How to take a VPS snapshot before a risky change (and how to roll back)

Snapshots are the cheapest insurance you'll ever buy. They take a few seconds to create, roll back in under a minute, and let you try a risky change knowing you can undo it. This article covers when to use snapshots, when not to, and the exact button sequence in the LYLIX portal.

What a snapshot is

A point-in-time copy of your VM's disk and (optionally) memory, stored on the same hypervisor storage pool as the VM itself. Taking one freezes the VM for a moment while the hypervisor writes the snapshot record, then resumes normal operation. The snapshot lives alongside your VM and consumes additional storage only for the blocks that diverge after the snapshot was taken.

You can take up to 3 snapshots per VPS. New snapshots after the limit require deleting an old one first.

What a snapshot is NOT

It's not an off-host backup. If the underlying storage pool fails, the snapshot fails with it — same disk, same host. Snapshots protect you from "I made a change and broke something." They don't protect you from "the storage died" or "the entire host caught fire."

For real backups, use off-host tools like restic, borg, or rsnapshot writing to remote storage. Snapshots are the fast-revert tool; off-host backup is the disaster-recovery tool. You want both, for different reasons.

When to take a snapshot

Five-second rule: if a change could break the VM in a way that SSH can't fix, snapshot first. Concretely:

• Before a kernel upgrade — most go cleanly, but the rare "VM won't boot" requires either rescue mode or a snapshot rollback. Rollback is ten seconds.
• Before a distro upgrade (Debian bullseye → bookworm, AlmaLinux 8 → 9, Ubuntu LTS upgrades). Distro upgrades touch hundreds of packages and config files. Rollback is your safety net.
• Before a config refactor — switching from Apache to nginx, redoing your firewall from scratch, re-architecting your application's data layer.
• Before a major application upgrade — FreePBX major version bump, Nextcloud upgrade, PostgreSQL version migration.
• Before changing low-level system files — /etc/fstab, GRUB config, initramfs hooks. Mistakes here can leave the VM unable to boot.

When NOT to use snapshots

• As your only backup. Off-host coverage is non-negotiable for any data you can't afford to lose.
• For long-term retention. Snapshot storage is the same SSD as your live VM — expensive per GB compared to archival storage. Keep snapshots short-term (days, not months); roll your own archival strategy for anything longer.
• For active databases under heavy write load. Filesystem-level snapshots can capture a database mid- transaction. Either quiesce the database before snapshotting (e.g., FLUSH TABLES WITH READ LOCK on MySQL, pg_start_backup() on PostgreSQL) or use the database's own backup tools.

How to create a snapshot

1. Sign in to customer.lylix.net, open your service.
2. Click the Snapshots tab.
3. In the create card at the top, type a Name (short, no spaces — e.g., before_php_upgrade) and an optional Description (free-form text).
4. Click Create Snapshot.

The snapshot appears in the list below within a few seconds. The VM is briefly paused during creation — typically less than a second — then resumes.

You'll see the new entry showing: name, creation timestamp, your description, and three action buttons (Edit, Rollback, Delete).

How to roll back

1. In the Snapshots list, find the entry you want to revert to.
2. Click Rollback.
3. Confirm the dialog. The VM stops, reverts to the snapshot state, and restarts automatically.

The whole sequence usually takes 30-60 seconds. When the VM comes back, it's in the exact state it was when the snapshot was taken — same files, same processes (mid-flight, restarted), same configuration. Anything written to disk between the snapshot and the rollback is gone.

This includes things you may not have intended to revert — emails that arrived in a mailbox, application state that was written, sessions that were active. Treat rollback as a reset to a known-good state, not a surgical "undo" of one change.

Editing snapshot descriptions

If you want to update the description after creation (for example, to note "this is the one I rolled back to on June 18"):

1. Click Edit next to the snapshot.
2. The description cell becomes editable.
3. Type the new value, click Save.

The snapshot name itself isn't editable from the portal — if you need to rename, delete and re-create.

Deleting snapshots

Snapshots cost storage. Delete the ones you don't need anymore:

1. Click Delete next to the snapshot.
2. Confirm.

Deletion is immediate and irreversible — there's no undelete. Once it's gone, it's gone. If you want to keep it long-term, either don't delete it (counts against your 3-slot limit) or back the VM up off-host first.

Recommended workflow

For routine risky changes:

1. Snapshot before, with a clear name (before_distro_upgrade).
2. Make the change.
3. Validate it works (give it a few hours or days, depending on the change).
4. Delete the snapshot to free the slot.

For long-running changes you want to test in production:

1. Snapshot before.
2. Make the change.
3. Leave the snapshot in place for a week or two while you watch for problems.
4. Delete when confident.

The 3-slot limit forces good hygiene — you can't accumulate snapshots forever, so you have to deliberately decide which ones matter.

One closing note about storage

Snapshots store the original blocks at the moment of capture plus the divergence. A snapshot taken on a 40 GB VM that then has 20 GB of changes written will occupy about 20 GB of additional storage. Long-lived snapshots on a VM with high write churn add up. If your VM's disk usage seems higher than you'd expect, check how many snapshots are alive and how long they've been there.

Questions? Open a ticket — snapshot tooling has more edge cases than most platform features and we're happy to walk through specific scenarios.