Is it a good idea to take snapshots of production servers at regular intervals. I am reading a lot of website that suggest that you should not take snapshots of production systems, stating that it can effect network and machine performance. Anybody have any insight on this?
-
I'd say that it depends on the situation. I know someone that would LOVE the snapshots for his production machines even for a trade off.– TimCommented Jan 11, 2012 at 21:19
-
4FYI, you should pretty never have a snapshot on VM that hosts an AD DC. Serious badness happens if you revert.– ZoredacheCommented Jan 11, 2012 at 21:47
-
1FYI - Best practices for virtual machine snapshots in the VMware environment– Aaron CopleyCommented Jan 24, 2013 at 20:00
Add a comment
|
10 Answers
Be aware that snapshots are not a replacement for backups! I use snapshots only for creating short-term failback points, e.g. before a server is patched with something that might break it. But I won't keep snapshots for longer than several days, and by no means I would create them on a regular basis, just because I can and might need them later.
Please note that most virtualization aware backup software also use snapshots in an automated way to bring a VM to a consistent read-only state before backing it up. But even then the snapshot is deleted again as soon as the backup job has finished.
Snapshots are not designed to make regular checkpoint and are not a backup solutions. You can have several issues by keeping them too much (like out of space, storage slow-down, and in some few cases also corruptions)
Generally, disk performance (and size expansion of the VM's storage) is the concern with snapshots, as disk is now split between the flat disk and the snapshot disk (potentially multiple snapshot disks); a simple disk operation when there is no snapshot can significantly balloon, potentially needing to work with data on both the base and (multiple) snapshot disks (which are not contiguous with the base or each other; adding much additional seek time), requiring a lot more IO time than on a flat disk.
Evaluate your disk performance; if it doesn't impact you significantly then snapshot away.
answered Jan 11, 2012 at 21:22
Snapshots can be used as a mechanism to keep a rollback point when performing maintenance activities, but should not be used as a mechanism to backup the VM.
This is from the best practices.
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.
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.
I LOVE VMWare Snapshots! This is such an awesome feature for DEV and QA servers.
On a production machine, the most common problem I hear from IT staff is the disk space they take up. Planning ahead can mitigate this but there are always going to be finite limits in a production environment. In other words, you can only take as many snapshots as your disks will hold.
Most of the time, my customers take snapshots only when they need a full backup of the guest OS environment. So, for instance, we wil take a snapshot before installing a major application update. We probably will not take a snapshot if the VM is running a database server, and instead just back up the databases in use inside.
Like Shane above, I'd say the performance hit is less important, especially if the server's CPU isn't usually pegged out and you can schedule the snapshots to be taken during off-peak times. YMMV.
Something I don't see mentioned here are VM stuns. If you have a very busy production server your snaps will grown quickly. If you have the snap open for any length of time the ballooning mentioned above has greater potential to occur. When you go to close that snapshot out there is potential for an interruption of services with the stun.
When I have to take a snapshot of a production machine it is generally when a developer is updating some software on the server, after its been tested in the development environment. The snap would be done in off peak hours and closed out generally in that same maintenance window after a successful upgrade.
-
1I should hope that most ESXi installations are past 3.5 by now... Commented Apr 28, 2013 at 3:10
-
"This process has been significantly improved in ESX/ESXi 4.0 Update 1 and later and the stun time will be much shorter. Updated: Feb 22, 2013. Product Version(s):VMware ESX 3.0.x-VMware ESXi 5.1.x. -- So do I. Commented Apr 29, 2013 at 15:58
Network performance can be degrated during the snapshot process. But in my opinion a little bit of a perofrmance hit is better than losing data. Depending on how critical the data is I would maybe do one during the night. Unless your data is that critical that you must do Hourly etc.
Only you can decied how much data you can lose should you need to restore.
If you can live with a snapshot 24 hours old stick with it. But if you need your data no less than an hour old from a restore do that.
We run snapshots hourly for our main database server as this changes hourly. But our Exchange Server is snapshotted every 12 hours.
Small to medium servers with low I/O, then yes, fine. As mentioned above, domain controllers, no no NO! Also depends on whether you're asking for a quiesced snapshot. With an active DB server, for example, the memory/disk I/O run-down can a) timeout and b) cause interruption. I've seen Oracle TNS being interrupted before. Granted, the transaction recovered, but still not ideal.
answered Apr 27, 2013 at 21:46
You have three choices. First one and the easiest one is to take snapshots, however, this is not considered an official back of your VMs. It is good for lab environments but not production VMs.
Your second option is to use Vmware data recovery (VDR). This tool is great for small-to-medium sized business. This is a lot better than snapshots but it has some limitations, like you can backup 8 VMs simultaneously. Not bad but if you have hundreds of VMs, this is not suitable.
The most professional solutions is the one who uses VMWare's vStorage API. Solutions like Tivoli storage manager (TSM), it extends VMWare's vStorage API to provide a solution to VM backups. There are others out there. The price goes up with the usage of course but it all depends on what you want to do. I would either use VDR or get some solution provider that uses vStorage API to do my backups and restores. Do your research and good luck :)
