snapshots no problem anymore?

[bc1000]

Hi, I am a bit confused, because I installed actual master on ESX 6.5 (free) and backing up some VMs. Some of them have snapshots. This is also detected in "dryrun" and therefore skipped. But if I run a normal backup of all VMs, really all VMs are backed up. So I checked these VMs and also restored one of them and they look good. Of course in the target/restored VM there is no snapshot anymore, but I have an actual backup.

The source VMs still has all the snapshots.

Is this behaviour normal and can someone reproduce?

dryrun: 2017-10-16 12:49:40 -- dryrun: ############################################### 2017-10-16 12:49:40 -- dryrun: Virtual Machine: XXXXX 2017-10-16 12:49:40 -- dryrun: VM_ID: 12 2017-10-16 12:49:40 -- dryrun: VMX_PATH: /vmfs/volumes/XXXXX/xxxxxx/xxxxxx.vmx 2017-10-16 12:49:40 -- dryrun: VMX_DIR: /vmfs/volumes/XXXXXX/xxxxxx 2017-10-16 12:49:40 -- dryrun: VMX_CONF: xxxxxx/xxxxxx.vmx 2017-10-16 12:49:40 -- dryrun: VMFS_VOLUME: XXXXXXXXXXX 2017-10-16 12:49:40 -- dryrun: VMDK(s): 2017-10-16 12:49:40 -- dryrun: xxxxxx_1-000001.vmdk 0 GB 2017-10-16 12:49:40 -- dryrun: xxxxxx-000001.vmdk 0 GB 2017-10-16 12:49:40 -- dryrun: INDEPENDENT VMDK(s): 2017-10-16 12:49:40 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 0 GB 2017-10-16 12:49:40 -- dryrun: THIS VIRTUAL MACHINE WILL NOT BE BACKED UP DUE TO EMPTY VMDK LIST! 2017-10-16 12:49:40 -- dryrun: ###############################################

normal run: 2017-10-16 12:51:08 -- info: Initiate backup for xxxxxx 2017-10-16 12:51:08 -- info: Creating Snapshot "ghettoVCB-snapshot-2017-10-16" for xxxxxx 2017-10-16 12:51:09 -- debug: Waiting for snapshot "ghettoVCB-snapshot-2017-10-16" to be created 2017-10-16 12:51:09 -- debug: Snapshot timeout set to: 900 seconds 2017-10-16 12:51:09 -- debug: findVMDK() - Searching for VMDK: "xxxxxx_1-000001.vmdk" to backup 2017-10-16 12:51:10 -- debug: /sbin/vmkfstools -i "/vmfs/volumes/XXXXXX/xxxxxx/xxxxxx_1-000001.vmdk" -a "" -d "thin" "/vmfs/volumes/XXXXXX/Backup/xxxxxx/xxxxxx-2017-10-16_12-50-25/xxxxx_1-000001.vmdk" Option --adaptertype is deprecated and hence will be ignored Destination disk format: VMFS thin-provisioned Cloning disk '/vmfs/volumes/XXXXXX/xxxxxx/xxxxxx_1-000001.vmdk'... Clone: 100% done. 2017-10-16 12:56:46 -- debug: findVMDK() - Searching for VMDK: "xxxxxx-000001.vmdk" to backup 2017-10-16 12:56:47 -- debug: /sbin/vmkfstools -i "/vmfs/volumes/XXXXXX/xxxxxx/xxxxxx-000001.vmdk" -a "" -d "thin" "/vmfs/volumes/XXXXXX/Backup/xxxxxx/xxxxxx-2017-10-16_12-50-25/sp2010-000001.vmdk" Option --adaptertype is deprecated and hence will be ignored Destination disk format: VMFS thin-provisioned Cloning disk '/vmfs/volumes/XXXXXX/xxxxx/xxxxxx-000001.vmdk'... Clone: 9% done..

[woogerboy21]

Taking a look at the code (and others more familiar with it can probably double check this) it appears the script does the commands ls "${VMX_DIR}" | grep -q "\-delta\.vmdk" to identify if the VM has pre-existing snapshots and if so then it errors out.

If you are using VMFS6 (or a few other criteria like the VMs disk is larger than 2TB) the SEsparse method for snapshots are used over VMFSsparse. When this method is used the file names actually have a different naming convention and not -delta.vmdk . Thus every check that is performed for previous snapshots would return a VM does not contain any snapshots.

This is probably something that needs looked into as it could potentially cause problems. One other thing to mention, taking backups of VMs with pre-existing snapshots and skipping the collapsing of the existing snapshots could result in a backup of a VM showing successful but you ending up with an older version of the VM than what may be currently operating. Since the script knows almost nothing about the current state of the VM in a snapshot tree, in this condition you are backing up the vmdk content prior to the first snapshot taken. And depending on how much snapshots are abused you may be talking days if not weeks old state.

[lamw]

Related/Dupe of https://github.com/lamw/ghettoVCB/issues/57

[sackofspuds]

This still seems to be a problem.

As woogerboy21 said over 3 years ago, the snapshot format on VMFS6 datastores is SEsparse. The snapshot file seems to use this naming convention: mymachine-000001-sesparse.vmdk