An awful lot of people think that snapshots are backups when in fact they are only good for rolling back to a the time they were taken and useless for most other purposes.
Snapshots simply record all changes to the base disk since they were taken and freeze the VMDK disk the state. VMware explains it this way:
The snapshot file is only a change log of the original virtual disk, it creates a place holder disk, virtual_machine-00000x-delta.vmdk, to store data changes since the time the snapshot was created. If the base disks are deleted, the snapshot files are not sufficient to restore a virtual machine.kb.vmware.com/s/article/1025279
There are many other misconceptions and limitations that we thought you would find this rule book for VMware vSphere snapshots useful:
Rule 1 – Delete Your Snapshots Within One Day
VMware says that you should not keep snapshots beyond 72 hours but we say you shouldn’t keep them more than 24 hours. Take a snapshot, make your changes, test your changes (or give your clients until the following day at noon to run their tests), then remove the snapshot.
A good Change Request should always have a thought out test plan; once that testing has been completed successfully, the snapshot should be removed. This is how snapshots are intended to be used.
We understand some customers have a process or requests to keep some snapshots for 4 or even 5 days and that is a mistake because:
- Reverting to a snapshot means losing all data since the snapshot was taken
- A number of important features like changing the size of disk or memory cannot be done when a snapshot exists
- Some backup software does not like taking snapshots of machines that already have snapshots, so you may be compromising your backups if you keep old snaps sitting around
- Old snapshots are just wasting disk space and creating clutter in your VMware environment
- Deleting stale snapshots takes time, is disk intensive and therefore slows performance of your disk which your users will not appreciate
Rule 2 – Don’t Snap High Volume Servers
Not all situations require snapshots and not all VMs should have snapshots taken.
Is this a large VM that has a high rate of data change (large file servers or heavily utilized SQL instances) or the customer has little extra space on their SAN?
On the other hand, if the customer is running very modern infrastructure with high performance SANs and vVols then snapshots may not have a noticeable impact but some rules may still apply.
Rule 3 – Do Not Snapshot Microsoft Exchange Servers
Neither VMware or Microsoft support the use of snapshots.
That being said, we still take some snapshots of Exchange servers, because we can restore the snapshot to a different temporary vm and recover any damaged files that may have occurred during patching. However, VMware and Microsoft are definitely correct in saying that you can’t use the snap to roll back the live production Exchange server.
Rule 4 – Be Careful When Taking a Snapshot of SQL Servers
When utilizing snapshots for SQL servers it’s important to ensure that you are using the quiesce option so that VSS is used.
Be even more careful if SQL is in a cluster, and always make sure the database is in a consistent state either by powering off the server or ensuring SQL servers are down.
Rule 5 – Don’t Snapshot Domain Controllers
There are several reasons why you shouldn’t use VMware to take a snapshot of a Domain Controller:
- In nearly all cases you will have other Domain Controllers available on your network so if this one blows up it’s not the end of the Earth. Simply create a new Server, join it to the domain and make it a Domain Controller. Even seizing the FSMO rolls is not that challenging, if you kill what we used to call the primary domain controller
- Only Server 2012 and newer Domain Controllers are even supported for snapshots. Older operating systems are not aware that they are virtual machines and cannot be rolled back successfully.
Just like Microsoft Exchange and SQL servers, we do sometimes take snapshots of Domain Controllers that we can restore the snapshot to a new offline virtual machine and manually copy any files that we might need in the event of a crash in the production server.
BONUS RULE – Don’t Nest Snapshots Beyond 3 Levels
Officially VM Ware says that you can keep up to 32 snapshots in a chain and still be supported. However performance lags for each one beyond 3 levels. We almost never keep more than a single level.
If You Aren’t Sure, Ask
The Internet has lots of good resources to answer your questions so you can Google any question you might have. Also, VMware has pretty good tech support so if you don’t have an in-house expert, call VMware. You have paid for WMware support, so use it.