VPSTabEvidence-first VPS decisions
Search2026.10.25-v7
Menu
Find a VPSProvidersPlansReviewsCompareUse casesGuidesMethodology
English
English简体中文日本語한국어DeutschFrançaisРусский
Guides

Backup and restore planning for a single VPS

Turn provider backup features into a restore plan you have actually tested, with realistic pricing and failure cases.

Last reviewedOct 24, 2026 · 1033 words

A backup is a restore you have performed

A provider checkbox labelled 'backup' is not a recovery plan. The useful question is what happens after the machine is gone: how long it takes to get a working replacement, what exactly is restored, and what data you lose in the gap. A snapshot of a running database is often inconsistent; a backup kept only on the same provider disappears with a billing problem; and a backup you have never restored is a hypothesis, not a capability.

This guide separates the three layers that matter: the data you cannot rebuild (business records, user uploads, keys), the configuration you can rebuild from source control, and the provider features you pay for. Each layer needs a different recovery time and a different test.

What providers in this catalog actually offer

DigitalOcean documents weekly backups at 20 percent of the Droplet price and daily backups at 30 percent, disabled by default. Linode publishes fixed monthly backup add-on prices per plan size, which makes the long-term cost easier to calculate than a percentage. Hostinger includes weekly backups with its KVM plans at no extra charge, while BuyVM sells nightly backups at 10 percent of the base price with a 0.50 dollar monthly minimum and includes five free snapshots. OVHcloud includes a daily 24-hour backup with its VPS plans and sells a premium 7-day backup and snapshots as separate options. Hostens offers a backup add-on for one dollar per month on its Linux plans. Contabo sells Auto Backup as a paid add-on with 10-day incremental retention.

Those differences matter more than the headline price. A 24-hour retention window means an accidental deletion discovered two days later is unrecoverable from the provider backup; a weekly schedule means up to seven days of loss. Percentage pricing scales with the plan, so a cheap plan today becomes a more expensive backup line after an upgrade.

Design the restore path before choosing the add-on

Write down the recovery point objective (how much data you can lose) and the recovery time objective (how long the service can be down). For a brochure site rebuilt from a repository, a weekly snapshot and a 30-minute rebuild may be enough. For a small store, order data usually cannot be recreated, so a daily database dump stored off-provider plus a tested restore procedure is the minimum. For a media library, the storage volume matters more than the operating system, and restoring hundreds of gigabytes takes hours regardless of the provider's backup feature.

Then check that the provider's feature can meet those objectives. If the only backup is a same-provider snapshot with 24-hour retention, it cannot satisfy a requirement for 30-day retention or protection against account loss. Add an independent copy: an object storage bucket, an external host, or an encrypted archive you download on a schedule. The cost of that copy is part of the plan, not an optional extra.

Restore drills you can run this month

Start with a file-level restore: delete a known test file on a staging copy and restore it from the backup. Then restore a database dump into a separate database and run a query that proves row counts and the newest records. Finally, rebuild the whole instance from the provider image and backup, attach the data, and measure the time. Each drill should produce a dated note: what was restored, how long it took, and what failed.

Keep the drill target separate from production. Restoring over a live server to 'test' the backup is how small mistakes become outages. A second small instance or an isolated schema is enough for the data checks, and it doubles as the place where you verify that keys, environment configuration and scheduled jobs are covered by the plan.

Encryption, retention and access

Provider snapshots are usually encrypted at rest by the provider, but that protects the storage medium, not your account. If an attacker controls the account, snapshots are reachable. For archives you download, encrypt them yourself and keep the key somewhere that is not the server being backed up. Record who can read the backup location and remove access for people who no longer need it.

Retention should be deliberate: daily copies for a week, weekly copies for a month, and a monthly copy kept longer for the data you cannot rebuild. More retention is not automatically better if nobody verifies that the old copies still restore. A smaller, tested set beats a large untested archive.

Common failure cases

The database is backed up while it is writing, producing a corrupt dump: use a consistent dump mechanism or a filesystem snapshot taken with the database quiesced. The backup lives only on the same provider and the account is suspended: keep an off-provider copy. The restore needs the same operating system version and the provider image has moved on: document the base image and pin it where possible. The backup includes data but not the configuration: store environment files and infrastructure notes separately, without secrets in the repository.

None of these failures requires an exotic setup to prevent. They require writing down the recovery path and testing it before the incident. If the provider does not publish backup pricing or retention, that is an unknown to verify, not a gap to fill with an assumption.

Write the plan in the same place as the runbook you will actually open during an outage: which snapshot or dump to use, where the credentials live, who approves a restore, and how you will confirm that the restored service is healthy before routing traffic back. A one-page plan that names the provider feature, the independent copy, the restore command and the verification query is worth more than a long policy document nobody reads. Review it after every drill, because the gaps you find are usually in the steps you assumed were obvious.

Verification checklist

  • Write down the maximum acceptable data loss and downtime.
  • Confirm the provider backup schedule, retention and price.
  • Keep at least one copy outside the provider account.
  • Encrypt downloaded archives and store keys separately.
  • Restore a file, a database and a whole instance as drills.
  • Record the drill date, duration and failures.
  • Treat unpublished backup terms as unknown until verified.

Sources