I think the main gist of why

Greg K — Wed, 19 Nov 2008 16:44:56 +0000

I think the main gist of why they give a long explanation is to explain that the data your server uses is not on the same physical machine.

I have seen this, where there is a SAN server that web servers tie into to use (similar to having a dedicated SQL server instead of actually on the same machine physically). Set up properly you can have not only raid with redundant drives, but actual redundant servers as well.

As the others have said, all the redundancy means nothing if someone hacks in and deletes the files, because it will just be redundant on deleting them. Backup is critical. Even more critical is backup that is ONE WAY. Data can be written to the backup server, not deleted except by the backup server itself (ie, after it is rotated out of timeframe).

Also needed is remote backup as well to another site as mentioned. All the backup in the world means nothing if it is destroyed along with the originals.

-Greg

They aren't backing up your

pr0gr4mm3r — Wed, 19 Nov 2008 15:29:45 +0000

They aren't backing up your images, they are just stored on a RAID setup, protecting you from a disk failure. This will not, however, protect you from intruders or viruses. If a malicious person gets into your server and deletes all your data, you are SOL. That is what happened to VPSVille. A hacker deleted all the data after hacking in, it wasn't a disk failure.

Bottom line is that if you want a backup solution that protect against accidentally deletion, hardware failure, viruses, etc. - you need it off-site. RAID setups are nice, but it doesn't cover all the bases.

As you are probably aware,

decibel.places — Wed, 19 Nov 2008 14:47:56 +0000

As you are probably aware, TWF recently experienced catastrophic server failure without backup - the data was eventually recovered forensically, as the disk was not operable.

It sounds like the service is backing up your data remotely as disk image, a compact storage file that can be used to reconstruct your server files in case of failure on the main server.

I would ask whether the backups are kept in a different location than the active server, which is a better guarantee of recovery.

Even with a subscription to a remote backup service, it is a good idea to set up your own backups regularly, you can't be too careful.

Don't forget to back up your database(s), I do not see any discussion of this critical protection. Drupal has a handy Backup and Migrate module that will perform scheduled database backups on your server and you can download them in minutes.