How to create and restore a VPS snapshot on KVM

The first rule of any serious sysadmin work is simple: snapshot before you touch anything. I have lost count of how many times a five-minute config change turned into a two-hour recovery session because nobody took a snapshot first. On a KVM-based Linux VPS, a snapshot is a point-in-time copy of the entire disk, which means you can roll back to a known-good state in seconds. This guide walks through how to create and restore a VPS snapshot from a control panel, how to verify it actually works, and the disk-space gotchas that catch most people off guard.

Prerequisites

• A KVM VPS running any OS: Ubuntu 24.04, Debian 12, AlmaLinux 9, or Windows Server. The snapshot mechanism works at the hypervisor level, so the guest OS does not matter.
• Access to the VPS control panel (Virtualizor or a similar KVM panel) where you can manage snapshots.
• Root or Administrator access to the VPS itself, for the verification steps.
• Enough free disk space on the host for the snapshot. This is critical, covered in detail below.

Why you need snapshots even if you have backups

Backups and snapshots solve different problems. A backup copies files to another location, which protects you against disk failure or accidental deletion. A snapshot preserves the exact state of the virtual disk at a moment in time, which is what you need when a bad update or a misconfigured firewall bricks the system five minutes after you applied it.

The difference matters in practice. Restoring from a backup means reinstalling the OS, reconfiguring everything, and hoping the data is recent enough. Restoring a snapshot is one click, and the VPS is exactly as it was when the snapshot was taken. For that reason I take a snapshot before every major change: kernel upgrades, PHP version bumps, firewall rewrites, Docker Compose updates. If the change breaks something, I roll back in under a minute and try again. If you run automation workflows with n8n or self-hosted GitLab on a n8n VPS, a snapshot before a workflow change saves you from debugging a broken instance at midnight.

One thing to be honest about: a snapshot is not an off-site backup. It lives on the same physical host, so a host-level failure takes the snapshot with it. For disaster recovery you still want regular off-site backups. For operational safety, snapshots are the fastest tool you have.

Step 1 - Taking the snapshot in the control panel

Log in to your VPS control panel and find the snapshot section. The exact wording depends on the panel, but it is usually labelled Snapshots or Backups. On Virtualizor, it sits under the VPS management page.

1. Go to the VPS management page in the control panel.
2. Find the Snapshot / Backup section.
3. Click "Create Snapshot" or "Take Snapshot".
4. Give it a readable name, for example: before-php83-upgrade-2026-01-15.
5. Confirm. The process takes from a few seconds to a few minutes depending on disk size.

While the snapshot is being taken, do not write heavy data to the disk. The snapshot captures a consistent state, and a busy database can end up with an inconsistent snapshot. For a clean copy of a database server, stop the service briefly, take the snapshot, then start it again. For a simple file server this is rarely necessary.

Verify: the snapshot appears in the list with a timestamp and a size. If the panel shows an error about insufficient space, you hit the gotcha described in the next section. The size shown is the space the snapshot consumes on the host, not the size of your VPS disk.

Step 2 - Understanding the disk space cost

Here is what nobody tells you before the first snapshot: a snapshot is not a full copy of the disk. KVM snapshots work on a copy-on-write basis. The first snapshot is small because it only records the differences from the base disk. But every byte you write to the VPS after taking the snapshot gets stored in the snapshot file. Write 10 GB of log files and the snapshot grows by roughly 10 GB.

This creates a trap. You take a snapshot, then keep running the VPS for weeks, writing data constantly. The snapshot file bloats until it fills the host disk, and suddenly the VPS slows down or the panel refuses to create new snapshots. The fix is discipline: delete old snapshots after you are sure the change was good, and never keep more than two or three snapshots per VPS.

Verify disk usage inside the VPS:

df -h
# Compare the Used column against the size of your snapshots in the panel.

If you have a 2GB RAM VPS, the disk is likely small, so you can afford one snapshot but not five. Plan accordingly and prune aggressively.

Step 3 - Restoring a snapshot

Restoring is the part that matters, and it is also the part where people make the most mistakes. The critical warning: restoring a snapshot overwrites the current disk state. Everything you changed since the snapshot was taken is gone. That includes new files, database writes, installed packages, everything. Make sure you actually want to lose that state before you click restore.

1. In the control panel, open the Snapshots section.
2. Find the snapshot you want to restore.
3. Click "Restore" or "Rollback".
4. Confirm the warning that current data will be overwritten.
5. Wait for the restore to finish. The VPS may reboot automatically.

After the restore completes, log in and check that the system is exactly where you expect it to be. Check the kernel version, the running services, and recent file dates.

uname -r
systemctl list-units --type=service --state=running | head -20
ls -la /etc/nginx/

Verify: the output matches the state you had when the snapshot was taken. If you restored because an upgrade broke Nginx, the broken config should be gone and the service should be back at the working version.

One more thing: some panels allow you to restore a snapshot as a new VPS instead of overwriting the current one. This is the safest option when you are not sure. It costs extra disk and IP resources, but it lets you inspect the snapshot before committing to it.

Step 4 - Automating snapshot hygiene

Manual snapshots are fine, but they depend on you remembering to take them. For systems that change often, a small script that prunes old snapshots keeps the host healthy. Most control panels expose a CLI tool for management, and you can also use the panel API. A weekly cron job that deletes snapshots older than 14 days is enough for most workloads.

# Example: remind yourself to prune snapshots weekly
0 3 * * 1  echo "Check and prune old VPS snapshots in the panel" | mail -s "Snapshot hygiene" [email protected]

If your panel supports API calls, you can automate the whole lifecycle: create a snapshot before a deployment, verify the deployment, then delete the snapshot after a grace period. Teams running CI/CD pipelines on a GitLab VPS benefit the most from this, because every pipeline run is a potential breaking change.

For anything running a database, combine snapshots with logical backups. A snapshot protects the whole system, but a mysqldump or pg_dump gives you a portable copy you can move off the host entirely. The snapshot is your safety net, the dump is your escape route.

Troubleshooting common snapshot problems

Snapshot creation fails with "no space left". The host disk is full. Delete old snapshots from the panel, then retry. If you cannot delete because the snapshot is locked, contact support. On a busy VPS, stop heavy write workloads before creating a snapshot so it does not grow during creation.

# Check disk pressure inside the VPS
df -h
# If you use Docker, dangling images eat space fast
docker system prune -f

Restore completed but the system does not boot. This usually means the snapshot was taken while the filesystem was inconsistent. Reboot into the panel's rescue mode and run a filesystem check on the restored disk. To avoid this next time, shut down the VPS cleanly before taking the snapshot, or at least stop database services.

The snapshot is much larger than expected. You wrote a lot of data after taking it, which is exactly how copy-on-write snapshots behave. Delete it if you no longer need it, and keep future snapshots short-lived.

Restore is greyed out in the panel. The VPS is running and the panel refuses to restore a running instance. Reboot the VPS into rescue mode or shut it down, then retry the restore.

FAQ

Related articles

• How to back up a VPS before an upgrade
• How to benchmark NVMe disk speed on a VPS
• Why my VPS runs out of RAM and how to fix it
• Migrate a website to a new VPS with zero downtime