Corrupted VDI after backup restore

[Overlord]

Hi folks!
I'm experiencing a strange problem on my host, which runs 9 VMs Windows, Linux, MS-DOS and Xenserver.
Yesterday due to O.S malfunction, I had to restore a full hard disk backup made with Acronis True Image; the restore procedure completed succesfully and the whole host O.S is working properly except one thing, some VDIs belonging to my VMs aren't recognized anymore.
I disconnected the VDIs and tried to reconnect them, but it failed with the following error:

Code: Select all

Apertura del file del file di immagine del disco K:\RESTORE\Windows 10\Windows 10.vdi non riuscita.

Could not get the storage format of the medium 'K:\RESTORE\Windows 10\Windows 10.vdi' (VERR_NOT_SUPPORTED).

Codice 'uscita: VBOX_E_IPRT_ERROR (0x80BB0005)
Componente: MediumWrap
Interfaccia: IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda}
Chiamante: IVirtualBox {0169423f-46b4-cde9-91af-1e9d5b6cd945}
RC Chiamante: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)

(this error comes from Windows 10 VDI but its the same with all corrupted virtual disks).

I checked the physical HDDs involved and both didn't report any error, even the backup passed the integrity check.
I think that this data corruption has been caused by a corrupted Acronis boot disk, from which I made the backup.

Now, I opened these VDIs with an hex editor and I found that the header is missing, the first 72 bytes are empty; even CloneVDI didn't recognise the VDI as disk image.
I tried to copy the first 72 bytes from a good VDI but the same error appears.

Is there any chance to recover them?

[mpack]

Pick one VDI, use your hex editor to save the first 2MB to a binary file, zip that file up and attach here. We'll see if the data is recoverable.

If the only thing wrong was the first 72 bytes zeroed, then replacing that should have fixed the problem. But, I can't imagine what corruption mechanism would corrupt only the first 72 bytes of a backup - the first 72 bytes of a VDI has no special meaning to any software except VirtualBox, which presumably had no access to the backups.

If entire VDI is filled with zeros then that I can understand, and there's no way to recover from it.

An entire VDI filled with zeroes would be symptomatic of network problems, specifically not being able to cope with very large files.

[Overlord]

Here's the zip file you requested, first 2 MB are zeroed.
First data available is at offset 0x200000, I exported that and added to the zip file too.

From what you say seems that I've no chance to recover my VDIs

[mpack]

Hmm. I asked for 2MB, you gave me 2K. I need to see the second 1MB.

But no, it doesn't look good. The "First available data" that you gave me is the master boot sector (MBR). If everything before that is zero then it means that you've lost both the header and the block table. The MBR being present indicates that there is probably data on the disk, but without the block table it probably isn't recoverable.

Some additional data would be useful to finally decide if anything can be done. Please take care to provide exactly what I ask for :-

• The entire first 2MB (2097152 bytes) of the VDI, zipped.
• The logical (maximum) size of the VDI disk.
• Was the VDI fixed size or dynamic?
• The precise (to the byte) current size of the VDI file.
• Was snapshots used with this VDI?
• Was this still the Windows 10 VDI?

[mpack]

Incidentally, I doubt that this could be caused by an corrupted Acronis boot disk. If the software is corrupted it will either fail to boot, or crash on loading or while working. It will not appear to carry out its work successfully, except the data is all zero. That would be symptomatic of a bad media, or network problems (depending on what the backup target was).

If the entire file had been zero then I'd have looked for an option in Acronis to ignore huge files. But, your file does not appear to be wholly zero, which means its a media problem (in the loosest sense), not a deliberate act or software corruption.

[Overlord]

My fault I'm sorry, this is my first time using an hex editor.
Yes, this is Windows 10 VDI I mentioned previously; here's the new exported file, I hope I did right.

Virtual disk details:

- VDI disk size is 25 GB
- Dynamic storage
- Actual VDI file size: 11,4 GB (12.337.545.216 byte)
- Before VDI corruption there wasn't any snapshot available, but I used them in the past; all snapshots has been deleted few days before data corruption.

If the software is corrupted it will either fail to boot, or crash on loading or while working

This is the exact behavior I was experiencing, before completing the backup succesfully the live O.S crashed and tried to dump the memory; I had to reboot and start again the backup process.
I'm currently investigating the problem also with Acronis support, it turned out to be a AHCI issue; the related kernel module is not working as expected and sometimes ignored the CRC during data transfer.

[Martin]

Do you have an earlier backup from before the crash?

[mpack]

Well, it's a good thing that I didn't take your word for it, because the second 1MB of your file is not zeros at all - it contains an intact block map, meaning that this file is quite probably recoverable. You need to practice your arithmetic man, learn the difference between 1000 and 1000000!

Details of fix to follow.

Edit:  I'm not seeing a block map for a 25GB drive here, I'm seeing one for a 16GB drive. So, either there is more data zeroing going on (and that doesn't look likely), or you gave me more incorrect information. Are you sure it was a 25GB drive, not 16GB? I would have thought 16GB was a tad small for a Windows 10 drive.

[mpack]

Ok, here's the fix.

1. If you have not already done so, make a backup copy of the "Window 10.vdi" file.
2. Next, create a new dummy VM. The details don't matter, it's only the VDI creation step that we care about.
3. When you get to the disk creation step, select dynamic VDI with a size which is exactly 16GB. Be precise, i.e. type the size in.
4. Shut down VirtualBox, and use FrHed to copy the first 1K bytes from the new VDI to your damaged VDI.
5. You can now close the newly created VDI - we no longer need it.
6. In the damaged VDI (which now has a new header), edit the 4 bytes at offset 388 (0x184) to be "F4 2D 00 00".
7. Save changes and close FrHed.

The new VDI has the wrong UUIDs in the header - we could fix that, but it would be complicated. Better just to unmount the bad VDI from the VM, and remount the repaired one. NOTE: you must delete the dummy VM before adding the repaired VDI, or VirtualBox will complain about two VDIs having the same UUID.

The VM should then be working.

[Overlord]

Do you have an earlier backup from before the crash?

Unfortunately no, the corrupted backup is the only one I have. I made a full host backup before updating it to Windows 10, then I restored all VMs from that backup.
After restoring my data I noticed the virtual disk corruption.

Ok, here's the fix.

If you have not already done so, make a backup copy of the "Window 10.vdi" file.
Next, create a new dummy VM. The details don't matter, it's only the VDI creation step that we care about.
When you get to the disk creation step, select dynamic VDI with a size which is exactly 16GB. Be precise, i.e. type the size in.
Shut down VirtualBox, and use FrHed to copy the first 1K bytes from the new VDI to your damaged VDI.
You can now close the newly created VDI - we no longer need it.
In the damaged VDI (which now has a new header), edit the 4 bytes at offset 388 (0x184) to be "F4 2D 00 00".
Save changes and close FrHed.


The new VDI has the wrong UUIDs in the header - we could fix that, but it would be complicated. Better just to unmount the bad VDI from the VM, and remount the repaired one. NOTE: you must delete the dummy VM before adding the repaired VDI, or VirtualBox will complain about two VDIs having the same UUID.

The VM should then be working.

Thank you mpack, will try that this evening if I will manage to do it.
I will post the results here

About the VDI size, when I created the VM it was set to 25 GB, now I'm trying to understand if it has been resized.
The physical host is a shared workstation, it's possibile that someone shrunk it to regain some HDD space.

[mpack]

VirtualBox has no facility to let you shrink a virtual drive's capacity, so that wouldn't be it.

[Overlord]

Here we have the results:

I applied the solution provided by mpack and I got access to the Windows 10 VDI, but the bootloader resulted to be corrupted.
I tried to restore it but Windows Recovery Environment failed that operation and corrupted the partition table, so I copied again the VDI from its backup and restored the header again.
Without restoring the bootloader I can't boot the O.S but I was able to recover some essential configuration files at least.
Actually I reinstalled the VM and my services are running on the new environment.

Thank you very much for your help!

[mpack]

I assume it wouldn't boot because the UUID had changed, so the boot manager couldn't find the boot partition. That probably could have been fixed by changing the boot config, but no matter. I'd have to do research on how to edit a W10 boot config anyway.

[Overlord]

It's possible but I can't say for sure, the VM rebooted few seconds after the BSOD without letting me check the stop code.
Anyway for diagnostic purposes, I will restore the corrupted VDI from my backup as soon as I can, and I'll try to fix the boot problem.
I will skip the startup repair procedure and run from the recovery environment

Code: Select all

bootrec /fixmbr

That will be enough I think

[mpack]

No, fixmbr will not do it. There was nothing wrong with your MBR.

There will be a config script inside the small boot manager partition which tells it to boot the OS found in <drive-uuid><partition id>. [*] But, BOOTMGR can't find this volume because the drive UUID has changed. The only fixes are to patch the drive UUID in the VDI header, or change the boot manager config.

[*] Windows since Win7 does not require the boot drive to contain the system volume.

There's no need for you to investigate this on my account. The procedure you already used is enough to recover your files. and I'm already pretty sure about the rest.