How good/safe are disk to disk backups?

In the good old days, backups went to tapes, some of which were often offline if not offsite. This made it difficult to destroy all backups (accidentally or maliciously), especially if the network/servers have been compromised.

These days, disk to disk backups are all the rage which brings up two questions:

  • Is it common for a d2d setup to keep all backups online (as opposed to also using tapes, rotating drives, ...)?
  • How are online backups typically protected? In other words, how is access to the media (e.g. files), and the ability to destroy it, restricted? How many people typically have access? etc..

Solution 1:

disk-2-disk backups as long as disks are kept offline in remote location: OK

online-only backups: Not OK

backups stored physically near your server: Not OK

if your site gets compromised and attacker will want to take you down - [s]he will not only destroy your data but also backups.

take a look here how people handle such backups.

you can obviously experiment with pull method of taking backups - so it's your backup server that connects to machines and copies the files. make sure backup machine is not internet reachable, is located in remote office / datacenter - this can actually work.

Solution 2:

Disk to disk over a WAN link to another site is ok. I am not a fan of having all my backups online, nor of having all my backups on tape. I've been in the backup game for quite a while now and people keep saying "Tape is dead." I don't think tape is dead. Disk 2 disk isn't the perfect replacement yet. Tape write speed is a limiting factor to some degree, but if you're talking about backing up with something like LTO4 you're going to hit network transfer limits long before you hit tape write limits. Unless you've got 10GB Ethernet. So if you're backing up to disk over the network then you're probably not going to see a huge speed hit going to enterprise class tape.

Backups are covering several contingencies most places: accidental file deletion, intentional data deletion/destruction, and disaster recovery, and sometimes data archiving. Depending on what all your needs are you probably need your data further away than the next rack.

Disk to disk backup comes in many forms, from scripted or manual file copies, to virtual tape libraries, to disk storage managed by your backup software. The VTL and disk backup managed by your software have the advantage of providing offline backup that can only be managed via backup software, and thus aren't subject to user intervention, and less susceptible to virus or malicious user attacks. I am using a deduplicating VTL now. Previously I had a large chunk of SAN space managed by NetBackup setup as a Disk Storage Unit. Since my total storage in this arena was limited I used it for backups that had short retention and didn't grow much.

I am not aware of a d2d solution that is meant to have it's drives pulled out and rotated. Since most of them are using RAID across all the disks. Which means your retention is limited by your disk size.

I strongly advocate against online disk based backups. They aren't really secure against tampering, and they can lead to data inconsistencies. I know a lot of people especially here on serverfault are using them but I don't think this is the way to make disk backup most effective.

I feel the same way about breaking mirrors and moving disks. Most RAID controllers will take it fine, but it is a lot of overhead to rebuild that RAID set and in the mean time your performance will suffer.

Solution 3:

One nice thing about doing backups to hard drives is that they are fast. Using a tape-based system, our tape-write-speed is the slow link in the chain. I think that if we began using hard-drives for backups, our network throughput would become the limiting factor.

Probably more critical is that restores can take place quicker. Not only due to the speed of the drives, but because they are random-access, you don't have to wait for a tape drive to do a slow sequential seek to find where to begin reading before you can perform the restore. And in a disaster recovery situation, time can be critical.