Overcome Windows 2008 R2 backup to network share limitation

Given that I work at a school district with no money, I find myself constantly faced with challenges that would otherwise be non-existent had I owned the correct tools. What I’m referring to in this instance, is Windows 2008 backup. If you are familiar with the earlier model of the Windows Server Backup (i.e: 2003 R2 and earlier), you know that the whole model has completely changed, and though the backup model seems pretty simple with Windows 2008 Server, almost mimicking the method that Time Machine uses on the mac, it is seriously lacking for backing up anything beyond one server.

For those not familiar with the Windows 2008 server backup (WB), there are 3 backup destinations which are possible.

  1. Device: this will allow you backup whatever data you choose, or your whole server to a device, be it another hard drive on your server, external device, or even remote device. This is the most intelligent method where the WB will operate most efficiently. The downside to this, is that you are required to format the whole device, and dedicate for a backup. If you have an iSCSI device, this would mean that you would have to have a separate backup volume for each server.  not exactly an ideal situation.
  2. Volume: This allows to back up to a volume which resides on the same server. Meaning, this could be another physical drive, or Partition.  This works ok, but would cost you a performance hit on the server. Given that you are backing up the data on the server to a volume on that server, it is highly likely that the server in question is running a production application and can’t afford a performance hit. The warning when choosing this option warns about a potential 200% performance decrease when running a backup to a volume.
  3. Network Folder : This method is what we are usually all familiar with as far as backup is concerned. With Windows 2008 Backup, it is possible. With a couple major caveats:
    • Though it is possible to schedule a backup to a network folder, that backup will overwrite the destination backup every time it runs. This means that you lose all the intelligence in the backup engine, and will only have on backup on-hand.
    • As a result of the first caveat, and if you want to have a workaround, you would have to use the wbadmin.exe command line utility, in combination with the schtasks.exe in order to schedule additional backup jobs. This will work, as long as you keep in mind that (1) You will no longer be able to monitor the backup job status for the manually created tasks. and (2) You will lose the ability to perform an incremental or differential backup. For every job, you would have to account for a full backup, means x2, x3 or x4 the space, depending on how many backups you want to keep.

The Solution
We need to have something that can be mounted on the source server that WB can actually see as a local volume, and therefore allowing us to use it as a target volume, instead of a network share, even though the actual destination data does in fact exist on a network share.

Here’s how to do it:

    • First estimate the amount of space you’re going to need for backup. The Windows backup is smart enough, and will delete old backups, so, depending on how far back you want your backups to go, you can double, or triple the space for your backup volume. For instance, if your data is 10Gb and you have a few megabytes of changes per days, then, creating a volume that is 15Gb for the backup, will likely make backups available to you, going back 3 months.
    • On your destination server. (where you want the backups to live), create a VHD file with the estimated size of the backup. Theoretically, you can create a TrueCrypt volume, or any other file that can be mounted as a device. (this example is assuming that your server that has the backups on it is running Windows Vista, 2008 or 7). To create a VHD:
        • Right click on My Computer and select Manage
        • click on Disk Management then right-click on Create VHD
        • Follow the prompt to create a VHD that corresponds to the size of your backup target.

      Right click on My computer and click on “Manage”

      From “Disk Management” right-click and select “Create VHD”

      Create the volume

    • On your source server (where you want to back up the data from), go through the same steps, but instead of select Create VHD, select Attach VHD
    • In the Browse… field, type in the path to the VHD you created on the target server, in the form of a UNC path.
    • The disk will get detected, and will show up in disk management
    • Go to the disk, initialize it, and format it like you would any other volume
    • Attach the VHD

      Browse to the VHD on the network location

      Initialize the VHD

Utility which will auto-mount the VHD on startup.


  • Go back to your Windows Backup, and change the destination to be a “Volume” destination. You will notice that the –remote– VHD volume will show up as a local drive for the server, and will now allow you to back up to a network “share”, while taking advantage of the features of Windows backup.


The last step required is to get the VHD to mount automatically upon server reboot. To do this, there is a little utility that you can run which will do exactly that, you can get it here: http://www.bmvhdloader.com/2.4.htm

Simply install it, point it to the VHD, and allow it to mount on startup.

Print Friendly

Sorry to necro this post. But I get "The process cannot access the file because it is being used by another process".

when i try to attach the vhd to the source server. Keep in mind that i use the vhd to be created dynamically not fixed on the destination server.



Before attaching the .vhd file to the source server you should detach the disk corresponding the created .vhd file from the destination server (the server where the file was created).


Searched hard for a solution in a restoration battle a few days ago. Wish this was easier to find. Another solution: Load Kernsafe ISCSI target software on the network share machine, and map a folder as a local ISCSI hard drive. Windows will see the target as local device and restore to it. Then you can drop the Iscsi target and skip the step of moving the data out of the vhd.

Kendall Bennett
Kendall Bennett

Imritebehindu: Once you have attached the VHD you can share the drive on the network. As long as the user has permission to access the drive and the drive is Mapped on the computer/ Server that is backing up to it there should be no issues. When Using VHD's as network drives ect you will need to make them non Dynamic. ( Static) when creating them. This means it needs to be zeroed out. Windows has no way of expanding the drive after you have mounted it and shared it on a network. Eddie: Good work. Do you Schedule that? Since VHD's are becoming more common to backup to does anyone feel that BMVHDloader should have a backup to VHD function with scheduling?


Thanks a lot for the article. Am running vmware and I have storage disks and OS disks. The plan is to let the storage disks spin down. So I can't backup to an vmdk on them. But with your help I got it to work. This is what I did: My batch file: diskpart /s mount.txt "D:\mysqldump.exe" --all-databases --port 3300 --user=root --password=...>"D:\database.sql "C:\Program Files\WinRAR\rar.exe" a "D:\MySQL Datafiles\Backup\SQL-Database.rar" -df -ri1 -mt2 -ag[yyyy-mm-dd] -v51200 -m5 "D:\"*.sql %windir%\System32\wbadmin.exe start backup -templateId:{8a49814b-7122-48f1-9211-4bdd825bc876} -quiet TIMEOUT 900 time my backup takes!!!!!! diskpart /s unmount.txt mount.txt: SELECT VDISK FILE="\\\d\Backups\vhd.vhd" ATTACH VDISK exit unmount.txt: SELECT VDISK FILE="\\\d\Backups\vhd.vhd" DETACH VDISK exit


The VHD trick has certainly helped with the situation I am in. However a 1TB VHD takes a very long time to create! There is a VHD tool out there which will create the full size VHD in seconds without zeroing out the disk but doesn't look like that can be run to a network share so didn't help me. Backups ate great with the VHD for restoring files but my tests of restoring a system image has so far failed. Thought I got it working by attaching the VHD to another machine and extracting the data within but it failed. If I just attach the VHD to another machine and share that drive Windows doesn't even see it. This was tested by booting from my 2008 Install disk and using the repair over a network share. If anyone has tried and tested and have a working solution for system image restores from a VHD then please let me know. May have to go back to the client to cough up and buy an iscsi nas! Thanks


You sir are a genius

Bishoy Harby
Bishoy Harby

Excellent solution, Thank you very much . I too work at a university !! :D


As vito said, this is a little slow, but the tradeoffs of having more than one backup available, as well as the ability to seamlessly do incremental backups with VSS, more than outweigh that drawback. Currently, I'm doing this for several Hyper-V guest machines and it works well (I added the VHD to the guest machine using Hyper-V so I didn't have to mess with trying to reattach it every time the guest booted). The restore path for a guest machine is fairly straightforward, as Hyper-V would make the backup disk available to the recovery console. However, I'm wondering how this would be accomplished for a physical machine. Have you ever done a restore from one of the VHDs that you made with this method? How did you mount it in the recovery console on the physical machine?


I too work at a school division with very limited budget to do things.....I ttoally know how ya feel. Good post. 2008 backup was cool and fast..going to a ISCSI NAS...but now I find my jobs are running 4 times longer then they used to. MS updates fixed some things made others slower.....


  1. […] More info at http://blog.foreignkid.net/2011/07/overcome-windows-2008-r2-backup-to-network-share-limitation/ […]

Subscribe By Email for Updates.