Bare metal restore failure

[chrisr85]

I'm in the process of testing out various scenarios using the Beta Veeam for Windows Agent. One specific scenario I'm getting hung up on is related to doing a bare metal restore to dissimilar hardware.

I have a case open for this issue, it is 02084091.

My issue seems to be surrounding restoring my backup to a system that has a smaller hard drive than the original system that was backed up. This is a quick summary of steps I've taken to get to this point.
1.) Load USB bootable Veeam Recovery Media environment on target system and start the bare metal recovery
2.) Connect to storage that contains my source backup to restore from and select restore point to restore to
3.) Select Entire computer as the restore mode, receive error that it is unable to auto-match disks and to use manual restore more
4.) Change to Manual restore (advanced) mode
5.) Disk mapping is listed with the 100MB Window Partition which when checked shows the restore layout as "Automatic". It also lists the System (C:) volume with a capacity of 232.8GB, which when checked gives me a warning stating "Cannot find original disk layout. Do you want to partition this disk manually?"
6.) I select yes to the warning prompt and a Disk Mapping window appears, which shows the 100MB Windows Volume marked as a Restored Volume and has the remaining portion of the 120GB drive available. I right click on the remaining portion of the drive and select Restore > Disk 0 > System (C:) (232.8GB). I then get prompted with "This volume is larger than the specified destination. Shrink the volume to fit the destination? I respond yes.
7.) It then goes to a state of "Analyzing Volume's contents"... and then shows that the System (C:) volume is allocated to the remaining space.
8.) Once everything finishes I move to the summary page where I start the restore

The restore kicks off at this point and then part way through I receive an error about shrinking the drive. This is a link to a screenshot of the restore window. The error code listed at the end of both of the errors lines is 0x80042574.

Any help on this issue would be appreciated.

[chrisr85]

Received some good info from the Veeam support team, that I believe to be the answer I was looking for.

It seems that the issue is related to unmovable files.
Indeed, you are able to restore backups to a volume smaller than the source, but there are some limitations.
The shrink process is performed by Windows environment, not by Veeam Agent itself.
In some cases Windows is unable to shrink volume due to unmovable files, despite the fact, there is enough free space.
You can find the description of this limitation by the following links:

https://technet.microsoft.com/en-us/lib ... s.11).aspx
https://www.quora.com/How-can-I-increas ... hard-drive

If you were to try shrinking the volume on the original OS, you would most likely run into the same issue.

As a next step I'm going to perform the same recovery to a system with enough space to prevent the volume shrink and see if everything runs smoothly.

[Mike Resseler]

Chris,

Thanks for coming back to us with the answer. There are indeed sometimes unmovable files (for the older guys and girls among us, they certainly will remember defragging systems with unmovable files that always remained somewhere

Please keep us updated about your next test

Cheers
Mike

[alxrvm]

Seriously, this is very limiting as a choice for backup and restoration.

Certainly it's not possible to go back and shrink the original volume first then recreate the VEEAM backup and restore to the smaller drive.

I thought VEEAM was a backup and recovery solution!? Not always feasible or required to use the exact same drive when bare metal restore.

Another nail in the coffin of using VEEAM for a backup solution.

[Mike Resseler]

Hi Alex,

I am not sure I understand what you mean. You can restore to a smaller drive. This was a different case and was a restore to an existing volume and then the OP wanted to shrink that one.

What exactly did you want to achieve?

Thanks
Mike

[NickViz1]

Hi Mike,

I'll try to guess - it seems that Veeam implemented a block level whole system backup. However, in some cases it's more practical to have file level one - like to make WIM file with DISM + all boot configuration (BCD + recovery partition, etc). That allows you to restore on arbitrary size volume, eliminates fragmentation, migrate between GPT and MBR layouts, probably even allows to restore on different FS (RaiserFS? )

If you remember Norton Ghost - it worked like that - backup files, attributes, streams, links, etc as a separate entities. And then format volume and restore it one by one. Current alternative is DISM, but it doesn't save boot environment, so after restore you need to do some manual tricks to finally boot.

I don't know the reasons behind Veeam's decision, I guess they were somehow justified, but right now it's a limitation that you need to keep in mind. I don't agree with Alex that VEW is not a backup solution - it is... just with a nuance (C).

Cheers

[Mike Resseler]

Hmmm,

I think most of this is possible, especially since you can go really deep and dirty with the volumes during BMR: https://helpcenter.veeam.com/docs/agent ... tml?ver=20

If you really want, you can also boot from the recovery media, go to the tools and through command prompt and diskpart cleanup everything what is necessary and make volumes there that can be used to restore (as long as obviously the size of the new volume is bigger than the volume that needs to be restored )

I am just trying to imagine now what we are exactly lacking and how your described scenario cannot be achieved. (Maybe I need a few additional coffee's to figure it out )