Access data from a possibly corrupt vdmk delta file

[chinggay]

The issue started when we tried to delete a snapshot and it timed out during the process. It might not have been able to fully consolidate to the baseline. Lost the vmdk files but followed the steps in following KB to recreate vmdk for flat and for a snapshot:

https://kb.vmware.com/s/article/1002511  https://kb.vmware.com/s/article/1026353

Now when booting up, it drops into Busybox/initramfs which leads me to believe that the disk is corrupted. 

Also getting an alarm message saying Virtual machine disks consolidation needed.

I would be extremely grateful if someone can show me how to mount the snapshot disk to at least access the data if this virtual machine is now hosed. 

[bmcb555]

I'd something similar in a cyber attack and was able to get the data off the disks following the below

https://enes.dev/

Now the guide is for recovering off flat files but you can follow the process from "06/02/2023 - UPDATE!" Guides you through mounting using the software and pulling it off.

[a_p_]

According to the file listing, the VM has two snapshots, but you've recreated the descriptor for just one of them. Therefore I assume that the .vmdk files have not been chained in the correct order.

To find out what can be done. please compress/zip all of the VM's files except for the flat, delta, ctk, and .nvram files, and attach the .zip archive to your next reply.

In addition to the files, please post the output of df -h, and ls -lisa (from within the VM's folder).

André

[chinggay]

Thank you so much for your time.

I have since also attempted to recreate a descriptor file for 00001 delta but still got busybox on boot. I have deleted it. 

[a_p_ · Accepted solution]

The .log files have unfortunately been overwritten, i.e. do not contain details about the previous state. So these are not helpful.
Assuming that the snapshot chain corresponds to the snapshots file names, I modified the attached .vmdk descriptor files, so that the chain is VDB2-000002.vmdk -> VDB2-000001.vmdk -> VDB2.vmdk.

What you may do is to:

1. extract the attached archive
2. upload (overwrite) the 3 .vmdk descriptor files to the VM's folder on the datastore
3. delete the VDB2-000002-ctk.vmdk file

After this, and before powering on the VM, I recommend that you create another VM snapshot, so that the current files won't get modified.

André

[chinggay]

It successfully booted up after following your steps. I did make a snapshot before powering on. 

I cant thank you enough!