Backup strategies for Windows Server 2003 filesystem

As I discovered recently, full filesystem backups of anything fancier than straight file storage seem to be of limited use. Examples:

1. AD, registry, and Windows itself: restore is not hardware-independent
2. MSSQL and pgsql servers: unless backup is made with VSS--which appears to bog the server as much as doing a hot backup of databases anyway--data is not necessarily in a usable state
3. NTBackup-created backups cannot be restored on anything newer than Windows Server 2003

I'm guessing that if your server hardware became unusable, building a replacement machine in a single-server, 9-5 availability environment, depending on what hardware you could get, it would be desirable to have backups that are as widely compatible as possible, since you're clearly stuck building and setting up from scratch. Given that, are there any major downsides to the following backup strategy?

1. Down SQL services
2. 7-zip tar update of all server hard disks to an external backup file
3. Verify integrity
4. Up SQL services again

(The tar update is just to avoid the middle-step when restoring of having to restore the complete backup and then incremental backups one at a time.)

From serverfault Kev

• I'm not so sure that you're correct in all cases, although you do have a point of sorts. However, you need to consider the case where you are restoring to the same hardware and software base as was backed up (which most places would - or at least should - do as a matter of course anyway). The scenario would be a DR where a server has failed and you need to get it back now, rather than restoring from a legacy or historical backup (which I suspect is the one you are considering more).

  Getting the data back is trivial. Getting the OS and it's configuration back can vary from relatively trivial to decidedly non-trivial. Getting a server application and it's configuration back is nearly always non-trivial. Full backups can save you in these situations.

  What I'm saying is that any sane backup strategy should consider a lot more than just the restore procedure, but should also consider the hardware and software in the restored environment.

  Kev : Good points to consider, but what if you don't know ahead of time what the restored environment will be? Small businesses can't always afford to have an identical secondary server standing by.

  Kev : Also, are you saying that a tarfile (taken with downed services rather than using VSS) cannot just be unpacked onto the drives, assuming the same hardware?
  From mh

• System State backups can be restored to dissimilar hardware. This can be a difficult experience but it can be done. link text

  SQL db dumps are not hardware dependent, but that doesn't get the application back.

  Assuming that tarring the disks works on identical hardware, (which I doubt unless the server is booted from a Linux boot CD and tarred from that environment) will it work if the target server is completely new, or the mb or RAID card is replaced? Without shutting the server down there won't be a restore-able backup of AD unless the System state backup is done separately.

  Can this solution be automated, can the output be verified? Can it be documented and are the steps simple enough that if you are on vacation, or have moved on to a different firm, a recovery can be performed? Is there tech support available if issues are encountered? If you are truly trying to diminish points of frustration during an emergency then all of these issues need to be considered.

  The statement about MS not supporting NTbackup in Server 2008 is incorrect, Server 2008 does provide for restoring NT Backups. link text

  An image based backup that can be restored to the same or dissimilar hardware or as a virtual machine (P2V) are some of the minimum requirements if a "fast" restore is needed. Generally this will require a 3rd party product and/or MS add-on: StorageCraft, Acronis, BackupExec, MS DPM, VMWare/Xen/HyperV, or hardware based snapshotting of VM's in a SAN along with replication. SBS 2003 has a server backup that might be considered "good enough" and all Server 2008 have image based backups.

  Kev : Thanks for the links. In particular I wish I had been able to find the second one earlier. I guess we'll stick with NTBackup for now, then. As for your questions, though, I don't think tar vs. NTBackup solves any of them. A restore on any hardware, same or different, still needs to have documented all the configuration and setup. Correct me if I'm wrong, but there's no free or built-in way to take any kind of backup that can then be plugged into a new system with empty drives, hit a button, and have the system working as it was before.

  Ed Fries : I completely agree that any backup method requires good documentation. My experience (through personal science experiments) has been that the more "alternative" the backup method is the more complex and less flexible they are to document, execute and t-shoot. One free method is using a P2V converter and then restoring as a VM. VMWare, Xen and MS all have free converters for P2V migration. Same caveats apply re. execution, automation, monitoring. I'm not aware of any built in imaging method for Server 2003.
  From Ed Fries