VPS Snapshots and Rollbacks: Your Safety Net for Server Changes

A snapshot captures your VPS disk at one point in time. If something goes wrong, roll back to the snapshot. It's an undo button for your server.

Snapshots vs Backups

Use both. Snapshots for safety before changes, backups for daily protection.

When to Take Snapshots

Snapshot Strategy

Pre-Change Snapshot

1. Take snapshot
2. Make change
3. Test thoroughly
4. If good: delete snapshot (save space)
5. If bad: restore snapshot

Scheduled Snapshots

Manual Backup Script

If your provider doesn't offer snapshots, create your own backup system:

#!/bin/bash
BACKUP_DIR="/backup"
DATE=$(date +%Y%m%d-%H%M)

# Create backup directory
mkdir -p $BACKUP_DIR

# Backup web files
tar czf $BACKUP_DIR/www-$DATE.tar.gz /var/www/

# Backup databases
mysqldump --all-databases > $BACKUP_DIR/db-$DATE.sql
# PostgreSQL: use this line instead (all databases plus roles)
# sudo -u postgres pg_dumpall > $BACKUP_DIR/pg-$DATE.sql

# Backup configurations
tar czf $BACKUP_DIR/etc-$DATE.tar.gz /etc/

# Remove backups older than 7 days
find $BACKUP_DIR -name "*.tar.gz" -mtime +7 -delete
find $BACKUP_DIR -name "*.sql" -mtime +7 -delete

echo "Backup completed: $DATE"

For PostgreSQL, pg_dump (one database) and pg_dumpall (all databases plus roles) work while the database stays in use. Each database comes out internally consistent, but pg_dumpall dumps the databases one after another, not all at the same moment. Dumps like these fit a small database such as a bot or a website. Our PostgreSQL backup guide shows how to take, restore and schedule them. Beyond simple cases, the PostgreSQL manual says pg_dump is generally not the right choice for regular backups of production databases; use pg_basebackup with WAL archiving there, which also allows point-in-time recovery.

Save the script as /root/backup.sh, make it executable with sudo chmod 700 /root/backup.sh, then open root's crontab with sudo crontab -e and add this line to run it every night at 02:00:

0 2 * * * /root/backup.sh >> /var/log/backup.log 2>&1

Off-Site Backups

Never keep all backups on the same server. If the server dies, so do your backups.

To Remote Server

rsync -avz /backup/ user@remote-server:/backups/vps1/

To Object Storage

# Using rclone to sync to any cloud storage
rclone sync /backup/ remote:vps-backups/

rclone sync makes the remote match the folder, so it also deletes the remote copies that the script removed after 7 days. Use rclone copy instead if the remote should keep older backups, and test either command with --dry-run first.

Disaster Recovery Plan

How long each recovery takes depends on how much data you restore and where it comes from. None of the provider pages under "Restoration: what actually happens" below gives a restore time, so time a test restore on your own setup.

Recovery Checklist

1. Assess what happened
2. Decide: snapshot restore or selective file restore?
3. If snapshot: restore and verify
4. If selective: restore specific files/databases
5. Test everything works
6. Investigate root cause
7. Prevent recurrence

Testing Your Backups

A backup only counts once you have restored it. Until a test restore has worked, it is a backup that might not work. PostgreSQL's manual makes the same point about its own checker, pg_verifybackup: even if you use it, you should still perform test restores and check that the restored databases work and contain the correct data.

A Space-Node VPS is KVM with full root access and NVMe storage, so you can run the backup script, rsync and rclone from this guide yourself. The plan features do not list snapshots, and backups are not included in the plan price: open a ticket and support tells you the backup option, how long backups are kept, how a restore works and what it costs. Keep your own off-site copies either way.

What a VPS snapshot is and isn't

A snapshot is a copy of your VPS disk at a single moment. Cloud providers such as Hetzner Cloud, OVHcloud and AWS make it from their control panel or API. On a self-hosted Proxmox VE host, the storage under the disk makes it: ZFS, LVM-thin, Ceph RBD and qcow2 files all support snapshots. Two properties matter:

1. Consistency: a snapshot of a running server is at best crash-consistent. The disk looks as if the power was cut at that moment: filesystems recover through their journal and databases through their own logs, and the section on application-consistent snapshots below shows how to do better for a database. Hetzner's FAQ (checked 31 October 2026) recommends powering the server off before a snapshot and says it cannot guarantee data consistency for a snapshot of a running system.
2. Location: where the snapshot is stored decides what it survives. A ZFS snapshot lives in the same pool as the data it copies. Hetzner Cloud stores snapshots in a different location from the server, except in Ashburn, Hillsboro and Singapore, and AWS keeps EBS snapshots in Amazon S3, replicated across the Availability Zones of the Region (both checked 31 October 2026).

A snapshot on the same storage as the disk is not a backup: if that storage or host fails, the snapshot goes with it. A snapshot stored elsewhere still sits with the same provider and account, so keep an off-site copy that you control as well.

Which copy survives what

Snapshots are great for "I'm about to do something stupid". Backups are for "the building burned down".

Restoration: what actually happens

What a restore does differs per provider. These are the steps in each provider's own documentation, checked on 31 October 2026:

None of these pages gives a restore time. AWS says a volume created from a snapshot first downloads its blocks from Amazon S3, with higher I/O latency until that is done, and that the default rate "could make completion times unpredictable". Hetzner and OVHcloud both warn that data written after the snapshot is lost.

Of these pages, only AWS says what happens to IP addresses: a root volume replacement keeps the instance's network interfaces, its public and private IP addresses and its DNS name. A new server created from a snapshot is a separate server, so check its addresses before you point DNS at it.

Application-consistent snapshots

For MySQL, take the snapshot while one client session holds FLUSH TABLES WITH READ LOCK, then run UNLOCK TABLES in that same session. MariaDB accepts the same statements, but its manual recommends BACKUP STAGE in most cases: run BACKUP STAGE START and BACKUP STAGE BLOCK_COMMIT, take the snapshot, then run BACKUP STAGE END, all in one session, because a disconnect releases the backup stages.

For PostgreSQL, older guides wrap the snapshot in pg_start_backup/pg_stop_backup. Check your version before you copy that:

• PostgreSQL 15 and newer: those functions no longer exist. Version 15 renamed them to pg_backup_start/pg_backup_stop and removed the exclusive backup mode.
• PostgreSQL 14 and older: called with only a label, pg_start_backup starts an exclusive backup, which the manual calls deprecated because it can block an automatic restart after a crash. PostgreSQL 14 reaches end of life on 12 November 2026.
• Every version: these functions belong to the low-level base backup procedure, which starts with working WAL archiving. In non-exclusive mode the calling connection must stay open until the end, and the backup_label it returns must be written into the backup. A VPS snapshot does not need any of that.

What PostgreSQL does support is a snapshot of the whole disk in one go, even while the server runs. The manual treats it as a server that was not shut down properly: on start, PostgreSQL replays the WAL, and the manual calls that "not a problem" as long as the WAL files are in the backup. Run CHECKPOINT; just before the snapshot to shorten that replay. If the WAL or a tablespace sits on another disk, the snapshots may not be simultaneous: stop PostgreSQL while you take them, or make a base backup with pg_basebackup and WAL archiving instead.

To the database, a restored snapshot looks like a power cut. InnoDB and PostgreSQL recover from that on their own, unless durability settings have been switched off, such as fsync = off in PostgreSQL, which its manual warns can cause unrecoverable data corruption after a crash.

What rolling back can break

• Time-sensitive certificates: if you roll back past a renewal, certbot has to re-issue.
• Outbound webhooks: services that talked to you between snapshot time and now have stale state.
• DNS TTLs: if you rotated keys/IPs, clients may be cached.
• Database streaming replication: replicas need re-init after a primary rollback.

Plan rollbacks with these in mind. A snapshot is not a magic time machine.

Sources

All opened on 31 October 2026:

• Hetzner Docs: Backups/Snapshots overview, Backups/Snapshots FAQ
• OVHcloud: Backing up an instance, Using instance backups to create or restore an instance
• AWS: Amazon EBS snapshots, Create a volume, Initialize Amazon EBS volumes, Replace the root volume
• Proxmox VE: Storage, qm(1); OpenZFS: zfsconcepts(7)
• PostgreSQL: File system level backup, Continuous archiving, SQL dump, pg_dump, pg_dumpall, pg_verifybackup, WAL settings, PostgreSQL 14 continuous archiving, PostgreSQL 14 admin functions, PostgreSQL 15 release notes, versioning policy
• MySQL 8.4: Backup methods, InnoDB crash recovery, mysqldump
• MariaDB: FLUSH, BACKUP STAGE, Storage snapshots and BACKUP STAGE statements
• Tools: rsync(1), rclone sync, rclone copy, tar(1), find(1), chmod(1), crontab(1), crontab(5)