[Solved] Corrupted VDI after host crash: VERR_VD_VDI_INVALID_HEADER

[doof]

After my Windows 8.1 host crashed, my vdi file is completely empty. 0 bytes.

My vagrant VBox VM was up and running but not doing anything at the time, iirc.

Other vdi files in the same folder are "last modified" months ago. I'm bewildered and wondering if perhaps the data is stored elsewhere, despite the "last modified" dates.

After the host crash, chkdsk was performed automatically on reboot. I didn't notice any failures there. Surprised that my SSD would have such an issue (Samsung 860 EVO 2TB, about 2 years old).


Anyway, I tried to start up my VM with vagrant and got this:

Code: Select all

doof@oldcomputer MINGW64 ~/projects/ubuntu20_test
$ vagrant up
Bringing machine 'ubuntufocal20' up with 'virtualbox' provider...
==> ubuntufocal20: Checking if box 'bento/ubuntu-20.04' version '202010.24.0' is up to date...
==> ubuntufocal20: Clearing any previously set forwarded ports...
==> ubuntufocal20: Clearing any previously set network interfaces...
==> ubuntufocal20: Preparing network interfaces based on configuration...
    ubuntufocal20: Adapter 1: nat
    ubuntufocal20: Adapter 2: bridged
==> ubuntufocal20: Forwarding ports...
    ubuntufocal20: 22 (guest) => 2222 (host) (adapter 1)
==> ubuntufocal20: Running 'pre-boot' VM customizations...
==> ubuntufocal20: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "665e5d19-7bb4-421c-8f83-b9d4c1350594", "--type", "headless"]

Stderr: VBoxManage.exe: error: Could not open the medium 'C:\Users\doof\VirtualBox VMs\ubuntufocal\Snapshots\{8b4af608-5d54-44bf-89e5-38996cb5a31d}.vdi'.
VBoxManage.exe: error: VDI: error reading pre-header in 'C:\Users\doof\VirtualBox VMs\ubuntufocal\Snapshots\{8b4af608-5d54-44bf-89e5-38996cb5a31d}.vdi' (VERR_EOF).
VBoxManage.exe: error: VD: error VERR_VD_VDI_INVALID_HEADER opening image file 'C:\Users\doof\VirtualBox VMs\ubuntufocal\Snapshots\{8b4af608-5d54-44bf-89e5-38996cb5a31d}.vdi' (VERR_VD_VDI_INVALID_HEADER)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MediumWrap, interface IMedium

Here's a screenshot showing my 0 byte vdi (it is completely empty).

VBox Snapshots

ubuntu_focal_snapshots.jpg (40.65 KiB) Viewed 1427 times

Here's a look at my virtualbox gui. Not sure why my vdi is in the ubuntufocal\Snapshots\ folder when I'm launching an ubuntu20_test machine. But all the other snapshots are old.

ubntu_focal_based_machines_snapshots.jpg (45.64 KiB) Viewed 1427 times

Is my disk completely destroyed?
I don't have backups of the disk itself. The data loss isn't a tremendous problem. But it will likely take me hours to get the machine back up to date from old snapshots (if they even work).

[scottgus1]

The dead file is a snapshot disk file, which is a changed sector file, so it must be present to run the VM in its last known state.

Not sure why my vdi is in the ubuntufocal\Snapshots\ folder

This would be reasonable if the test VM were a linked clone, or if the Snapshots folder of the test VM were redirected to the ubuntufocal folder. Other reasons might have caused this that I'm unaware of.

Is my disk completely destroyed?

This one is.

it will likely take me hours to get the machine back up to date from old snapshots (if they even work).

Snapshots aren't backups, they're changed disk sectors (and VM 'hardware' changes). You can't 'load a snapshot' to restore missing data. You'll need a real backup to get the file back in place or restore the data that was in the missing file.

You can try Mpack's CloneVDI to clone the most recent snapshot disk file that CloneVDI doesn't error over, then build a new VM around the clone disk file.

[doof]

The dead file is a snapshot disk file, which is a changed sector file, so it must be present to run the VM in its last known state.

Not sure why my vdi is in the ubuntufocal\Snapshots\ folder

This would be reasonable if the test VM were a linked clone, or if the Snapshots folder of the test VM were redirected to the ubuntufocal folder. Other reasons might have caused this that I'm unaware of.

It may have been.

As I understand it, VM snapshots are like "diffs" from the last complete machine image?
Since I was able to restore my November snapshot from the VBox GUI without any issue, I guess that means there was a full backup behind it that was uncorrupted.

It did seem to restore files. My MySQL database was in its late-November state, and I had to re-run update scripts from that point on to bring it back up to date. But I would have a hard time knowing if all files were restored perfectly.

Snapshots aren't backups, they're changed disk sectors (and VM 'hardware' changes). You can't 'load a snapshot' to restore missing data. You'll need a real backup to get the file back in place or restore the data that was in the missing file.

You can try Mpack's CloneVDI to clone the most recent snapshot disk file that CloneVDI doesn't error over, then build a new VM around the clone disk file.

Thanks!

[fth0]

As I understand it, VM snapshots are like "diffs" from the last complete machine image?

Not exactly.

To get the terminology right, distinguish between the Virtual Machine (VM, *.vbox) and the Virtual Disk Image (VDI, *.vdi). The former is the equivalent of a PC, the latter is the equivalent of the PC's hard disk.

When you create a new VM, the VDI is a base image, which is read from and written to. When you create a snapshot, the base image is frozen (read-only) and a new differencing image is created, which is then written to. If you create more snapshots later on, you'll end up with one base image and multiple differencing images, where the latest image is written to, and all images are read from. You can read more about it in 5.5. Differencing Images.

Guessing from your screenshot all three snapshots should be ok, only the current differencing image has been corrupted, and you can revert to the latest snapshot from November 29th.

[mpack]

I guess that means there was a full backup behind it that was uncorrupted.

You had a previous guest state to revert to, not a backup.

A backup is when you copy data so that losing one only of the copies means you can recover the data from the other copy. A snapshot does no such thing: the old state is frozen, and a new state begins to accumulate - but no copy is made of the old state. Loss of a single file from the chain results in unrecoverable data loss of that state and all the newer states that depend on it. That's a pretty shitty property for a "backup".

I encourage you to make real backups by periodically copying the VM folder to offline storage: and stop using the inherently dangerous snapshots feature.