1

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.)

Improve this question
5
  • Is there a reason you don't want to use something like Backup Exec and the necessary agents? Perhaps Backup Exec System Recovery? Commented Feb 19, 2010 at 15:57
  • Compatibility. How do I know they'll always have a version for the current version of Windows that will be able to read the files their older version produced? Tar, at least, never changes. Also Backup Exec costs money. Commented Feb 19, 2010 at 16:17
  • (The reason I say this is that Microsoft did that very thing by pulling the plug on NTBackup in 2008 and not having the replacement be able to read NTBackup files. That's what I meant by my third example in the OP.) Commented Feb 19, 2010 at 16:22
  • 1
    Understand the money part but how much is the data worth? Version changes are often an issue that one has to deal with. Backup Exec has been pretty good about using data from older versions or NTBackup. Don't forget that hardware changes too. What do you plug your USB 2.0 drive or PATA drive into in 10 years? The data usually moves with the hardware. New hardware has the data migrated to it. Commented Feb 19, 2010 at 19:34
  • Good point, but I think software incompatibilities crop up faster than hardware ones do. Either way, I'm trying to diminish points of frustration during an emergency. I realize there's no perfect solution. Commented Feb 19, 2010 at 21:38

2 Answers 2

Reset to default
3

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.

Improve this answer
2
  • 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. Commented Feb 22, 2010 at 19:18
  • 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. Commented Feb 23, 2010 at 17:45
1

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.

Improve this answer
2
  • 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. Commented Feb 19, 2010 at 18:15
  • 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? Commented Feb 19, 2010 at 18:17

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.