Why can't we back up snapshots too?

[bp2008]

When I was evaluating HPE VM Explorer (free version of HPE VM Explorer, with free ESXi), it was able to back up a VM that had a pre-existing snapshot. The snapshot survived the backup process and when I checked the output directory the snapshot was there too. Only problem was that scheduled backups don't work in their free version and they want a lot of money for a license.

So why does ghettoVCB have to consolidate (a.k.a. delete) all previously existing snapshots before backing up a VM? If HPE VM Explorer can back up the snapshots somehow (I don't know how), shouldn't ghettoVCB be able to do the same? Or at least, shouldn't ghettoVCB be able to back up from the latest pre-existing snapshot without consolidating/deleting them? https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1027876

Sorry if the answers are obvious; I haven't been using ESXi for long and I still have to google for instructions for pretty much everything that isn't exposed in the GUI.

[ctsde-markus]

That would be a great feature!

While you are at it, can you also change the logic when POWER_VM_DOWN_BEFORE_BACKUP=1 to shutdown the VM, take a snapshot, POWER IT ON AGAIN and after that start the backup. That would reduce the downtime to 2-5 minutes instead of how long it takes to do the actual backup while the backup is still in a consistant state.

Thanks!

[lamw]

Thanks for the comment.

First off, please keep in mind that ghettoVCB is a completely free solution that I've created in my spare time. There are and will be limitations, some of which are inherent to the methods I've used given this was created almost 9yrs ago. As such, trying to compare ghettoVCB with other backup solutions which are able to take advantage of more efficient methods for backing up a VM isn't really fair (API vs ESXi Shell commands ...)

I've personally said this many times in the past, snapshots are not backups. Although some vendors allow you to retain the snapshot chain, it is not a trivial thing to manage nor it is something ghettoVCB can even implement today without major implications. If this is something that is unacceptable, than you are more than welcome to look at other paid solutions which don't have such limitations. ghettoVCB is and has always been a very simple backup solution that users can easily deploy in their env.

[bp2008]

Ah. We do appreciate ghettoVCB for what it is, and if we find we can't live without persistent snapshots then we'll just have to spend money.

[hi-ko]

just to understand the issue: Why not creating a new, addtional snapshot following a distinct name pattern (e.g. ghettoVCB-${TIMESTAMP}) which will be removed after successfull clone/backup?

[ctsde-markus]

To my knowledge you can't backup a snapshot other than the oldest one with vmkfstools.

[hi-ko]

No, you could clone a vmdk from any snapshot. From 1027876:

vmkfstools -i /vmfs/volumes/Storage1/examplevm/examplevm-000003.vmdk /vmfs/volumes/Storage2/examplevm_clone.vmdk

So for my understanding we just need to extend the shell script logic to find out the latest one(s) for the backup, right?

[ctsde-markus]

Interesting! Maybe that was an old limitation back in the days.

I'll test this and i may be tempted to even make a pull request some day for that (given it really works that way). But don't hold your breath!

A long-time TODO of mine is trying to change the shutdown, take snapshot and backup logic to shutdown, take snapshot, START VM, backup. This way downtimes for "cold" backups would be like 5 minutes and not the whole time the actual backup takes.

[ctsde-markus]

Oh dear! I think i know why this isn't implemented yet.

Can anyone write (or give hints) a /bin/sh compatible function to parse such a result, i'd need the "Snapshot Id" number from a snapshot named "ghettoVCB-$something" as return value:

# vim-cmd vmsvc/snapshot.get 27
Get Snapshot:
|-ROOT
--Snapshot Name        : v1
--Snapshot Id        : 1
--Snapshot Desciption  : Version 1: Starting point
--Snapshot Created On  : 1/18/2019 10:28:17
--Snapshot State       : powered off
--|-CHILD
----Snapshot Name        : v2
----Snapshot Id        : 2
----Snapshot Desciption  : Version 2 - NOTES.snapshot with first line "Version 2" created
----Snapshot Created On  : 1/18/2019 10:33:35
----Snapshot State       : powered off
----|-CHILD
------Snapshot Name        : v3
------Snapshot Id        : 3
------Snapshot Desciption  : Version 3 - NOTES.snapshot contains a second line "Version 3"

tricky! The "Desciption" can have multiple lines...
------Snapshot Created On  : 1/18/2019 10:47:46
------Snapshot State       : powered off

Edit: parsing the .vmsd file is way easier (but still a challenge) so forget the above.

[hi-ko]

my first shot:

VMID=116
# create a snapshot for testing ...
vim-cmd vmsvc/snapshot.create $VMID TestBackup "Testbackup-$(date)" 0 0

SNAP_LIST=$(vim-cmd vmsvc/snapshot.get $VMID)
# extract the beginning dashes from the last line
SNAP_PREFIX=$(echo "$SNAP_LIST"|tail -1|sed -e 's/\([-]*\).*/\1/') 
SNAP_ID=$(echo "$SNAP_LIST"|grep -- "$SNAP_PREFIX" | grep 'Snapshot Id')
SNAP_ID=${SNAP_ID#*: }

echo $SNAP_ID

[hi-ko]

To identify the vmdks to clone you find everthing in the $VM.vmsd file:

SNAP_NS=$(grep "snapshot.*.uid = \"$SNAP_ID\"" $VM.vmsd)
SNAP_NS=${SNAP_NS%%.*}
VMDKLIST=$(grep "$SNAP_NS" $VM.vmsd | grep 'disk.*.fileName'|sed -e 's/.*\.fileName \= \"\(.*\)\"/\1/')