VPS Backups: Snapshots, Offsite Copies and Restore Tests

A VPS recovery plan needs consistent application data, a copy outside the VPS’s failure boundary and a tested way to rebuild or restore the service. A snapshot can be useful for rollback, but its existence alone does not prove database consistency, independent retention or recovery after loss of the original account or host.

Define acceptable loss and recovery time

Write down how much recent data the service can lose and how long it can remain unavailable. These are recovery-point and recovery-time objectives. A daily backup cannot meet a requirement to lose no more than one hour of new records without another recovery mechanism.

Inventory the recovery set
Data	Include
Application state	Uploads, persistent directories and database backups
Configuration	Service units, reverse proxy, schedules and deployment versions
Access	Protected secrets and the credentials needed to reach backup storage
Infrastructure	OS/runtime versions, addresses and required provider settings
Recovery procedure	Order of restoration, validation and final cutover

Capture a usable application state

Use the database’s documented logical or physical backup method. Copying active database files like ordinary documents can produce an unusable or inconsistent result. If files and database rows describe the same operation, coordinate their capture or stop writers during a maintenance interval.

Check what a provider snapshot actually guarantees: powered-off, crash-consistent and application-consistent captures are different. Confirm whether attached volumes are included. Keep enough independent generations to recover from damage discovered after the most recent backup already contains it.

Protect the copy and its keys

Store a copy somewhere that survives loss of the VPS and its primary storage. Use encryption where appropriate and protect repository credentials. If the only decryption key exists on the lost machine, encrypted backups cannot be restored. Limit deletion authority and consider retention controls supported by the destination.

Restore into a separate directory or machine

For an existing restic repository, the commands below list snapshots, check repository structure and restore a chosen snapshot into a new target. Configure repository access securely beforehand. Replace the snapshot ID and target; do not restore blindly over live application paths.

restic snapshots
restic check
restic restore SNAPSHOT_ID --target /srv/restore-check-YYYYMMDD

A basic restic check does not read and verify every stored data pack by default. Follow its documented data-check options when planning a deeper integrity check, including the associated read time and storage charges. Neither metadata checks nor file restoration establish application correctness on their own.

Restore the selected files and database into an isolated environment with compatible software.
Disable scheduled writers, payment hooks, emails and other external side effects during the rehearsal.
Start the service privately and verify representative records and user workflows.
Check ownership, permissions and persistence after restart.
Record elapsed time, missing prerequisites and the exact snapshot identifiers used.

Alert on recovery risk, not just job completion

Monitor the age of the last successful backup, failures, storage capacity and restore-test recency. A scheduler that ran successfully can still have backed up the wrong directory. Preserve the previous good generation until the new set passes its checks; retention cleanup should not erase your only known recovery point.

Use VPS monitoring for alert design. When comparing VPS hosting, ask which snapshots or backups are included and which independent recovery work remains your responsibility.