Backups are the part of VPS administration that is invisible until the day it saves you. There are no feature flags to admire, no dashboards to watch — and for exactly that reason, backup systems are the first thing to be neglected and the last to be tested. Then a deleted directory, a failed update or a corrupted database turns a five-minute fix into a recovery project, and everyone discovers what the backup strategy actually contained.
A backup strategy that works has three layers: capture, distribution and proof. Capture is the automatic snapshot or archive your host provides. Distribution means copies that survive the loss of the server itself — offsite storage. Proof is the restore drill that verifies the whole chain. This guide explains all three, in the order you should build them.
Why "We Have Backups" Is Not a Strategy
Two numbers define every backup plan: the recovery point objective (RPO) and the recovery time objective (RTO).
- RPO answers: how much data can we afford to lose? If backups run daily at 02:00, an incident at 23:00 can lose almost a full day of changes. If they run every hour, the maximum loss shrinks to an hour.
- RTO answers: how fast must we be back online? A 30-second snapshot restore and a weekend spent rebuilding a server from scratch are very different answers to the same question.
Without explicit RPO and RTO targets, "we have backups" means nothing measurable. Decide the numbers first — for a small production VPS, losing less than a day of data (RPO ≤ 24 h) and returning within hours (RTO ≤ 4 h) is a realistic starting point — then check every tool against them.
Snapshots and Automatic Backups
A snapshot is a point-in-time image of a virtual machine: its disk state at the moment the snapshot is taken. On KVM virtualization, snapshots are fast and consistent enough for regular scheduling. Open Vista operates its own KVM virtualization platform (Proxmox) and includes automatic backups with every NVMe VPS plan, which covers the capture layer by default — no configuration required from you.
What automatic snapshots do well: they protect against deletion, configuration mistakes, failed updates and corruption introduced during the backup window. What they do not do is protect you from losing the infrastructure itself — if the host or its storage is lost, snapshots stored alongside it can disappear with it. That is why the capture layer is only the first step, and why the offsite copy is not optional.
Two habits make snapshots more useful:
- Keep a sensible retention window. Enough history to go back several days (in case corruption is discovered late), without hoarding months of identical images.
- Take a manual snapshot before risky operations. Upgrading the OS, migrating data or changing major configuration? Trigger a snapshot first, so the rollback point is explicit rather than dependent on the schedule.
Offsite Copies: The 3-2-1 Rule
The classic backup rule still holds in 2026: keep three copies of your data, on two different types of media or systems, with at least one copy offsite — somewhere other than the server itself. The offsite copy protects against the scenarios snapshots cannot: hardware loss, provider-level incidents, ransomware that encrypts everything it can reach, and human errors that delete the wrong storage.
For a VPS, a practical offsite layer looks like this:
- Encrypted archives. Use a tool such as `rsync`, `restic` or `borg` to push encrypted, deduplicated archives to object storage or to a second server you control.
- Prioritise the data that cannot be rebuilt. Database dumps and configuration files are irreplaceable; an operating system can always be reinstalled. At minimum, the database should leave the server on its own schedule.
- Keep the keys separate. Encrypted backups are only useful if you can decrypt them — store the encryption keys somewhere other than the server being backed up, and document who holds them.
- Test the credentials. Offsite storage with an expired token or a forgotten account is storage that does not exist. Verify access during your restore drill, not during the incident.
Restore Drills: Testing What Actually Matters
A backup that has never been restored is a hypothesis. Restore drills are how you convert it into a fact. The drill answers three questions: is the backup complete, is it readable, and how long does recovery actually take?
Run drills on a schedule — quarterly is a reasonable cadence for a production VPS, plus one after any significant infrastructure change. A drill does not need to touch production: restore into a separate test VPS or environment, then verify the essentials:
- The operating system boots and the stack starts.
- The database imports cleanly and contains the expected data.
- Application configuration, secrets and cron jobs are present.
- The measured restore time fits the RTO you defined.
Write down the procedure as you perform it — the runbook you produce during a calm drill is the document that will guide you during a real incident. Note the support contacts and where the recovery documentation lives; on the actual day, nobody will remember the details you did not write down.
A Practical Backup Cadence
- Daily: automatic snapshots and, if your data changes frequently, database dumps.
- Weekly: an encrypted archive pushed offsite.
- Monthly: verify offsite archives are readable and retention is working.
- Quarterly: full restore drill into a test environment.
- Before any major change: manual snapshot plus a fresh database dump.
FAQ
What is the difference between a snapshot and a full backup? A snapshot captures the state of the virtual machine at one instant and is fast to restore, but it usually lives with the host infrastructure. A full backup — typically an encrypted archive — is a complete copy of your data that can be moved offsite and restored elsewhere. Production setups use both: snapshots for quick rollbacks, archives for disaster recovery.
Are automatic backups included with an Open Vista VPS? Yes — automatic backups are included with every Open Vista NVMe VPS plan, alongside a dedicated IPv4 address, a management panel and 24/7 support in English and French. Included does not mean untested: verify retention, and add the offsite copy for the data that matters most.
How often should I test my restore procedure? At least once a quarter, and again after major changes to the server or its applications. Restore drills take minutes on modern virtualization and they expose problems — missing files, wrong permissions, expired offsite credentials — while there is still time to fix them calmly.
Where should the offsite copy live? Anywhere that is not the same server, same host or same single point of failure: object storage in a separate account, a second server you control, or another provider. Encrypt the archives before they leave the server, and store the decryption keys separately.
Backups are cheap insurance until they are tested — and the tests are what make them real. Every Open Vista NVMe VPS plan includes automatic backups, a dedicated IPv4 address, a management panel and 24/7 support in English and French, with no contract and deployment in under 15 minutes. Compare plans at https://openvista.ma/en/vps and order at my.openvista.ma.