What Is a VPS Snapshot? A Guide to Point-in-Time Backups

A VPS snapshot is a point-in-time image of a virtual server's disk and, depending on the platform, its configuration and RAM state. It gives you a fast way back after a bad update, but it may live on the same infrastructure as the VPS and may not protect application data consistently. Treat it as a rollback tool, not your only backup.

What a VPS snapshot actually gives you

At 3 a.m., a snapshot can feel like a spare exit door after a bad package upgrade. It is useful, but it is not magic. A VPS snapshot records a point-in-time state of virtual disks and, depending on the platform, some machine settings or the VM’s memory state. It gives you a fast rollback path, not a complete recovery plan.

Most snapshot systems use copy-on-write storage. The existing blocks are not copied in full when you create the snapshot. When the VM later changes a block, the original is kept for the snapshot and the new version is written separately. Creation can therefore be quick. Keeping the snapshot for weeks, however, can consume substantial storage as changed blocks accumulate.

The button labelled Take snapshot does not guarantee application consistency. A database might be writing several related files when the snapshot is captured. The resulting disk may be consistent enough to boot while still requiring database recovery. Those are different things.

Use it this way: treat a snapshot as a quick rollback point, and treat independent, tested backups as your actual recovery plan.

Snapshot or backup?

A snapshot usually remains tied to the provider’s storage infrastructure. If your VPS account, storage cluster, or provider becomes unavailable, the snapshot may disappear with it. A backup can be copied to separate storage, another region, or another provider. The familiar 3-2-1 approach means keeping at least three copies, on two kinds of storage, with one copy separated from the primary system.

Speed is where snapshots earn their place. A snapshot taken before an operating-system upgrade can return the whole virtual disk to its earlier state. If one configuration file was deleted, restoring several hundred gigabytes is unnecessary; rsync, borgbackup, or a database-specific backup is a better tool.

A snapshot also may not expose a deleted file conveniently. Some control panels restore only the entire disk. Extracting one file can require creating a temporary disk or a new VPS from the snapshot, which adds time and storage cost.

Read the provider’s documentation before relying on the feature. Check where snapshots are stored, how they are billed, whether attached data disks are included, and how deletion works. The same word describes different implementations.

Use it this way: before restoring an entire VPS to recover one file, check your file and database backups first.

Before you press the snapshot button

The safest snapshot is taken while application writes are controlled. For a web server, briefly reducing traffic may help. For a database, use its own flush, backup, or maintenance mechanism. A clean shutdown is simpler, although production traffic does not always allow one.

A practical pre-snapshot check

• Confirm the VPS hostname and ID in the provider panel.
• Check disk usage and leave room for snapshot growth.
• Review active database writes and long-running deployment jobs.
• Record the date, purpose, and rollback reason in the snapshot description.
• Note possible effects on DNS, queues, and external APIs.

On Linux, I start with a small state check:

hostnamectl
findmnt /
df -hT
free -h
systemctl --failed

df -hT shows disk usage and filesystem types. findmnt shows what is mounted. The commands do not create a snapshot; they help confirm that I am on the expected machine and show its current state.

For a WordPress VPS, I also create a database export before taking the snapshot. The post titled How to Install WordPress on a VPS: Step-by-Step Guide covers the application setup, but recovery still needs its own test. A successful snapshot job does not prove that WordPress, PHP-FPM, and the database will start correctly after a rollback.

I keep this check deliberately boring. Boring is good when the alternative is restoring the wrong machine.

Creating a snapshot with Proxmox

In Proxmox VE, you can create snapshots from the web interface or with qm. The example uses VM ID 101. Confirm that ID with qm list before running anything.

qm list
qm snapshot 101 before-kernel-update --description "2026-09-24 before kernel update"
qm listsnapshot 101

The first command lists the VMs. The second creates a named snapshot. The third displays the snapshot tree. The description matters more than it seems; six months later, it tells you why the snapshot exists.

If you want to include the VM’s RAM state, Proxmox supports the --vmstate option. The snapshot storage needs enough space for that memory image. A disk snapshot and a RAM snapshot are not interchangeable. Without the RAM state, restoring normally means booting the guest again rather than returning it to the exact previous running state.

qm snapshot 101 before-upgrade --description "Before package upgrade" --vmstate

On the Proxmox version I use, that option is available for snapshot creation, but storage support and command behavior can vary. Check the command help and your storage documentation before using it in production.

Rollback is more destructive:

qm rollback 101 before-upgrade

Data written after the snapshot may disappear. Preserve important logs, new uploads, and database exports before running the command. Proxmox storage types such as ZFS, LVM-thin, and Ceph can differ in snapshot capacity, deletion time, and dependencies. Check the VM ID twice.

Can you snapshot a running VPS safely?

The claim that snapshots must never be taken on a running server is too absolute. Saying they are always safe is just as misleading. The platform may capture the guest filesystem while application data is changing. Static files are usually less difficult than MySQL, PostgreSQL, Redis, or a busy mail queue.

The cleanest option is to shut down the VPS during a maintenance window and then take the snapshot. If that is not possible, use the application’s own flush or backup mechanism. A logical MySQL dump, pg_dump, or a database-specific physical backup gives you another recovery layer.

If the QEMU Guest Agent is enabled, the virtualization platform can communicate with the guest in a more controlled way. It does not automatically pause every database operation safely. It is a coordination channel, not a replacement for database-aware backups.

I use Proxmox on my homelab Dell OptiPlex because experiments should fail there, not on a customer VPS. Even there, I do not treat a green snapshot status as an application test. The guest can boot and still have a broken service dependency.

After creating or restoring a snapshot, inspect service states, logs, and application data. A web server can show active while the PHP-FPM socket or database service is unavailable. The post titled How to Fix WordPress Error Establishing a Database Connection describes symptoms that can also appear after a rollback if connection settings or socket files returned to an older state.

Retention, storage, and the snapshot you forgot

Snapshot cost cannot be calculated from the VPS’s total disk size alone. With copy-on-write storage, usage depends on the blocks changed after the snapshot and how long the snapshot chain remains. Providers may bill by reserved capacity, consumed storage, or a fixed snapshot fee.

For a rough estimate, track how much data changes each day and compare it with the retention period. A 100 GB server changing 8 GB of unique blocks per day does not mean that seven snapshots will consume exactly 700 GB. Rewritten blocks, compression, deduplication, and the provider’s storage design all affect the result. Use the usage figure reported by the panel when available.

Keeping too many snapshots creates storage and management problems. Taking one for every deployment can leave old images in place indefinitely. I prefer a small number of operational rollback points, a temporary snapshot for a risky upgrade, and external backups for longer retention.

Deleting a snapshot may also take time. An older image can still hold blocks referenced by other snapshots in the chain, so storage usage may not fall immediately after deletion.

Set an owner or expiry date in the description. A snapshot without a reason eventually becomes archaeological evidence.

Restoring without making the outage longer

A rollback does not only restore old files. It can affect every disk and configuration change included in the snapshot. Users created afterward, installed packages, database records, and logs may disappear. Copy anything that must survive to separate storage first.

Before rolling back

• Verify the target VPS hostname and IP address.
• Check the snapshot date and description.
• Copy data created after the snapshot to external storage.
• Record DNS TTL values, queues, and external service connections.
• Tell users that the rollback will interrupt service.

After the rollback, inspect the basic state before restarting services at random:

hostnamectl
systemctl --failed
journalctl -b -p err..alert --no-pager
df -hT
ss -lntup

journalctl -b shows logs from the current boot, while ss -lntup lists listening TCP and UDP ports. If the web server is not listening on ports 80 and 443, or the database is not listening on 3306 or 5432, fix that layer before testing the application.

A rollback may not require a DNS change. Still, verify the records if the provider also restored older network settings:

dig +short example.com

That command checks the address visible through DNS more directly than relying on an assumption in the panel. DNS is not the only dependency. Check queues, webhooks, payment callbacks, and external API credentials too.

Snapshots are useful before operating-system upgrades. For changes involving the kernel, bootloader, or disk layout, check the provider’s rollback guarantees separately. Confirm that rescue access and the console connection work before the upgrade. Those options matter when the machine does not boot normally.

Snapshots belong beside backups

A sensible plan does not make the snapshot its only recovery method. For a WordPress VPS, I might combine daily database dumps, versioned external file backups, a weekly full backup, and a temporary snapshot before package upgrades. Copying backups to another provider or separate storage account reduces the risk of losing everything with the VPS account.

Write recovery targets in two measurements. RPO is the amount of data loss you can accept. RTO is the time you can accept before service is restored. A snapshot may return you quickly to the state from 15 minutes ago, but it does not preserve orders created during those 15 minutes. A database backup may protect newer data while taking longer to restore.

Do not assume a backup job succeeded because cron produced output. Check the file size, checksum, backup log, and an actual restore attempt. I have seen jobs report success while producing an archive that was useless for recovery. An untested backup is mostly hope.

The post titled Cloud Migration Checklist: A Step-by-Step Planning Guide also treats pre-migration verification as a separate task; a snapshot is one safety measure before migration, not the whole plan. If you are changing Nginx, the post titled How to Install and Configure Nginx on Ubuntu is useful for the setup steps, but back up the existing configuration files separately.

Connect snapshot jobs to monitoring. A failed snapshot, filling storage, or deletion that takes much longer than expected should create an alert. A dashboard showing only the date of the last job is not enough if that copy was deleted or never restored successfully.

Before the next upgrade, answer one plain question: if this rollback removes today’s data, where will that data come from?

Before You Take or Restore a VPS Snapshot

• Confirm the VPS hostname and ID.
• Check disk usage and available snapshot storage.
• Review database writes and running deployments.
• Export application data that needs independent protection.
• Record DNS, queue, and external API dependencies.
• Save data created after the snapshot before rolling back.
• Test services, logs, ports, and application integrity after restoration.

Frequently Asked Questions

Sources

• Proxmox VE Administration Guide — pve.proxmox.com
• NIST – Data Integrity, Recoverability, and Resilience in Cloud Computing — nist.gov