Things to consider when backing up Windows 2003 Server

Some random thoughts:

A backup isn't a backup if you can't restore from it. You won't know if you can restore something unless you try it. Test restores from your backups!

If your backup media is destroyed at the same time the server computer is, it's not a backup. Take backups off-site!

I've seen several cases where service programs (database engines, etc) kept files locked and years of backups went by w/o ever catching the locked files. Had a test restore been tried, this would have been apparent.

If you have Active Directory you need to catch a "System State" backup on one of your domain controllers in a regular fashion.

If you plan to do a bare metal recovery of a specific server computer, having a "System State" (or equivalent) backup taken in a regular fashion is nice.

Consider the data you are backing up... is it a database server? Is it a web server? File server?
Is there data on the OS drive that is essential? If so why? Will it take longer to restore the OS than it will to rebuild it?

If it is a server I intend to do a bare metal type restore on I make sure I get the OS and System State daily, as well as the data.

If it's just a file server and there is little to nothing going on on the OS drive well then you may not need to back it up at all or at least no more often than once/week.

TEST YOUR RESTORES. Every time I see Evan say this I think there is a guy who probably learned this the hard way. I know I did.

Take a test box, and try and restore it to the original state of your server. You'll quickly notice if you don't have some sort of BareMetal option you're going to have to put an OS and a backup agent on it. Hence the question about does it take longer to rebuild than restore?

The most important piece of backup advice after "test your restores" I can think of is "know what to backup and what to exclude". Do NOT try and run your backup software over hot database files, or your anti-virus quarantine, or the directory your backup software is using for caching. These things may work some of the time, but they will cause backup failures eventually and then you won't have the backup you need when you need it. Murphy's Law means that the backup you absolutely must have is the incremental that failed.

As already mentioned, test restores are an absolute must. Other important items are:

• Document everything, including what goes where.
• Use backup software that reports back. e.g. If a locked file is skipped you need to know about it so that situations such as Evan described cannot happen.
• Ensure at least the two most recent backups are taken off-site. If you rely on just one you can be sure something will go wrong.
• If you value your data, and you should, don't use disposable media, such as external hard drives. Use something made for the job.
• If your system allows it, run more than one backup procedure. e.g. On Windows servers I use Windows Backup (to a local disk) so that restores from the previous day are quick and easy but Backup Exec (to tape) for "proper" backups. Fortunately for me, I have a large time window to do this in.
• Design your backup system to be as hardware independent as possible. If the smoke starts leaking out of the server you may well need to replace it with a different make or model, so find out if you can do a restore on incompatible hardware.

Just bear in mind that one of the reasons for backups is to be able to recover from a disaster, such as the building and everything in it being destroyed. They're not just so your users can get away with being careless.

When choosing the components that will make up your system give consideration to the future. If you have a disaster, such as a fire, will you still be able to obtain a drive that can read your old tapes, etc.

Backing up everything is the way to go, IMO.

It's not just about restoring data - that's the easy part. Can you also restore any apps running on the server?

Maybe an aside but while you're thinking about it, do yourself a favor and document everything. You'll be glad you did especially if you aren't 100% dedicated to setting up and maintaining the backups.

What gets backed up, when, how long it is kept, the actual (tested) restore procedure, and how your tape rotation and offsiting work. Ideally, these things can either be matched up against system SLAs or even form the basis of SLAs (and contribute to any DR planning)

Having this stuff clearly set out and easily accessible is useful. Most people don't think about the backups until they need them. Or until the auditors show up. And at that point, it's nice to be able to pull out a document and get them what they need.

One thing to remember is to back up the System State Data as that'll greatly help recovering after a lost-server event.

We have backed up a great deal of servers using Symantec Ghost and it works great every time.

But just like tape storage, make sure you test it on similar hardware.

Another software that some associates of mine use is Acronis which works quite well.

Never name backups as "new backup", "newer backup". Always write down a date.

I suggest doing traditional master/differential file level backups (to facilitate single file restoration) as well as doing a baremetal backup of the server's boot partition. If the server fails, you can then restore the OS/Apps to repaired/replaced hardware and be up in running in very short order, followed by a file level restoration. I would also consider backing up to a disk target/appliance like a Unitrends solution (or equivalent).