Skip to main content

Rolling snapshots

warning

Snapshots are NOT backups. A snapshot lives on the same storage as the original disk: if you lose that disk or the whole storage repository (SR), you lose every snapshot with it. Rolling snapshots are a convenient way to roll back in time, not a way to survive a storage failure.

Snapshots and backups are not mutually exclusive either: use rolling snapshots for quick rollbacks, and a real backup job (with data stored on a separate backup repository) for actual protection. Never rely on snapshots alone!

A rolling snapshot job takes a snapshot of the VMs you selected, on the schedule you defined, and applies a retention policy: when the number of snapshots created by the job exceeds the limit, the oldest one is deleted automatically. The result is a rotating window of instant restore points that maintains itself, with no manual cleanup and no backup repository (BR) needed.

Because everything stays on the SR, snapshots are created in seconds and reverting a VM to any point in the window is nearly instant. That makes rolling snapshots ideal as a first line of defense against "oops" moments: a bad update, a broken config change, a botched application upgrade.

How it works​

Every time the schedule fires, Xen Orchestra:

  1. Takes a snapshot of each VM in the job.
  2. Counts the snapshots previously created by this job.
  3. Deletes the oldest one(s) if the total exceeds the configured retention.

With a daily schedule and a retention of 7, you always keep the last seven days: each morning a fresh snapshot appears, and the one from eight days ago disappears.

Storage repository (SR)VMDay 1removedDay 2Day 3Day 4Day 5Day 6Day 7Day 8newRetention = 7: creating today's snapshot removes the oldest one
Daily rolling snapshots with a retention of 7new snapshotoldest, removedrotation

Creating a rolling snapshot job​

Rolling snapshots are configured like any other backup job:

  1. Go to the Backup view and create a new backup job.
  2. Select Rolling snapshot as the job type.
  3. Select the VMs to snapshot, either explicitly or with smart mode (dynamic selection based on pools, tags and power state, so new matching VMs are included automatically).
  4. Define the schedule (when snapshots are taken) and the snapshot retention (how many to keep).
  5. Save the job. It will now run on its own, and you can also trigger it manually at any time.

To roll back, open the VM's Snapshots tab and revert to the restore point you want.

Scheduling examples​

  • Nightly snapshot, for example at 4:30 AM, with a retention of 7: you can revert any VM in the job to any of the last seven days.
  • Weekly snapshot, for example Sunday at 11:00 PM, with a retention of 4: about a month of rollback capability, at a coarser granularity.
  • Combine both in two separate jobs if you want short-term granularity and a longer safety net at the same time.

Caveats​

tip

On thick-provisioned storage (LVM-based SRs: iSCSI, HBA, local LVM), every snapshot reserves the full virtual size of the disk on the SR. Seven rolling snapshots of a 200 GiB disk can claim more than 1.4 TiB. Avoid rolling snapshots for large VMs on these SRs, or keep the retention very low. Thin-provisioned storage (local ext, NFS, XOSTOR) only consumes space for the actual changes.

  • Coalesce load: deleting a snapshot triggers coalesce work on the SR to merge the disk chain back together. If snapshots rotate faster than the SR can coalesce (very frequent schedules on slow storage), chains pile up and Xen Orchestra will skip the VM to protect it. See VDI chain protection for details.
  • Reverting is destructive: rolling a VM back to a snapshot discards everything that happened after that snapshot was taken. If you are not sure you want to lose the current state, snapshot it first, then revert.

When to use it​

Rolling snapshots shine as a cheap, fast undo button: before risky changes, on dev and test VMs, or as a short-term rollback layer on top of a proper backup policy. They cost nothing to set up, need no backup repository, and restore in seconds.

They are not a protection layer: they will not survive the loss of the SR, a corrupted storage, or a host disaster. Once your rolling snapshots are in place, head over to the Backup strategy guide to design real protection, with incremental backups as the natural next step: they reuse the same snapshot mechanism, but export the data to a separate backup repository where a storage failure can't reach it.