Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've got an intriguing goal with an equally intriguing problem to overcome: how to restore an OS to a set of blank disks attached to a running computer. This computer is running the very OS I want to restore to the blank disks, and I when the restore is complete, I want to be able to bring the new disks online as if nothing had happened.

Our current setup:

Windows Server 2003

  • Backup Exec 10d backup server with an accessible backup of the C:\ and shadow copy components of the R2 server
  • Primary DC

Windows Server 2003 R2 server

  • System partition running on software RAID 1 (read:dynamic disks) (C:\)
  • An empty RAID 1 basic, primary NTFS partition running off a hardware controller (E:\)
  • Secondary DC

What I'd like to do

Without disturbing the software RAID partition, restore a recent backup of the R2 server to the partition on the hardware RAID controller and unplug the software RAID partitions, effectively switching from software RAID to hardware RAID. Ideally, the server will boot to the new drive, which should then be the standard C:\, and life will continue as if nothing happened.

Effectively, what I'm trying to do is 'install' an OS from a backup to an empty set of disks by simply restoring a backup to the empty disks, nothing else (seems simple, doesn't it?)

A couple of concerns I have:

  • I don't trust Backup Exec 10d to do things logically, due to past experience: if I elect to restore the shadow copy components of the remote server, will it restore them to the remote server (good), or to the local Backup Exec 10d server (bad)?
  • (if the above is SCC redirect properly, then:) If I elect to redirect the backup, will the shadow copy components be redirected to the new disks as well?
  • All else failing, or because there's a simpler way, what other options do I have?
share|improve this question
    
There are no "primary servers" in Active Directory. The "PDC Emulator" FSMO role holder relates to time sync, NT 4.0 compatibility, and some specific user password validation behaviours. The AD database on the PDC Emulator FSMO role holder isn't special otherwise and it's some magic "primary" copy. –  Evan Anderson Dec 20 '09 at 0:44
    
You're right, thanks for the clarification/reminder. –  jobu1324 Dec 20 '09 at 2:03

1 Answer 1

I don't think you're going to get what you want with the method you're proposing. Switching the type of disk controller that Windows 2003 boots from hasn't been tremendously reliable in my experience.

Backup Exec also isn't going to write out the bootloader bits necessary to make these disks bootable when you restore onto them. You'll end up needing to boot the Windows Server CD and use the recovery console to do a "FIXBOOT" and "FIXMBR".

I'd opt to demote the Windows Server 2003 R2 machine back to a member server, reinstall the OS (leaving the hardware RAID partition alone), and re-promote. That's going to get you a clean install of Windows that I'd trust to work w/o any future "strangeness" that might result from the strange backup and restore.

If you do opt to attempt the backup and restore I'd DCPROMO the server back to a member server anyway, just so you don't have troubleshooting Active Directory startup issues to contend with with the rest of the process.

share|improve this answer
    
Hmm. I'm not worried about the FIXBOOT or FIXMBR problem. What kind of trouble have you had switching disk controllers? Was it just something that an edit of the boot.ini could fix, or was it more involved than that? The recommendation to demote the server before attempting anything is well-taken. Can you foresee any difficulties if we restored from a backup of a demoted server and then re-promoted it? –  jobu1324 Dec 20 '09 at 2:08
    
Since you've got the driver for the hardware RAID already loaded you're on your way. You may get by w/ just an edit to the BOOT.INI and swapping the proper SCSI driver into NTBOOTDD.SYS. Since you're starting from a functional state, so long as you keep your current boot drives unchanged (and, of course, are careful with your data partition), you're safe to give it a try. Frankly, I think Microsoft could be more open in documenting exactly how the Windows boot process works. Moving Linux installs between unlike disk controllers is no sweat, but Windows always gives me the willies. –  Evan Anderson Dec 20 '09 at 4:18
    
It may be a while before I try this out, so for now I'll vote you up. But if we do move ahead on this, I'll certainly come back here and mark this answered if your suggestions work. Thanks for the help! –  jobu1324 Dec 22 '09 at 3:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.