Depending on what storage you are running, performance penalty on IO and
CPU cycles will be significant on VMs as well as storage back-end, space
consumption can be much greater than allocated.
Each time snapshot is made, you are creating a delta file, the more
snapshots you have the more delta's you create - they inturn become a
chain dependency of one another. When you read and/or write IO - ESX
hypervisor needs to inspect the datablocks - as well as add new
datablocks continuously. You are not overwritting an existing datablock,
you are continuoisly create a new block that is a delta of pre-snapshot
block. As a result, while you root or data volume is allocated 10GB (as
an example), the actual disk consumption could be much greater.
Also, if a dependent snapshot delta file becomes corrupted, the entire
VM may fail to start. You maybe lucky enough to bring the VM to
pre-snapshot state, but you would incur some data loss.
Like Geoff mentioned and you confirmed, it should be used as temporary
measure, creating continuous snapshots for 30days, is risky, costly and
performance degrading.
On 5/16/14, 4:54 PM, Phillip Kent wrote:
Thanks Geoff,
that's very helpful clarification.
The documentation on VM snapshots gives mixed messages. The CS
documentation is non-committal about how snapshots should be used (and
maybe it should be non-committal). The VMware documentation is very
enthusiastic about the coolness of using 'snapshot chains' while at the
same time pointing out all the things which can go wrong.
My company has recently started to use CS to provide an IaaS platform to
customers, and we find that they are attracted to VM snapshots because
they are incremental, whereas there is limited possibility for
incremental snapshots of volumes (we have only implemented CS with ESXi
at the moment, which I understand does not support incremental). There
are customers whose backup policy is to keep a daily backup of volumes
for the last 30 days, so they are looking at significant storage costs
for non-incremental snapshots. (Perhaps, we should educate them towards
a smarter backup policy, but that is easier said than done.)
Phillip
On Fri, 2014-05-16 at 21:06 +0000, Geoff Higginbottom wrote:
Philip,
Simple answer is no.
A VM Snapshot should only be used as a temporary roll back option
prior to making a system change. After the planned changes are made,
and as soon as you confirm there have been no undesired adverse
affects, VM snapshots should be removed.
Snapshots are certainly not designed to be used as long term backups.
This is general virtualisation 'best practice' and not directly
related to CloudStack.
When a VM has an active VM Snapshot, CloudStack limits certain
features such as storage migration so another reason for not
maintaining long term VM snapshots.
On 16 May 2014, at 20:27, "Phillip Kent" <[email protected]>
wrote:
Dear all,
I have some questions about using VM snapshots.
In principle, VM snapshots look like a very painless way for users to
keep backups of VMs (compared with the alternative of doing separate
volume snapshots of root disks, data volumes, etc).
But when you look more into it
(http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1015180)
you see that a lot of things can go wrong with snapshots.
So I wondered if anyone has views or experiences on this, especially
where CloudStack is being used as IaaS for paying customers. I am
thinking about end users who only have access through the UI or API,
not
users who have root access to the hypervisors. Are VM snapshots a good
strategy for end users to keep regular backups of their VMs??
Thx Phillip
