Booting image backup vhds in Virtual PC or Hyper-V


#1

I have image backups that run fine and good. On a Windows system with reserved partition, I can see that separate vhds were created for the sysvol and C: drive. Backup for each volume also come with .mbr files.

Is it possible to simply boot the vhds without having to restore again using the restore cd? This way, it will be more efficient if the restore environment is virtualized.

It will be good if the image backup can combine the sysvol and c: drive volumes into 1 vhd so that it is bootable straightoff. Any ideas if this will be made possible in version 1.5?


#2

@uroni, I would be interested in this also. Can you please elaborate on what the restore CD does? It might help those of us who want to do a more direct import in to some sort of virtualization platform.


#3

You can kind of see that here: https://urbackup.atlassian.net/wiki/display/US/How+to+restore+via+command+line

MBR (first 512 byte of the disks) are stored in the .mbr files plus information about which partition the vhd should be restored to. The MBR also contains the offset and size of the volume within the VHD. The offset is fixed at 524288 bytes currently.

I think it would not be much effort to also add copy to VHD file target to the above write_mbr and vhdcopy operations. That way you could cobble together a working (single) VHD file from multiple VHD files. Would that work?
The restore CD is actually using the Linux kernel to read the partition table. So reading the partition table has to be implemented.


#4

I get what you mean. But how does it work in cases where there are system reserved partitions available? Does the following work assuming that my target is a single vhd file named target.vhd?

  1. write mbr to target.vhd file
  2. vhdcopy the system reserved backup to target.vhd
  3. vhdcopy again with the actual volume backup to target.vhd

Will step 3 overwrite whatever was restored in step 2 or will it simply append to the disk so that i can now have 2 partitions/volumes in a single disk/vhd file?


#5

That should work for my purposes. I just need to be able to automate the process of making the VHDs bootable on Xen or Hyper-V.


#6

Just wondering if you have managed to test this out successfully?


#7

For systems with system reserved partitions, image backups will result in 2 vhd - one for imaging C drive and one for imaging the sysvol.

Both of the above also come with a .mbr file. Is it sufficient to just restore the sysvol mbr file if i want to make the restored client bootable?


#8

They both contain the same MBR so restoring one is sufficient


#9

Okay here is what I have tested:

  1. write mbr to target.vhd file
  2. vhdcopy the system reserved backup to target.vhd
  3. vhdcopy again with the actual volume backup to target.vhd

The above results in a single vhd file named target.vhd. However, virtualbox is refused to recognize it as a virtual disk.

Is it supposed to work this way?


#10

I have been able to boot up a full image backup using third party tools. I recently spoke to a company who uses it for DR. You will need a software called Bootice and a ISO of the installation media.

Open Bootice and select Disk Image Tab. Naviagate to VHD file and select it. Go through the following:

  1. Proces MBR> Windows NT 5.x/6.x MBR>Install/Config>Windows NT 6.x>Close

2.Process PBR> BOOTMBR> Install/Config> Close

This will build the MBR into the current VM.

Next, go to your VM software. In your VM add the ISO or windows recovery and boot into the media. Go to the recovery console and use bootrec /rebuildbcd to add any windows found.

Ensure that the controller is IDE, PAE/NX is selected and enable VTx (if intel. AMD-V if AMD) in your BIOS.


#11

All of these methods seem a bit convoluted, and not manageable on a large scale. Looking forward to an autonomous bootable VHD.


#12

It is a bit cumbersome since you will have to do it every time you launch a VM. It isn’t difficult though. The trade off here is, how often would you need to spin up a VM for DR? Not that often, it takes 8-15 minutes (with no issues) to boot up the VM using this method. While it is alot, it is the best option so far.

I too look forward to the day when we have autonomous bootable VHDs


#13

Thanks for the knowledge share. I was thinking at the very least DR testing and image verification.


#14

Thanks for sharing this!

So i guess using write mbr to restore the .mbr file directly into the vm doesn’t work in this way.

Will give Bootice a try.


#15

Anyone know if can do the same as above for incremental image backups?

How does incremental backup work? I don’t think that we can simply mount the vhd as above?


#16

Unfortunately you can’t. I avoid increments all together. I have other software running in the background for that (EaseUS and Aomei for incremental imaging) and Urbackup serves to boot up a VM in the event of a server outage. That’s it.


#17

I have added a tool to 1.4.9 now which writes multiple volume images and the master boot record into one disk image. See UrBackup Server and Client 1.4.9 .


#18

Thank you for adding this! I understand that there is also a new bug fix for image read ahead.

Can you please share which .cpp files were updated for the new image read ahead bug?


#19

I have tried the new 1.4.9 batch files to combine VHDs, but wasn’t able to boot from them using XenServer, Hyper-V, or VirtualBox. I eventually found a Sysinternals program called disk2vhd that will make a single VHD for all selected partitions, including that elusive System Reserved partition. It also supports the newer VHDX file format, but it does not support incremental images, or a nice dashboard for management and reporting, or space quotas, or image restoration options, or any of the other great features that UrBackup offers.
If it’s not one thing, it’s another, right?

I wrote a batch script for disk2vhd at GitHub/Linkz57 if you folks are interested. I gave the batch file to Windows Task Scheduler, and it’s been working reliably with Hyper-V for a few weeks now.
Now I use disk2vhd for C:\ and System Reserved, and I use UrBackup for incremental images of all other partitions and disks.

I bring this information and simple script to the UrBackup community as an offering of good will, and in hopes that I might make some requests.

UrBackup is a fantastic project, and hope it continues to grow.
Speaking of growth, I have been having an issue with the “global soft filesystem quota”, in that it doesn’t seem to be working for me (Odds are it’s because I’m an idiot and am using it wrong. Hopefully I’ve provided enough information below for those smarter than me to diagnose this issue). I have UrBackup saving everything to a dedicated 2.5 TB HDD and have set the UrBackup server’s global soft filesystem quota to 80%. a few weeks of backups later, and I find the disk is 80-some percent full. Section 10.1 of the manual says that quotas are enforced at night, so I wait about 15 hours and check the next morning, and the disk is 94% full and UrBackup is actively imaging a machine. There was enough free space in that remaining 6% for it to complete its image, in case that’s relevant. Most of my machines have passed their minimum image threshold of 4, so I feel that they should have been culled for space.
This is my first question: what can I do to ensure that the “global soft filesystem quota” is enforced?

Thankfully, the “Maximal number of incremental file backups” seems to be working, and I saw in the activity log that UrBackup had deleted the oldest incremental image of one of my machines (not the machine I caught being backed up into my remaining 6%).
Out of curiosity, I mounted the newest incremental image of the machine that had just surpassed its ‘maximal incremental backups’ in Hyper-V, booted it up (from disk2vhd’s image of C:\ ), and checked its D:\ (from UrBackup’s recently culled incremental images). I wanted to quickly test every file for accessibility, because I assumed that each incremental image consisted only of changes that occurred between the last image and itself, and as such referenced each previous incremental image, chain-linked all the way down to the most recent full disk image. I assumed that UrBackup deleting the first incremental image after my only full disk image would 1: break the chain in its last link before the full disk image (where I assume all files that have never changed reside), and 2: make unavailable the files (if any) that were only changed between the full image and that one deleted incremental image.
I figured that touch.exe v0.99 from Stephane Duguay at binarez would be the fastest way to check every file, and so I ran touch.exe -Rc D:* and it didn’t print any errors. Now I assume that either touch.exe was wrong/was used wrongly, or that magic is real.

This is my second question: how do incremental VHDs work?
The manual says that UrBackup uses hashes for comparison, but makes no mention of how it makes up for all of the unchanged data it didn’t bother to copy over. Is there something in the VHD’s header that specifies a name and path to other VHDs that contain its missing information?

Sorry for the long post, and thanks again for a great product.


#20

Can we revisit this? It’s a pretty critical service that I’m sure many would be interested in. I tried to use assemble_disk_image.bat to combine C,ESP,sysvol full images into one VHD for virtualization purposes. I’m getting the error:

2016-02-08 23:54:11: ERROR: NTFS magic wrong
2016-02-08 23:54:11: WARNING: Volume not an NTFS volume. Copying all blocks…
2016-02-08 23:54:11: Writing B:*full_path*\Image_C_160208-1219.vhd into output VHD…
2016-02-08 23:54:11: Optimized by only writing used NTFS sectors…
2016-02-08 23:54:11: ERROR: Trying to write beyond partition
Press any key to continue . . .

Any Ideas? Server 2.0.2 Beta

P.S. I’ve also tried creating a new VM with base install of windows identical of what I’m installing them mounting all drives into their respective drive letters via regedit, leaving the newly made mbr,sys, etc. intact. only changing c drive to the mounted VHD It ends up in a boot loop