Most of the recovery tickets we handle at Cybeward start the same way: a change went sideways, and the customer wishes they had taken a snapshot first. They almost always could have — it takes seconds — but the habit wasn’t there yet. This guide is about building that habit, and about understanding exactly what a snapshot does for you so you don’t lean on it for the wrong job.
Every Santiago plan includes two snapshot slots out of the box. You don't pay extra to use them, and you can keep, replace, or delete them as you like.
What a snapshot actually is
A snapshot is a point-in-time image of your VDS disk. At the moment you take it, Cybeward records the exact state of the disk — files, packages, configuration, the lot — and stores it on the same NVMe-on-Ceph storage that backs your server. If a later change goes wrong, you roll back and the disk returns to that recorded state.
What it is not is an offsite backup. The image lives in the same storage cluster as your live disk. Ceph keeps multiple replicas, so it survives a failed drive without blinking — but it is still operationally close to your VDS. A snapshot protects you against your own changes. It is not designed to protect you against a catastrophe that takes out the whole environment, nor against slowly accumulating data loss you only notice weeks later.
A snapshot answers one question: “can I undo what I just did?” If your question is “can I recover from a disaster three months from now?”, you need a backup.
When to take one
The rule of thumb is simple: snapshot before any change you’d hate to do twice by hand. In practice that means:
- Before OS updates — a kernel or library upgrade that breaks boot is the classic case.
- Before config changes — editing
sshd_config, web server vhosts, firewall rules, anything where a typo locks you out. - Before app deploys — a new release that won’t start, or a migration that mangles state.
- Before migrations — moving a database schema forward, or shuffling data between services.
The common thread is that all of these are reversible in theory but painful in practice. A snapshot turns “spend the afternoon rebuilding” into “click rollback, try again.”
Heads-up. A snapshot freezes the disk, not the clock. Anything written to disk after you take it — new orders, uploaded files, log entries — is gone if you roll back. Plan around that, especially on busy systems.
How to create and roll back
Both actions live in your Cybeward portal, under the snapshots area for your server. Creating one is quick:
1. Open your server in the portal 2. Go to the Snapshots tab 3. Click "Create snapshot" and give it a clear name 4. Wait for the status to switch to "ready"
Name it for what you’re about to do — before-php8.3-upgrade beats snapshot-1 when you come back in a panic. The image is ready in moments; on NVMe-on-Ceph the capture is near-instant for typical disk sizes.
Rolling back is just as direct:
1. Open the Snapshots tab 2. Select the snapshot you want 3. Click "Roll back" and confirm
The server reverts to the recorded state. We recommend shutting the VDS down (or at least quiescing your database) before a rollback so the disk image you return to is clean and consistent.
Where snapshots stop being enough
This is the part people learn the hard way, so we’ll be blunt: a snapshot is not a substitute for real backups — especially for databases.
Two reasons. First, location: snapshots sit in the same storage as your live disk. Real backups should be somewhere your server can’t take down with it. Second, point-in-time consistency. A database snapshotted while it’s mid-write can roll back into a half-finished transaction. For anything with a database, run a proper logical or physical backup (a pg_dump, a mysqldump, a WAL stream) on a schedule, and keep it off the box.
Snapshots are your fast undo button for the change you’re making right now. Backups are your safety net for the future. You want both.
Buying extra slots
Two slots cover most workflows: one “known-good” baseline and one you cycle before each risky change. But if you run several environments on one server, do staged deploys, or want to keep a longer history, you can buy additional snapshot slots from the portal. Dedicated backup slots are available the same way for the offsite, scheduled protection snapshots can’t give you. Add what you need, drop it when you don’t — no long commitments.
Snapshot before you…
Keep this list somewhere visible. If you’re about to do any of these, take ten seconds first:
- run
apt upgradeor any kernel update - edit
sshd_config, firewall rules, or networking - deploy a new application release
- run a database migration
- change anything you can't easily reproduce by hand
Build the habit and most “help, I broke it” moments turn into a thirty-second rollback. And when you genuinely need to recover days-old data, you’ll be glad you set up real backups too — but that’s a guide for another day.
