Is our planned backup strategy adequate for my new server insfrastructure?

We're in the process of setting up a new server for migrating the old ones.
Basically we'll have a Windows Server (2003 or 2008) running 6+ virtual box servers (Windows and Linux development, applications, databases and a couple of testing workstations) on RAID 5.

Also we need to centralize data (files and SVN repositories), so a file server will be needed. As we don't have any admin experience and never done backup before, do you have any experience virtualizing file servers? It is best to run them on a physical box? Any advice on running this will be welcome.

About our backup strategy, the one sketched for now is:
Note: tape backup for now is not an option for us, because of money constraints.

• Do a full backup weekly to a separate backup server on RAID 5 (see Should a backup server use RAID?) and to external drive (sort of poor man's tape drive)
• Differential daily backups
• Planning to do a monthly backup to online services

Do you think this approach is reasonable? Im sure there are a lot of aspect to carry about that we are surely missing.

Lastly, one think that worries us is how to backup virtualbox machines. One simple way is to simple backup everithing (as recommended in one of the questions, i can't find wich...).
What is your advice about the data contained in that vboxes? Should be backed up also ("just in case..."), or it is safe to backup the virtual images directly?

If it serves as additional info, we're planning to use BackupExec.

Thanks for thaking the time to read this.

----- 2009/08/04 UPDATE -----

Due to health reasons i couln't keep on with this question. Thanks to those who answered my question, it was a big help.

Here is the backup plan we've sketched now we've got more background: As we're a small company (from south america), for now we can't afford a tape drive.

I now bacukp isnt bacukp if it's not offsite & offline, but we're trying to get the better strategy for out money constraint:

Data loss window: 1 day/8hrs. Recovery Time: 1 day/8hrs. Stuff to backup: all (data & server installations)

• Daily: do a diff backup daily to a physical backup server, possibly with BackupExec. Someone proposed to use one of those external storage hubs with sata support. Another proposed uploading it to a storage service while we can get a tape. We don't have the option for taking then offsite right now (so data loss window 'fake')
• Weekly: take out a full backup with an external 1TB drive.
• Monthly/Yearly: same as weekly. We have the problem of where to store those backups

We want to keep it simple, but i think we're getting it complex with all those daily strategies for overcoming the leak of offsite backup.

Solution 1:

My standard backup advice:

The whole point of backing up is to be able to restore. Unless you're fully confident that you can get your stuff back, your backups are useless. Everything you implement in your backup solution should be coming from the perspective of "how do I restore from this?"

Tape isn't that expensive, and it has the advantage that it's far more durable than disk. Less moving parts, no live electrical current going through it on a constant basis, all good stuff. If it saves your ass once then it's already paid for itself in my book.

As well as "how much data can you afford to lose" you also need to consider "how long can you afford to be down for in the case of a DR scenario?" A 3 day restore time is 3 days of lost business. You should be counting your restore times in hours and on the fingers of one hand.

You can very quickly get into silly money if you allow yourself to get too paranoid about this however, so you should be looking to divide your servers into 2 or 3 lots. Those you absolutely need to get back NOW in order to continue your core business functions, and those you can defer until after the core ones are back. Put the heavy investment into the first lot, ensure that you have fully documented restore procedures (for the OS, for applications and for data) that a blind leprous monkey with one hand tied behind it's back can follow. Print and bind a copy and keep it in a fireproof safe - you're screwed if all you have is an electronic copy and that gets lost or destroyed. But don't think that this means you can get lax with the second lot, just that you can delay getting them back or take a little longer doing so (eg. by putting them on slower media).

Specific examples: your core fileserver goes into the first lot, for sure. Your HR server goes into the second lot. It's important to the HR people, but will your core business functions be OK for a coupla days without a HR system? Yup, I reckon they will.

Keep your backup solution simple and boring. Far too often I have seen people implement fancy or complex backup solutions that just end up being too complex, fiddly and unreliable. Backups are boring because backups should be boring. The simpler they are, the easier it will be to restore. You want a "me Og, Og click button, Og get data back" approach. Keep a daily manual element in there. This helps to establish a drill, which can avoid situations where someone forgets to change a tape or rotate a HD in the pool. You can fire the person responsible afterwards if this happens, but guess what? You're still in a position where you've lost a month of data.

Solution 2:

Nick,

I would strongly recommend you take a look at the book "Backup & Recovery" from O'Reilly.

http://oreilly.com/catalog/9780596102463

It will explain to you terms such as "single point of failure" as well as general strategy for backing up your critical systems.

This is a good book for anyone's bookshelf.

Solution 3:

The key question is how much data are you prepaired to lose? One months? One days? 6 hours? 5 mins?

It gets more expensive as the data loss window gets smaller.