VMware vSphere

 View Only
  • 1.  snapshots best practices?

    Posted Aug 15, 2019 10:37 AM

    Hi, I am curious as to what others are using as a standard/best practice for snapshot management. I understand how the work and there is no way to know exactly the growth rate/size/commit time etc due to the IO, but as a general rule of thumb? The reason I ask is that someone mentioned recently that snapshots over 50GB in size are prone to corruption but this is new to me.

    I'd appreciate other peoples views on this.

    Thanks and regards

    Steve



  • 2.  RE: snapshots best practices?

    Posted Aug 15, 2019 10:44 AM

    Welcome to the Community,

    it's not the size of a snapshot that's important.

    Best practice for production VMs is to keep snapshots only as long as necessary (e.g. while installing a critical update), so that you can revert to the previous state in case of a failure. Keeping snapshots for a long time - especially with multiple snapshots in place - may decrease the VMs performance, and requires additional disk space.

    Please remember that snapshot are no backups!

    André



  • 3.  RE: snapshots best practices?

    Posted Aug 15, 2019 10:54 AM

    Hello André and thanks for the reply.

    I understand there can't be an exact figure, and we do encourage these recommendations you mentioned. I'm curious if anyone has heard of such an issue with corruption over certain sizes? I'm doubtful, as you said the size is not relevant. We're trying to decide on a policy to stop snapshots growing too large, but how large is too large is the question really!! How long is a piece of string sounds familiar! :-)



  • 4.  RE: snapshots best practices?

    Posted Aug 15, 2019 11:02 AM

    There's really no size limit that I'm aware of, it's basically the age of a snapshot that you should monitor. At some point in time it simply may not make any sense to revert to it.

    I've seen snapshots with more than a TB. As long as you don't run out of free disk space on a datastore, you shouldn't experience size related issues.

    André



  • 5.  RE: snapshots best practices?

    Posted Aug 15, 2019 03:21 PM

    Thank you, I'm still interested if other people use a general rule of thumb around this?

    Thanks in advance.



  • 6.  RE: snapshots best practices?

    Posted Aug 15, 2019 05:03 PM

    You might find KB1025279 helpful.  In our environment (5.5) we've grown somewhat leery of extensive snapshot chains because they caused corruption issues and lost us whole VMs in the past (granted that was while running vSphere 4.0, but it scared us enough to impact our behavior.)

    Here are our present rules of thumb:

    • Few snapshots as possible (ideally five or less)
    • Don't let snapshots live longer than 24 hours

    Once a month I run a report to see if we've got any forgotten snapshots and email the VMs owner, prodding them with a reminder to delete old snapshots.  We've found that most old snapshots (older than a few days) are useless anyway, since it's unlikely we would revert to a snapshot older than twenty-four hours—that's why we have backups, after all.

    Our primary use of snapshots is when building test boxes.  On production servers snapshots are used during maintenance windows and are deleted once the work is completed.



  • 7.  RE: snapshots best practices?

    Posted Aug 18, 2019 01:10 PM

    Hello

    Consider some main aspects of Snapshot Generation:

    1. Old-Aged Snapshots are not useful, because they are old enough that most of times you don't need them anymore. Many of Monitoring systems (also vRealize Operation Manager) recognized them as not-useful object if they are very old, and then warned you to remove them.

    2. Many nested Snapshots can cause complexity in VM management, because each snapshot is depended to its previous snapshot. Too many snapshot in one path may slow down VM operation and you will need to consolidation action after a duration. Also elapsed time of consolidation depends on snapshot hierarchy and their dependencies. So avoid to generated depended (nested) snapshot.

    3. Do not include VM's memory to the snapshot if you really don't need it. In other words create snapshot in power-off state or uncheck this option whenever you don't really need it. It will generate a VMSN file include content of virtual machine memory, big as Virtual Memory size, So you will require more space on your datastore for each snapshot like this.

    4. For each reason if you lose one of delta.vmdk of your VM suddenly , it may lead to VM corruption, So you need to protect the VMs and their Snapshots more than ever.

    I Wrote a post about Snapshot two weeks ago, I hope it can be helpful for you:

    Virtual Machine Snapshot Details Investigation - Part 1



  • 8.  RE: snapshots best practices?

    Posted Aug 18, 2019 06:31 PM

    I am curious about the rule-of-thumb that others have give here that SnapShots should live only for a short time.  We use VCenter Appliance 6.5 on ESXi 6.5. The VMs are used primarily for testing our software. We will take a (powered off) Baseline Snapshot with the VM configured how we want it before we install our software.  After a testing cycle, we will revert to that Baseline Snapshot and start again. It now sounds like a practice like this is can degrade performance of the VM and eat up lots of disk space.  I thought Snapshots were exactly for this type of situation.  What am I missing? What is the best way to revert a VM to a previous (powered off) state?



  • 9.  RE: snapshots best practices?

    Posted Aug 18, 2019 06:34 PM

    In your use case, this is a fine application of snapshots. Each time you revert to an earlier snapshot, you discard the delta that was accruing those changes made after the snapshot. This is different from continuing to run off that state for weeks, months, or years.



  • 10.  RE: snapshots best practices?

    Posted Aug 19, 2019 11:03 AM

    OK thanks, I guess this is one of those ones that can't be quantified. I will stick with the best practices we have in place now.

    Thank again for your feedback.


    Regards

    Steve