Let me see if I can clarify.
Redundant routing engines
Redundant REs are hardware-specific. Typically, this referrs to chassis platforms that have a routing engine (supervisor in Cisco world) that is independent of the line cards with the actual ports on it. This would be something like the MX240/480/960, EX8200/9200, M10i/40/120/320, and some others. The chassis has slots for two physical routing engines (the brains) independent of the slots for normal interfaces.
Platforms that support virtual chassis (stacks in Cisco world), like the EX4200, muddy things a little bit. These platforms are self-contained: the brains and the forwarding ports are all combined into one unit. When multiple of these physical units are linked together to be managed as a single logical unit, 1-2 of the physical units behave as routing engines. Just like chassis platforms, one is master, the other is backup, and the assorted protocols and management stuff runs on them. The physical units that are not acting like routing engines are designated "line cards". They run a small subset of processes in order to communicate with the "routing engine".
backup-router
This one has nothing to do with normal traffic flow or normal routing. It is not required in the configuration. It is for out-of-band management and works with physical management port on the routing engine. That is fxp0 (M/MX/T) or me0 (EX) or vme (EX virtual chassis). Think of it as a default route for the system to use while it is coming online.
Network management with dual REs
The easiest is to do in-band management. The IP address is assigned to the chassis itself, not to a routing engines (components) within the chassis. Using in-band management, you are connecting to the chassis using normal interfaces and normal routing table.
Doing out-of-band management can be tricky. I'm not going to attempt to explain it since it varies depending on the environment.
Redundant RE communication
For the most part, you never need to worry about this. There is nothing you need, or can, configure. This is the exact same mechanism used for communication between the routing engine and the line cards. I will say that for normal chassis hardware, all communication is contained within the chassis itself and it is all handled outside of the normal network traffic.
On a virtual chassis, there are "virtual chassis ports" (VCPs) that are used to connect the physical units together. Communication between the units, as well as normal traffic going from one unit to another, will use the virtual chassis ports. There are two physical VCPs on each physical switch. If you have units that are farther apart that the longest virtual chassis cable supports (~20m I think?) you can specify that that tone or wo normal physical ports will be used as VCPs instead. Note that this dedicates the port(s) to virtual chassis usage, no other configuration will be allowed on them. Again, nothing you can configure here.
The communication itself is internal to the chassis. If it is a virtual chassis, then the communication is across the virtual chassis uplink ports.
Detecting failures
This is one of the things the RE communication handles automatically. Each one is aware of the other using something akin to heartbeats. If the backup stops hearing heartbeats from the master for a certain amount of time it will decide that the old master is dead and will take over as the new master. If the formerly dead routing engine comes back online, it will check to see if there is already a master. If there is a master then it will go into backup mode. If there isn't it will go into master mode.
You can also manually toggle mastership between the two routing engines. This is useful when doing code upgrades or wanting to test failover scenarios. "request chassis routing-engine master switch" is the command.
graceful route-engine switchover (GRES)
This is the biggest reason for having redundant REs and is primarily intended to minimize disruption to the network in the event of a route-engine failure. With GRES enabled, some information is synced from the master RE to the backup RE. This allows the backup RE to take over without having to do things like reset the line cards. There are some things that may still need to be started from scratch though.
GRES sets the foundation for non-stop functionality. Non-stop is when mastership can switch from one RE to the other and there is no disruption to the network. There is non-stop routing (NSR) and non-stop bridging (NSB); NSB may also be referred to as non-stop switching. With NSR enabled, not only are some system-level things kept in sync between the REs, but routing protocols are synced as well. When an update occurs on the master, the backup is also notified. That means the backup RE will effectively have a mirror of the master RE's route table ready to go.
NSB is the same as NSR but covers layer-2 functions. That means things like spanning-tree and the switching table are mirrored between the REs.
Note that clusters are different that redundant REs. Clusters are primarily for the security side and are for 2+ physical devices. A cluster member may or may not have redundant REs, it depends on the hardware. The closest analogy to a cluster in the routing/switching side would be a virtual-chassis but they are definitely not the same thing. No such concepts like clusters or redundancy groups.
Does that help explain it?
-Chad