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.
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
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:
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.
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.
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).