Things to consider when backing up Windows 2003 Server
Which are the most important things to consider when backup a Windows 2003 Server?
It means something like:
- Common mistakes.
- Things to consider to do a complete recover.
- The most important points to never forget.
- ...
Solution 1:
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.
Solution 2:
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.
Solution 3:
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.