On my second week as a junior admin, someone told me to "just take a snapshot before the patch, that way we are safe." I took it, patched, the change went fine, and I moved on. Three weeks later a datastore alarm went red. The cause was my snapshot, still sitting there, quietly grown to 40 GB, with the VM running off a stack of delta files nobody had merged. That day taught me the single most useful thing in this whole topic: a snapshot is not a backup, and forgetting it is how juniors cause outages.
Templates, clones and snapshots are the three ways VMware lets you copy and preserve a VM. They sound similar and the vSphere Client menus sit right next to each other, so people blur them together. They do completely different jobs. Get the mental model right once and you will use all three with confidence for the rest of your career.
Three tools people constantly confuse
Think of a VM as a working document on your laptop. A snapshot is like the moment right before you make a big edit, the point you can roll back to if the edit goes wrong. A clone is Save As, a brand new independent copy you can mess with freely. A template is a locked master file you keep in a drawer and copy every time you need a fresh standard document, but never type into directly. Same family, three jobs.
Here is the same idea as a table you can keep next to you:
| Question | Snapshot | Clone | Template |
|---|---|---|---|
| Independent VM? | No, tied to parent | Yes | No, cannot power on |
| Can it run? | The VM keeps running | Yes | No, convert it back first |
| Main use | Quick roll-back point | One-off copy for testing | Mass-deploy identical VMs |
| Safe to keep long term? | No, hours only | Yes | Yes |
| A backup? | Never | Closer, but not a backup strategy | No |
Snapshots: a save point, not a safety net
A snapshot captures the state of a VM at one moment: its disk, optionally its memory, and its settings. You take one before something risky, a patch, an upgrade, a config change you are not sure about. If the change breaks the VM, you revert to the snapshot and it is as if the change never happened. If the change is fine, you delete the snapshot. That is the whole healthy lifecycle, and it should last hours.
What actually happens on disk
This is the part most tutorials skip, and it is the part that bites you. When you take a snapshot, VMware does not copy the disk. Instead it freezes the original disk as read-only and creates a new small file called a delta disk, named something like myvm-000001-delta.vmdk. From that second on, every write the VM makes goes into the delta, not the original. The original is your frozen save point. The delta is everything that changed since.
Take a second snapshot and you get a second delta. Now there is a chain: base, then delta one, then delta two, and the VM runs off the newest delta. To read a block, VMware checks the newest delta first, and if the block is not there it walks back through the chain until it finds it. Short chains are fine. Long ones add real latency to every read. That is why performance guidance is to keep only two or three snapshots, even though the technical limit is 32 in a chain.
The 72-hour rule and the warning that catches freshers
VMware recommends you do not keep a snapshot longer than 72 hours. The reason is simple: the delta keeps growing as the VM writes data, and on a busy VM it can grow large enough to fill the datastore. A full datastore stops every VM on it, not just yours. That is how a forgotten snapshot becomes an outage.
Gotcha
One day you will see a yellow alarm: Virtual machine disks consolidation is needed. It means a delete or backup left delta files behind that never merged into the base disk, so the VM is still running off snapshot files even though Snapshot Manager looks empty. The usual cause is a backup job that locked the files or a datastore with under about 1 GB free, so the merge could not finish. The fix is to right-click the VM, choose Snapshots, then Consolidate, and wait. Do it during quiet hours, because consolidation hits disk hard. Ignoring that alarm is exactly how the deltas keep growing in the dark.
Templates: the golden image you deploy from
A template is a master VM image you keep clean and deploy fresh copies from. You build one good VM, install the OS, apply patches, set your standard tools and security settings, then convert it to a template. From then on, when someone needs a new server, you deploy from the template and get an identical, pre-configured VM in minutes instead of installing an OS by hand every time. A template cannot be powered on; that is deliberate, so nobody accidentally drifts the master out of sync.
Convert to Template versus Clone to Template
vCenter gives you two ways to make a template, and freshers pick the wrong one all the time. Convert to Template turns your existing VM into the template, so the original VM is gone as a runnable machine. Clone to Template leaves your VM running and makes a separate template copy. Use Convert when the source VM was only ever meant to be a master. Use Clone to Template when you want to keep the source VM running and produce a template alongside it.
Here is where I disagree with the tidy version of the advice you will read online. Plenty of guides say Convert to Template is the more flexible choice because you can flip it back to a VM, patch it, and convert it again. That round trip is real, but in practice it is also the most common way templates rot. You flip a template back to a VM to patch it, someone powers it on, it pulls a DHCP address, the agents check in, and now your supposedly pristine master has logs, a machine identity and state it should never carry into a fresh deployment. My rule for a first job: keep a normal VM as your build source, never power on anything you call a template, and rebuild the template from the source rather than reanimating the template itself. It is one extra step that saves you from shipping a polluted golden image to fifty servers.
Clones: full versus linked
A clone is a copy of a VM made right now. There are two kinds, and the difference matters. A full clone is a complete, independent copy; it shares nothing with the source once cloning finishes, so it can run on its own forever. A linked clone shares the source disk and only stores its own changes in a delta, much like a snapshot. Linked clones are fast to create and save space, but they depend on the parent; lose the parent and the linked clone is useless.
For day-to-day vSphere work you will mostly make full clones; deploying from a template actually produces a full, independent VM. Linked clones show up in places that spin up many short-lived desktops or test machines, such as VMware Horizon, where saving space across hundreds of near-identical machines is worth the dependency. As a fresher, default to full clones unless someone specifically tells you a linked clone is wanted.
Worked example
Your team needs ten identical web servers, each with a 60 GB disk. Two ways to get there:
By hand: install the OS ten times, patch ten times, configure ten times. At roughly 45 minutes each, that is about 7.5 hours of clicking, and small differences will creep in between machines.
From a template: build and patch one master once (say 60 minutes), convert it to a template, then deploy ten copies with guest customisation. Each deploy is a few minutes; ten land in well under an hour and every one is identical.
Same outcome, a fraction of the time, and zero configuration drift. That difference is the entire reason templates exist.
Real interview question
Is a snapshot a backup? Explain.
Say no, clearly, then explain why. A snapshot only stores the changes since you took it; it depends on the original base disk and lives on the same datastore as the VM. If that datastore fails or the base disk is lost, the snapshot is worthless. A backup is a separate, independent copy stored somewhere else, so it survives the loss of the original. Snapshots are short-term roll-back points for risky changes; backups are your real recovery plan. Finish with the practical line interviewers like: keep snapshots for hours, not weeks, and never rely on one as protection.
Try it yourself
On a free home lab, VMware Workstation or nested ESXi both work, do this with a small test VM:
1. Take a snapshot. Inside the VM, create a file on the desktop called before-change. 2. Take a second snapshot. Now delete that file and add a new one called after-change. 3. Open the datastore or VM folder and look for the delta vmdk files that appeared. 4. Revert to the first snapshot and check the desktop.
You got it right if reverting brings back before-change and removes after-change, and if you can see the delta files growing as separate files from the base disk. Then delete all snapshots and confirm the deltas merge away. That single exercise makes the base-plus-delta model click for good.
FAQ
Does taking a snapshot pause or slow my VM?
Taking it is quick and the VM keeps running. The slowdown comes later: the longer you keep the snapshot, the more reads have to walk the delta chain, and a busy VM with old snapshots feels sluggish. Delete snapshots promptly and the penalty disappears.
How many snapshots can I have, and how many should I have?
VMware supports up to 32 in a chain, but for performance keep it to two or three at most. The supported limit is not a target. If you find yourself near it, something has gone wrong with your cleanup habits.
Can I edit a template?
Not directly, because a template cannot power on. You convert it back to a VM, make changes, then convert it to a template again. Just be careful: a powered-on former template can pick up state it should not keep, which is why many admins patch a separate build VM and rebuild the template from it instead.
What is the difference between deleting a snapshot and reverting to it?
Reverting throws away everything that happened after the snapshot and returns the VM to that saved state. Deleting keeps your current state and merges the delta changes into the base disk, removing the save point. Both are normal; just know that delete means commit, not discard.
Should I snapshot a VM before a backup runs?
Your backup software already takes its own snapshot behind the scenes and removes it when done. You do not need to add your own, and a leftover manual snapshot can actually interfere with the backup. Let the backup tool manage its own snapshots.
The one habit to take away
If you remember nothing else: snapshots are short-lived save points, templates are your reusable master images, and clones are one-off copies. The mistake that hurts careers is treating a snapshot as a backup or leaving one running for weeks. Take them when you need them, delete them the same day, build a clean template for anything you deploy more than once, and you will already handle this better than plenty of people with years on the job. Next we move into keeping VMs alive and fast, starting with the feature that genuinely surprises newcomers: moving a running VM between hosts with zero downtime.
References
Broadcom: Best practices for using VMware snapshots
About The Author
DrJha