Many VPS owners assume that taking a snapshot means they have a backup. In reality, snapshots and proper backups only look alike and protect against different problems. A snapshot is a quick way to roll a system back, while a backup is an independent copy that lets you recover even if the whole server is gone or your data was corrupted days ago. People usually discover this difference at the worst possible moment, when they actually need the copy.
What a snapshot is and how it works
A snapshot records the state of a virtual machine's disk at a specific moment. Most of the time it does not copy everything: the virtualization layer freezes the current blocks and writes later changes separately. That is why a snapshot takes seconds or minutes and restoring it is fast. Taking one before an OS upgrade or a PHP version change is a good habit, because if something breaks you are back in a working state within minutes.
However, snapshots usually live on the same infrastructure, often on the same storage system. If the storage array fails, someone gets into the account, or the server is deleted, the snapshot may disappear with it. A snapshot of a running server is also only crash-consistent, similar to the state after a sudden power cut. The file system typically copes, but database transactions still held in memory may not be fully saved.
Why a backup is a separate thing
A backup is a copy of your data moved somewhere else and independent of the server: another server, S3-compatible object storage, or a disk in your office. A good backup keeps several versions, such as yesterday, last week and last month. This matters because many problems are not noticed right away. If a site is hacked and malicious code is injected, you may only find out after a week or two, and only an older version is clean. Backups typically cover what really matters: site files, database dumps and configuration such as /etc/nginx, cron jobs and application settings.
| Criterion | Snapshot | Backup |
|---|---|---|
| Creation speed | Seconds to minutes | Minutes to hours, depending on size |
| Location | Usually same infrastructure | Separate server or storage |
| Contents | Whole disk state | Selected files and DB dumps |
| If the server is lost | Often lost too | Still available |
| Best use | Rollback point before changes | Long-term protection, full recovery |
Backing up databases correctly
Copying the raw files of a running MySQL or PostgreSQL database is risky because they change while you copy them. Use the database's own dump tools instead. For InnoDB tables, --single-transaction produces a consistent copy without locking, so the site keeps running. Then ship the dump off the server with rsync over SSH, or use restic or borg for encryption, versioning and deduplication.
mysqldump --single-transaction --routines --triggers -u backup -p shop_db | gzip > /backup/shop_db_$(date +%F).sql.gz
pg_dump -U postgres -Fc clinic_db > /backup/clinic_db_$(date +%F).dump
restic -r sftp:backupuser@backup.example.uz:/srv/restic backup /var/www /etc /backup
restic -r sftp:backupuser@backup.example.uz:/srv/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneA practical example: a Tashkent online store
Picture a small appliance store in Tashkent running misol.uz on a VPS with WooCommerce and MySQL. Every night at 03:00 a cron job dumps the database and sends it, together with /var/www and /etc, to a backup server in another city via restic, keeping 7 daily, 4 weekly and 6 monthly copies. Before every plugin or PHP update, the admin also takes a snapshot. When a new payment plugin caused a blank page, a snapshot rollback fixed it in five minutes. When an employee broke the price table with a bad SQL query that was noticed two days later, the snapshot was useless because rolling back would erase new orders. A three-day-old backup saved the day: only that one table was restored from the old dump.
The 3-2-1 rule and testing restores
The 3-2-1 rule says to keep at least three copies of your data, on two different types of storage, with one copy offsite. For a VPS, that can be the live data, a restic repository on another server and a periodic copy downloaded to an office disk or another cloud. The most neglected step is testing restores. Once a month, restore the latest copy on a test server and check that the dump opens and the site starts, and make sure the backup script alerts you when it fails.
restic -r sftp:backupuser@backup.example.uz:/srv/restic restore latest --target /tmp/restore-test
gunzip -t /tmp/restore-test/backup/shop_db_*.sql.gz && echo "dump OK"When to use which
Use snapshots as a short-term safety net before big changes and delete them once everything works, since old snapshots consume space and can slow storage on some platforms. Build backups to be continuous, automated and stored off the server. If your VPS runs at sayt.uz, you can ask about snapshot or backup options through the cabinet or support, but keeping an independent copy of your own data under your control is still wise. In short, a snapshot is an undo button, while a backup is your guarantee of coming back even if everything is lost.