Microsoft Small Business Server 2008 bundles Active Directory, Exchange 2007, IIS and Sharepoint into one supposedly easy to use package, tailored to run on a single server. It is aimed at networks of up to 75 users, and is great value if you want or need to run this stuff on-premise.
A new feature in Windows Server 2008 is Hyper-V, for server virtualisation; and a new feature of Small Business Server 2008 is the Premium Edition which comes with a license for a second server. One of the supported scenarios is that you use the second server to run a Hyper-V host, and run SBS 2008 itself as a virtual server.
Well, it is more or less supported. However, there is one significant oversight in Microsoft’s product design. SBS 2008 comes with a new backup solution based on imaging to an external hard drive rather than tape. Hyper-V guests do not support USB pass-through, so you cannot use the backup system in the way that is intended.
How then do you backup virtual SBS? Microsoft’s grown-up backup system is Data Protection Manager, which supports Hyper-V; but that is extra cost and an extra server, hardly appropriate for SBS.
What about just backing up the host? Since Windows Server Backup is able to backup live virtual machines, that seems a good solution. However, there are a few disadvantages:
1. Especially if your Virtual Hard Drives (VHDs) are fixed size, backing up the host is inefficient. Each VHD looks like a single huge file and will be backed up as such.
2. Backing up a live VM is a complex process. The host tells the guest it is being backed up, and VSS (Volume Shadow Services) gets invoked both on the host and in the guest. I’ve had backup failures when the guest is running, that disappear when the guest is shut down first.
3. There are special considerations when backing up a virtual domain controller, like SBS. It is recommended that you backup a domain controller from the guest:
Only use the standard way to backup and restore Active Directory Domain Controller, since the default checks of Active Directory consistency will only be performed when the Domain Controller is aware of a restore.
Using imaging solutions like Symantec Ghost and Acronis TrueImage seem like smarter backup and restore solutions, but they are imaging solutions (in contrast to proper backup and restore solutions.) Restoring an image of a Domain Controller may cause an Update Sequence Numbers (USN) rollback situation to occur, which may lead to replication problems and other undesired effects.
4. SBS 2008 backup has a very easy wizard for restoring individual files, such as a document that is inadvertently deleted. If you only have a host backup, getting at that individual file will not be quite so easy – though it should be possible to mount the backup VHD and copy the file from there.
I don’t mean to suggest that you should never do a host backup. It is a good idea; but should not be your only backup.
Is there a way to use the built-in SBS backup when running virtual? Here’s what I have come up with.
1. Use Hyper-V 2008 R2, not the first release. There is a free version, provided you can cope with server core. The reason is that R2 lets you attach and detach VHDs from the virtual SCSI controller while the guest is running.
2. Use a VHD as the backup target. A VHD attached to the virtual SCSI controller actually looks like a removable drive to the guest, so SBS backup will be happy. You need a large VHD – I suggest a dynamic VHD, which can be located on a cheap Sata drive if you like, since if the drive fails it can be easily replaced with minimal impact on the main server.
Backing up to a VHD actually works very nicely, since you can restore individual files using the wizard.
3. The tricky bit: how do we safely copy the backup VHD to an external drive each day, for off-site storage? Ideally this should not require the user to do more than simply plug and unplug a USB drive from the server.
You can accomplish this with a scheduled PowerShell script. First, grab the PowerShell Management Library for Hyper-V from Codeplex and install it on the host.
4. Next, go into the guest and open device manager. Under Disk drives, right-click the drive that is the backup VHD, click Policies, and choose Optimize for quick removal.
What if you have several drives, all called Msft Virtual Disk SCSI Disk Device? You can tell which is which by the LUN, which shows on the General tab. You can also see this number in the Hyper-V manager. I suggest you always use the same LUN for your backup VHD; in the example that follows it is LUN 6.
The reason you have to do this is that there is no way (that I know of) to script the Safe Remove Hardware wizard in order to safely remove the backup VHD. You will need to safely remove it, in order to back up the VHD with confidence. Turning off write caching means safe removal is not necessary.
5. Schedule your backup using the SBS wizard. The script will be detaching the backup target, so clearly you need to leave enough time for the backup to complete before detaching the drive. Fortunately, the SBS backup is incremental and usually completes relatively quickly; but leave plenty of margin. If a problem occurs, the SBS report will tell you.
6. Download sync.exe from sysinternals and install it on the host. It doesn’t matter where you put it, provided your script can find it. This enables you to flush the external backup drive so the user can safely disconnect it.
Why didn’t we use sync.exe on the guest as well? Because it requires a drive letter, and the SBS backup target does not have one.
7. Here’s a PowerShell script you can schedule on the host:
Remove-VMdrive "your-vm-name" 0 6 -SCSI -DiskOnly
Copy-Item path-to-source.vhd path-to-target-vhd
Add-VMDisk "your-vm-name" 0 6 "path-to-source.vhd" -SCSI
In this script, your-vm-name is the name of your SBS virtual machine; path-to-source.vhd is the full path to the backup VHD; path-to-target-vhd is the full path to where you will be copying that VHD on the external drive; and target-drive-letter is the drive letter that is assigned to the external drive.
The backup VHD will be large, so this script will take a while to complete.
It is helpful to keep details of how you have configured the SBS VM, in case you need to do a restore. In particular, note the sizes of any VHDs that are attached, and whether they are SCSI or IDE, and make sure you know their internal drive letters as well. It makes sense to keep one drive letter per VHD; I suggest avoiding multiple partitions on a single VHD.
Restoring Virtual SBS
If you follow the above procedure, you will have no problem restoring individual files or Exchange mailboxes from the internal backup VHD, but there are a few complications if you need to do a bare-metal restore. Imagine that your SBS server is stolen and all you have is your recent copy of the backup.vhd.
Here’s how you can do a bare metal restore. First, install Hyper-V Server R2 on the new machine. You will need wbadmin on this machine; you can install this using ocsetup.
Next, create a new VM using the same or similar settings to the original. Details such as the exact amount of RAM or the number of virtual processors don’t matter too much, but having the same number and size of VHDs attached is important.
Attach the backup VHD to the IDE controller, not SCSI. Otherwise the restore will not be able to see it.
Now boot the VM from the SBS install media. Go into system repair, and do a full recovery from the backup.
You will find that the recovery works for the C drive but not for any drives attached as SCSI. The recovery reports:
The following disks were not restored … The backup is restored to available disks.
Fortunately there is a workaround. Shutdown the VM once recovery completes; don’t try to restart it yet. Now log onto the Hyper-V host. Use Diskpart to mount your VHDs, the backup as well as any target VHDs that were not recovered. Assign a drive letter to the backup VHD. Partition, quick format, and assign a drive letter to the target VHDs.
Now you can use wbadmin to restore individual volumes. Continue until they are all complete. Take care to use the same version as used for the system recovery; normally you would just use the latest one.
Finally, use diskpart to detach the VHDs. Go back to the Hyper-V manager and move the backup VHD to the SCSI controller. Start the VM.
All going well, you will get a successful boot. In my tests, I found that the virtual NICs were re-detected by the guest, so it was as if the NICs had been replaced. This meant fixing networking, as the SBS server lost its assigned IP. In other respects, the restored SBS seemed to work fine.
Note that you can also restore the host complete with its VMs, if you have a full backup. However, doing this on a daily basis is more difficult and lengthy than backing up from the guest. My suggestion is to backup the host occasionally as a fallback.
Helpful post? Sponsor ITWriting.com for ad-free access to the site