Sometimes, despite all ground testing, a new build of software can break a satellite. How does one put in protections to keep this failure from being a permanent failure?
For example, what do you do if for some reason the new software isn't 100% updated? Or if there was an unintended consequence of the new build? How can you ensure you can always fix a problem caused by a software bug?
A typical approach as used on Mars rovers is to keep the previous build on the spacecraft as the default to boot to on a reset. You load the new build and command a boot to the new one. Then you test it. If something goes south, it will reboot to the old build. Or you can command a reboot to the old one. Once you're confident in the new build, you make it the default. Even then you can keep the old build on-board just in case. It can be booted to by setting a bit to use that one and commanding a reset (using "hardware" commands decoded by the radio).
There are 2 main methods I'm aware of that spacecraft employ. One is what Mark mentioned, that two images are kept on the spacecraft. Usually one of these images is called the "Gold" image, and is never actually updated during flight. This image is thoroughly tested to ensure proper functionality on the ground prior to launch.
The second way is to have 3 layers of software build on top of each other. The Mon 1 image is just a bootloader, which loads Mon 2. Mon 1 and Mon 2 never change during flight, and are thoroughly tested prior to launch. They contain the minimum code required to talk to the satellite, so it can be fixed. The Mon 3 code contains the useful code, and is updated in flight.