The big nightmares for a web site operators are the "big crash" and the "hacked site". So most of us take regular backups to be able to recover. Most hosting services provide automated backup/recovery tools. However, sometimes those backups fail, and the big crash is not the only time you need a reliable backup. Single level backup won't help unless it is 100% reliable, 100% of the time; just like the Tooth Fairy. Backups cannot be relied on unless there is redundancy.
What is Redundant Backup?
Having sequential backups does nothing for you. 
The best you can hope for is that the latest worked correctly and is still accessible after the crash. Putting backups in multiple locations does not do the trick if all the locations can get wiped out at the same time. The hosting service backups might or might not be okay. They are automated processes, and might or might not give you what you need to recover. So you do your own backups. Put a backup in a recovery directory and when the crash comes it takes out that backup as well.
To be effective and truly redundant; backups must be isolated. So, you put a backup on your pc or laptop. Good but not foolproof. A third party storage provider? Now you are getting the idea; but let's go one more level and put it one on DVDs, tapes or thumb drives. At this point if you still can't find a backup you can use for recovery then the universe has decided to punish you for past sins.
Why Do You Need a Redundant Backup?
You don't need backups; let alone redundant backups. Modern systems are reliable, so failure are rare. You don't need seatbelts when driving because you never have accidents. You don't need AV software because you never go to nasty sites. You don't need fire insurance because you have never had a fire. However if you are not so fortunate, sooner or later you will need a backup. You may not understand why you need a redundant backup until the first time you find a corrupted backup.
Overkill? Yes it is overkill, just like having spare batteries for electronic devices.
How Much Time Does it Take?
The amount of time it takes is not a big deal. The actual time you spend working on it is a fraction of what recovery without backup will take. The time will vary based on the size and complexity of the site.
How Often Does it Need to be Done?
The frequency will vary based on volatility. All major changes need an immediate backup. The normal day-to-day changes can be covered with a daily backup, but if a site is relatively static, then once a week might be fine. Whatever the frequency, it needs to always be done on time and as a priority. It is almost a law that a crash only comes when the backups are out of date or you miss a cycle.
Tools (LAMP server side and WAMP for dev environment for this example)
Preparation
On your development computer you need a standalone dev environment. I find the easiest way to do the is to define a separate drive for my wamp server and keep everything related to the site and site development in folders on that drive. Then I set up another drive as a mirror. It will always have the latest version of the site on it. Finally, I have two versions of the database; one for development, and one for the mirror.
It is important that nothing in the mirror is changed for any reason. All changes are done in development and then promoted up to the server. The promotions need to be fully documented. I use a manifest for each piece that goes up.
Procedure
- Create folder S:\{yyyymmdd}. Using the current date makes it easy to locate specific versions of backup.
- FTP full site (root down) to S:\{yyyymmdd}
- Export production DB to S:{yyyymmdd}as an sql script file named db.sql
- Upload S:\{yyyymmdd} to your remote storage site. Keep three generations on the remote storage.
- REPLACE the dev environment on your remote storage site by deleting the previous version and uploading a fresh copy from W:.
- Purge data in the mirror database.
- Import S:{current date}\db.sql to create new mirror DB.
- Copy W: to DVD or thumb drive
- Copy S:\{yyyymmdd} to DVD or thumb drive
- It is generally okay to keep the last three version of the backup on the S: drive and delete any older versions
You now have a redundant backup that can be used to respond to any crash situation.
Recovery Scenarios
So what happens if there is a problem on the server that damages your site. The first line of defense is the hosting service backups. If they are out of date or unusable, you have the complete site in your mirror on the development computer. FTP and you are back in business. A worse situation? Your pc crashes and damages the mirror while you are trying to recover. Okay you use another computer; even a public one in the library or an internet cafe. You access the version on the third party site and you recover from that.
The absolute worst case is the remote site is not available or the backup on it has some how been corrupted. You go to the DVD with the mirror on it. Could this also fail? If it does it would mean 4 points of failure all failing at the same time. That is more redundancy than should ever be necessary; but if you want to feel safer yet you can also put your dev environment on a separate pc or laptop and as an added measure print everything. Now you can recover from anything short of an extinction level event like the moon falling out of the sky.
There is another option. You can use off the shelf backup systems, but you still need to deal with insuring that you have multiple backups in multiple isolated locations.