VDI Corrupted but still intact

[PotMack]

I have a corrupted VDI file which became inaccessible after I saved my VM. I managed to copy the VDI file to a new location and tried to repair using the CloneVDI tool but this came back with 'Source has strange format or has been corrupted', which it has. The VDI file was a dynamically expanding volume initially set at 32GB but was about 3.23GB when it failed.

If I view the VDI file with a hex viewer, I can see that the first block of data to h6F0000 is all ZERO bytes. After that point it looks like the data is still there as I can see filenames, program descriptions and the usual file pointers.

Is there anyway I can a) recover the data that I can see, or b) reinitialise the disk with some missing data so that as least it's recognised?

Any help here most appreciated.

[mpack]

If CloneVDI does not offer to repair then it can't be repaired, except of course from a backup.

If you have lost the first 7MB of data then that means that the VDI header and block map has been lost, so the VDI blocks are now in random order. Also, the part of the drive that usually contains the entire filesystem has been destroyed. It is an ex-disk, it has ceased to be.

Sure, you could access the drive at a sector level and may recover data in 4K chunks, but in general you'd have no way to know where the data comes from, and there is a huge number of 4K clusters on a modern drive - I don't see this as a practical possiblity.

AFAIK, losing the first 7MB of a VDI is unheard of. It doesn't just "become inaccessible". There is no VirtualBox mechanism I know of that could do that, no matter how buggy it was (and I'm allowing that only for arguments sake - in fact I don't know of any bugs in this area): writing 7MB of zeros has to be done on purpose.

Are you sure this wasn't a snapshot? All of the "corruption" you describe would be normal in a snapshot. Not that it would matter much, since you can't recover data from lone snapshots either.

[PotMack]

Thanks for reply.

This drive was a 2nd drive added as SATA Port 2 (as D:\).

I was using the VM as usual with access to this drive and normally closed the VM and 'Saved the Machine State'. When I next came to use the VM, the SATA Port 2 reference for the drive was showing the name of the HDD Image with (inaccessible) written after it, and the VM would refuse to start citing the HDD as faulty.

Incidentally, the VirtualBox program was updated during the period prior to the failure; 6.1.4 from 6.1.2, but I can't see how that would affect a file held on a physically different drive.

The VM itself has never been snapshotted and I'm not sure what has caused this fault. I do have an earlier back up from the system but I was hoping that I could rescue some of the more useful files I created. I guess this is one of those learning situations (yet another one ) where regular backup are a must, especially with VM's.

[mpack]

You say 2nd drive, does this mean an external drive? I usually try to discourage people from running VMs from external drives, because they are notorious for this kind of failure.

[PotMack]

No not an external drive, but rather another VDI file created in the same directory as the main VM (C:\). In hindsight, it would probably have been prudent to partition the existing VDI to create the D:\ drive. Hey ho..

[mpack]

Oh, I see. Offhand I can't think of a reason why having more than one VDI in a VM should be any more reliable than having one larger VDI, if both scenarios cover about the same number of host sectors. As you've already said, a backup is the only sure way to avoid losing data.