VPS backups: a strategy that survives a real failure
A copy is useful only when it contains consistent data, remains available after the original account fails and can be restored within the required time. Build the plan from business recovery targets, not from a backup button.
Start with RPO and RTO
Recovery point objective (RPO) is the maximum acceptable data loss. Recovery time objective (RTO) is how long restoration may take. A brochure site may tolerate a day-old copy; an order database may require hourly or continuous protection. These targets determine frequency, retention, storage and cost.
Use complementary backup layers
| Method | Strength | Limitation |
|---|---|---|
| Provider snapshot | Fast full-server rollback | Often tied to the same provider account |
| Database dump | Portable and logically consistent | Restore can be slow for large databases |
| File-level incremental copy | Efficient history and individual file recovery | Requires careful exclusions and permissions |
| Object storage with versioning | Independent, durable retention | Egress and request costs |
| Infrastructure configuration | Recreates a clean server | Does not preserve user data |
The 3-2-1 rule is a useful baseline: three copies, on two types of storage, with one off-site. For a VPS, the original data, a provider snapshot and an encrypted copy in a separate account or provider form a practical start.
Create application-consistent copies
Do not copy a live database directory as ordinary files. Use the database's logical dump, physical backup or replication tooling and verify its exit status. Coordinate file uploads and database records if they refer to each other. For virtual-machine snapshots, briefly quiesce the application or use a provider feature that guarantees filesystem consistency.
Back up more than content: include web server configuration, environment templates, scheduled jobs, service definitions and a list of required versions. Store secrets separately and document how to obtain them during recovery.
Encryption, retention and cost
- Encrypt archives before they leave the VPS.
- Keep encryption keys outside the server and backup bucket.
- Use an account independent from the production administrator where practical.
- Enable retention lock or object versioning against accidental deletion.
- Alert on missed jobs, zero-byte output and abnormal archive size.
- Budget for storage, requests, egress and temporary restore capacity.
A common retention schedule keeps daily copies for a week, weekly copies for a month and monthly copies longer. Adapt it to regulation and how long corruption might remain unnoticed.
Restore testing is the decisive test
Automate checksums and archive inspection, but also restore the complete service onto a clean temporary host. Measure the time, run migrations, open representative pages and verify a real record. Test after changing the database version, backup tool, encryption process or infrastructure.
Write a short runbook with storage locations, credentials process, exact order of restoration, DNS switch and responsible person. During an outage, concise verified instructions outperform memory.
Frequently asked questions
Is a VPS snapshot a backup?
It is a useful rapid rollback layer, but not sufficient alone. Add independent database and file copies outside the same provider account.
Must I stop the site?
Usually not. Database tools can produce consistent online backups, but file writes and cross-system consistency still need planning.
How often should restoration be tested?
After relevant changes and on a schedule. Quarterly may be a baseline for a small site; critical services need more frequent exercises.
Where should the encryption key live?
In a secret manager or protected organisational vault with an independent emergency copy, never only on the VPS.
Related: NVMe versus SSD for VPS workloads.