Why are snapshots considered as temporary backups not real backups?

Question

I am using VMware ESXi. In our team we use to provide snapshots for long term backup.

Then we faced issues like memory spillover and the server got hang up.

I started reading in VMware knowledgebase articles and everywhere. Everywhere it was recommended not to have snapshots for a long time.

Even VMware advised to keep snapshots for maximum of three days.

But our team kept asking us to have at least two permanent snapshots (till deleting the VM). Sometimes we may use the VM for a year).

1. one snapshot is for fresh machine state. (So when we complete testing an application, we will revert back to fresh state and install another application) (If I did not allow that, I may often need to host the VM.)

2. Next snapshot for keeping the VM in some state (maybe they would have found an issue and keep that state for some time. Or they may install prerequisites for the application and keep the machine ready for testing.)

Logically, their needs seems to be fair. But if I allow that, I am to permit them to hold the snapshots for long time. We are not using our VM as a mail server or database server.

Why is keeping snapshots for long time having an adverse effect?

Why are snapshots considered as temporary backups, not real backups?

Answer 1

When a VM has an active snapshot, its virtual disk I/O is not performed on the VM's actual .VMDK files, but instead they are kept unchanged, and whatever changes in the VM is written to different physical files; this allows for the recovery of the previous VM state, but has three important side effects:

• Disk I/O for the VM is much slower.
• Those "delta" files keep growing over time, as more and more disk I/O is performed by the VM.
• When the snapshot is removed, the changes stored in the "delta" files have to be merged back into the main .VMDK files, and this is is very slow and time consuming if the snapshot has been active for a long time.

It is indeed better to not keep active snapshots for a long time. If you need a long-term backup of a VM in a given state, you can just copy the VM somewhere else: this will have no performance impact on the VM, and you'll anyway end up using less disk space than what long-term snapshots would fill up over time.

Also, having a copy of the VM stored in a different place will actually help you if you lose the VM: snapshots are stored together with the VM they belong to, and are only useful if the VM is available; they are totally useless in the case of an actual data loss (like a datastore crash), and thus can't be used as real backups.

Here is some official documentation about snapshots:

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1015180

Answer 2

Some snapshot formats used by vmware degrade performance over time as they store more data. The "sparse extent" format I believe is still the default in the latest versions doesn't seem to have this property (you're looking at 3 reads per read, and up to 2 reads or 3 writes per write, but this doesn't get any worse as the disk fills up). So, I'm not entirely sure that the "don't keep snapshots around for a long time" property is necessarily correct advice at all times.

One thing I have noticed, though, is that merging snapshots takes ages as they get big. Depending on your use case, this may or may not be a problem.

As far as your other question, about "temporary backup", well, that's easy -- a backup is intended to survive the loss of the primary data store. Since snapshots and origins are stored together (and the snapshot is useless without the base image), you lose the lot -- hence a snapshot is in no way a backup.

Answer 3

I know this post is a little old, but the question and points raised are still very relevant.

VMware snapshots are definitely not backups. Worse side effect that I had happen to me and numerous customers, they keep a 6 month old VMware snapshot, the ESXi host experiences an unplanned disruption causing the ESXi to reboot or a reboot is needed to clear the disruption. The ESXi is recovered, VMs are booted and all data has been reverted back to the point in time where that VMware snapshot was taken.

In this scenario all changes between the point in time where the VMware snapshots was taken and moment of disruption are simply lost.

So my general advise is to take VMware snapshots only for an specific purpose and delete them once they have serve that purpose.

http://kb.vmware.com/kb/1025279

Answer 4

As a solution for your team's request for a clean install image or a particular state, I'd recommend using templates. Templates clone the VM (basically just a copy) to a state that can't be powered on or changed, it can just be used as a reference to clone copies. So for example, if I have a "Default Debian Install" template, and the server team asks for three new servers, I just create three new clones, customize, and I'm done.

The same can be done for your second scenario. If the VM gets to a state that you want to reference, create a template. From then on, whenever you need to reference it, just clone another copy.

Answer 5

The idea behind a snapshot is more of a restore point before you do some reconfiguration of the VM (install new software, major upgrade etc). So if you fuxor it you can back up to the point where it was workng and walk away whistling without having to blame any of your coworkers :)

And the general idea is that you'll merge at some point in the future (when you can bring it down for a while without affecting your users).

Answer 6

You shouldn't keep the vmware snapshot around for reasons others here have already described, but what a lot of people do is to have a vmware snapsot being taken and after that is done cleanly (depends on the guest what the snapshot really does) you take your storage array's snapshot to get and then you can backup/copy/archive/etc that snapshot. After you've created a real snapshot on your array you have to remove the vmware snapshot ASAP.