So our current backup system has stopped working. We had 4 harddrives on rotate, each taking 2 days and sunday being skipped. Each backup doing a FULL backup. I did NOT design this! All 4 harddrives are not working suddenly. I am investigating it sigh
Anyway, I would like to use the opportunity to set up a proper system.
I have some specific requests:
- Has to be able to handle harddrive failure (so some duplication, raid or similar).
- I will go to work tomorrow and find out which inputs, besides USB, it can take.
- It has to support encryption (disk encryption?), a strong one would be great (in fear of theft).
- It has to do good incremental backups.
- Some inbuildt support for exchange server 2003 would be greatly appreciated.
- If it can support some kind of rotation, it would be great.
So far, each month, the chief take a harddrive, which has a backup of everything,and takes it home to his vault. After a months, he would take it back, put it back into rotation and then take a different one home. Etc. This prevent complete dataloss if there is a major fire, theft or similar.
If it could this, as a hot-swap(I was thinking of a raid5 + a drive doing a duplicate), it would be great.
Can anyone help me out? My company is able to pay both for hardware solution plus a seperate software solution that uses the hardware.
I've never been a fan of using hard drives as a primary means of backup storage and retention. IMHO, you're better off using tape backups for long term and archival backups and hard drives for short term, near-line backups.
There are a bazillion different ways to accomplish your goals so I'll just propose our method as one for your consideration:
We run a Full backup of all of our systems once a week to a 2TB external hard drive array on our backup server. We then run incremental backups the remaining 6 days of the week to the same external drive array.
Each day, the backups that reside on the external drive array are backed up to tape and moved off site for 4 weeks. On the 5th week we start the rotation again. We always have 4 weeks of daily backups on the near-line external drive array for immediate recovery needs and we have 4 weeks of tape backups off site for DR purposes.
Once a month we take a special Full backup of all of our systems to tape and archive those tapes for 3 years. this becomes our long term archive and DR backup library.
We use Symantec BackupExec 12.5 (which supports encrypted backups) with the appropriate agents for our systems (Windows, SQL, Sharepoint, Exchange, AD, etc.).
It's unclear what you mean. You talk about "offsite" and "local", but then you talk about "choosing local". Backup is off-site and offline. Anything else isn't backup. If you don't have a robust off-site component, taking data off-site as often as is necessary for the tolerable risk then it's not backup.
There are some good discussions on backup already on Server Fault. I'd have a look at them:
Is our planned backup strategy adequate for my new server insfrastructure?
Recommended Backup Media for Circa 2009?
Personally, I think you should at least investigate the expense associated with a "traditional" tape backup and the associated management software. I did some calculations a few months ago (posted on Server Fault in one of the questions above, but not updated) and found that tape wasn't necessarily the most expensive route. Call me a traditionalist, but tape has worked very well for me and my Customers, and has proven to be reliable and suitable for disaster recovery. I tend to think that a lot of the "horror stories" associated with tape being unreliable often stem from backup strategies that don't involve testing of the backups after-the-fact. As is often said, backup isn't about backup-- it's about being able to restore.
Off-the-shelf hard disk drives aren't built to be used as hot-swappable backup media. I'm certainly not saying that they won't work, but I'd question the long-term reliability and expense. I'm not surprised that you've had some disk failures.
This field is a moving target. Personally, I'm hoping that we end up using something non-volatile and solid state, like flash memory, moving forward. Until costs get down to the point where that makes sense, though, we're all stuck with ugly thinkgs like moving parts and spinning platters or mylar ribbons covered in rust.
Edit:
joeqwerty mentioned Symantec Backup Exec, and I'll second that recommendation here. His disk-to-disk-to-tape strategy works very well, and we're doing the same thing with several Customers. The software can be a bit pricey, but it works as well as anything I've used (and a whole lot better than some of its competitors... >cough< ArcServe...)
You shouldn't center your whole backup regime around writing backups to an on-site storage device. Further, I'd question if you can restore fast enough to get back up and running in a timely fashion if your off-site backup device is a "cloud-based" remote backup solution. If your "cloud" provider has a provision to ship you a physical storage device I could see that working. If you have to download your entire backup corpus over a consumer Internet connection, though, I'd think that you'd be talking about at least a couple of days to get everything back up and running. Ouch!
Likewise I would suggest tape; many of the reasons have been gone over in the other posts that Evan linked to, so have a read of those. If nothing else, it's tried & trusted, durable, the media is cheap, high-performing and high-capacity, and - with a good external drive or library in place - incredibly flexible for restoring from (the whole point of backing up is to be able to restore, so come at it from that angle).
Regarding cloud backups, they may be tempting but the one point I would always stress about them is that you will have to be absolutely certain that you can get a full server restore done in a comparable amount of time before committing to this kind of solution. If you have money to burn and want a second tier, they might be suitable, but I don't believe that anything can compare with local for your primary backup and restore. (Ever tried restoring an Exchange edb over your internet pipe? Me neither, and I sure don't want to.)