Our website use cookies to improve and personalise your experience and to display advertisements (if any). Our website may also include cookies from third parties like Google Adsense, Google Analytics, Youtube. By using the website, you consent to the use of cookies.

Blog Post

Best practices for VMware Snapshots

I have come across a number of forums and emails were people are unsure on the proper use of snapshots and on occasions using snapshots for the wrong reason.  I found a great VMware article which I think covers everything you need to know about snapshots and the correct use:-

  • Snapshots are not backups. A snapshot file is only a change log of the original virtual disk. Therefore, do not rely on it as a direct backup process. The virtual machine is running on the most current snapshot, not the original vmdk disk files.
  • Snapshots are not complete copies of the original vmdk disk files. Taking a snapshot does not create a complete copy of the original vmdk disk file, rather it only copies the delta disks. The change log in the snapshot file combines with the original disk files to make up the current state of the virtual machine. If the base disks are deleted, the snapshot files are useless.
  • Delta files can grow to the same size as the original base disk file, which is why the provisioned storage size of a virtual machine increases by an amount equal to the original size of the virtual machine multiplied by the number of snapshots on the virtual machine.
  • The maximum supported amount of snapshots in a chain is 32. However, VMware recommends that you use only 2-3 snapshots in a chain.
  • Use no single snapshot for more than 24-72 hours. Snapshots should not be maintained over long periods of time for application or Virtual Machine version control purposes.
    • This prevents snapshots from growing so large as to cause issues when deleting/committing them to the original virtual machine disks. Take the snapshot, make the changes to the virtual machine, and delete/commit the snapshot as soon as you have verified the proper working state of the virtual machine.
    • Be especially diligent with snapshot use on high-transaction virtual machines such as email and database servers. These snapshots can very quickly grow in size, filling datastore space. Commit snapshots on these virtual machines as soon as you have verified the proper working state of the process you are testing.
  • If using a third party product that takes advantage of snapshots (such as virtual machine backup software), regularly monitor systems configured for backups to ensure that no snapshots remain active for extensive periods of time.
    • Snapshots should only be present for the duration of the backup process.
    • Snapshots taken by third party software (called via API) may not show up in the vCenter Snapshot Manager. Routinely check for snapshots via the command-line.
  • An excessive number of delta files in a chain (caused by an excessive number of snapshots) or large delta files may cause decreased virtual machine and host performance.
  • Configure automated vCenter Server alarms to trigger when a virtual machine is running from snapshots.
  • If hosts and/or vCenter Server are prior to vSphere 5.0 confirm that there are no snapshots present (via command line) before a Storage vMotion. If snapshots are present in the pre-vSphere 5.0 setting, delete the snapshots prior to the Storage vMotion. vSphere 5.0 and ESXi 5.0 and later support Storage vMotion with snapshots present on a Virtual machine.
  • Confirm that there are no snapshots present (via command line) before increasing the size of any Virtual Machine virtual disk or virtual RDM. If snapshots are present, delete them prior to increasing the size of the disk/s. Increasing the size of a disk with snapshots present can lead to corruption of the snapshots and potential data loss.

 

Related Posts