Non-Persistent Disk - Recovery from redo log file

[Gaurav_Awasthi]

Hi,

We  have a situation where a disk was incorrectly configured as independent non-persistent .Disk setting was modified and made as dependent and as obvious changes were lost.

We need to recover files from a date when disk were still non-persistent . Now we have storage level snapshot and were able to get base VMDK and redo log file.

After registering the VM it does point to redo log which shows size of 15 GB but  inside the VM ,still we are seeing the old data from a date when disk were made non-peristent.

So the question s there a way to recover data using redo log file(non-persistent disk) and base VMDK if they are available from storage level snapshot

[Nawals]

Hi, Its not possible to recover it. Below explain about Non-Persistence Disk

Nonpersistent

Changes to disks in nonpersistent mode are not saved to the disks, but are lost when the virtual machine is powered off or reset.

Nonpersistent mode is convenient for people who always want to start with a virtual machine in the same state. Example uses include providing known environments for software test and technical support users as well as doing demonstrations of software. Any disk type can be used in nonpersistent mode.

If your virtual disks are in nonpersistent mode, you can take advantage of the repeatable resume feature, which allows you to save the current state of the virtual machine when you suspend it, then resume from the point at which you suspended it every time you start the virtual machine. For more information, see Resuming Virtual Machines Repeatedly from the Same Point.

VMware Workstation only reads the virtual disk file. Any writes to the virtual disk are actually written to a redo-log file that is deleted when you power off or reset the virtual machine. This is similar to the redo-log files used with disks in undoable mode.

While you are running the virtual machine, any blocks that have been modified and written to the redo-log file are read from the redo-log file instead of the disk files. When the virtual machine is powered off or reset, the redo-log file is discarded

Redo-Log Files

Log files save blocks that the virtual machine modifies while the it is running. The log file for a disk in nonpersistent mode is not saved when the virtual machine is powered off or reset, while the log file for a disk in undoable mode is saved. The log file for disks in undoable mode is called the redo log, and the user decides whether the redo-log file should be saved or not.

The redo-log file for a virtual disk called vm is called vm.vmdk.REDO. If the virtual disk is larger than 2GB, it is divided into sets of 2GB disk files named vm.vmdk, vm-02.vmdk, vm-03.vmdk and so on; its redo-log files are called vm.vmdk.REDO, vm-02.vmdk.REDO, vm-03.vmdk.REDO and so on.

You can choose the location where these redo logs are stored. By default, the redo logs for disks in undoable mode are stored in the same directory as the .vmdk file that contains the virtual machine configuration. Redo logs for disks in nonpersistent mode are stored in your host's temp directory by default. In the case of plain disks, filename.pln.REDO is created by default in the same directory as the .pln file.

[a_p_]

Which files were you able to recover from the storage snapshot. Please post a complete list including sizes, time stamps, etc. (e.g. the output of ls -lisa).

In addition to this compress/zip the VM's configuration (.vmx) as well as the .vmdk descriptor/header files (the ones without flat|delta|sesparse in their file names), and attach the .zip archive to your next reply.

André

[Gaurav_Awasthi · Accepted solution]

I was able to recover the data using redo log file .This is a little non-standard and probably an unsupported way of doing it but it helped.

Redo log files behave pretty much the same way as  snapshot disk (only diff being that if you turn off or reset the VM ,changes are discarded) so using following steps we were able to recover the data.

1.Mount the backup luns.

2.Edit redo log file names to give them name format of a snapshot disk. Descriptor file becomes XYZ_1-000001.vmdk and data vmdk becomes XYZ_1-000001-delta.vmdk

3.Make changes to the descriptor file ,XYZ_1-000001.vmdk, to ensure parentFileNameHint is pointing to base vmdk (present in restored LUN) , has correct parent CID of base vmdk and after extent descriptor it has correct delta file name .Something like below

======================================

# Disk DescriptorFile

version=1

encoding="UTF-8"

CID=7f3a1e17

parentCID=19741890  --> this is of base vmdk

createType="vmfsSparse"

parentFileNameHint="XYZ_1.vmdk" -- >path to base vmdk

# Extent description

RW 31457280 VMFSSPARSE "XYZ_1-000001-delta.vmdk" -- > pointing to delta file

==================================================

4.use vmkfstools -e XYZ_1-000001.vmdk to ensure disk chain is consistent.

5.Edit the vmx file to comment out "independent-nonpersistent" for the disk  value ,point scsiX:Y.name (where X is controller and Y is bus number)  to XYZ_1-000001.vmdk and blank out the redo entry - scsiX:Y.redo=""

6.Register the VM and Power on

For VM now it is similar to recovering from a crash with unconsolidated snapshot

We also had a P1 case raised with VMware however I was surprised that the L3 engineer didn't make any effort at all and  refused to even try anything stating that redo files are like cache/swap files (which is not right ) data from which  is unrecoverable.