Back Up and Restore Linux Files with Restic on a VPS

Restic creates encrypted, deduplicated snapshots of selected files. It can be useful on a self-managed Linux VPS, but a file snapshot is not a bootable VPS image, a database-consistency mechanism or a promise of hosting-plan backup retention. You remain responsible for selecting data, protecting repository credentials and proving recovery.

Plan an independent repository

Choose a supported repository backend and storage outside the source server’s failure domain. For SFTP storage, use a dedicated authorized account and verify the SSH host key independently. The backend must provide the operations restic needs; an arbitrary upload-only account is not necessarily compatible. Protect both the SSH identity and the repository password, and keep a separate recovery copy available if the VPS is lost.

Use an existing repository’s real password and location during recovery. Do not run restic init to “repair” an inaccessible repository: it creates a new one rather than recovering snapshots. Never overwrite an existing password file with a newly generated password for the old repository. Losing every usable repository key/password can make encrypted backups unrecoverable.

Practice a backup and restore locally

This Bash fixture deliberately uses a new private local repository and synthetic text. It demonstrates the workflow, not off-server protection or a real VPS restore. It needs restic and OpenSSL installed from maintained sources.

umask 077
lab=$(mktemp -d)
cd "$lab" || exit 1
mkdir source
printf 'synthetic website file\n' > source/index.txt
openssl rand -base64 32 > repository-password
export RESTIC_REPOSITORY="$lab/repository"
export RESTIC_PASSWORD_FILE="$lab/repository-password"
restic init
restic backup source --tag practice
restic snapshots
restic check --read-data
mkdir restored
restic restore latest --target "$lab/restored"
cmp source/index.txt restored/source/index.txt

The new temporary directory prevents collisions with an existing repository or password file. Both are on one disposable machine here, so they are not a production recovery design. The comparison establishes only that the fixture file restored byte-for-byte. check --read-data reads repository data and can incur significant storage traffic and time on a real repository.

Capture the right application data

Inventory application files, uploads, configuration, service definitions, certificates and protected database exports. Verify every required source exists and has the expected mount and permissions before starting. Do not assume a zero exit status means an omitted path was included; inspect warnings, exclusions and the resulting snapshot. Restic has distinct nonzero outcomes, including incomplete source reads, that monitoring must not silently treat as success.

For a running database, take an application-consistent dump or another supported consistent backup before copying its artifact. Restic reading live database files is not equivalent. A static site’s content backup also does not recreate the operating system, users, firewall, DNS, dependencies or database service.

Automate with monitored completion

Use a dedicated protected wrapper, absolute paths and the intended account. Load repository configuration without exposing passwords in command arguments, public files or logs. Check source/mount prerequisites, avoid conflicting maintenance, retain useful errors and alert on missing completed snapshots. Observe an actual scheduled run and restoration before relying on it. A manual command succeeding does not prove cron has the same environment.

Restore without replacing production first

1. Prepare a clean compatible recovery environment and obtain the existing repository’s credentials independently of the failed server.
2. List snapshots and select an explicit intended snapshot rather than assuming the newest is clean.
3. Restore into a fresh staging directory. Inspect ownership, secrets, file scope and trusted checksums; validate application and database compatibility.
4. Plan service stoppage, data reconciliation, configuration validation and rollback before switching live paths. Do not automatically move over a working web-server configuration or newer customer data.
5. Test the recovered application, permissions and external dependencies. Keep the previous state until recovery is accepted.

Review forget retention with its dry-run option before any deletion, and understand how pruning reclaims shared data. Do not use forced unlock as a routine response while another process may be active. Encryption does not make a writable repository immutable against an attacker holding its credentials; independent retention and access controls still matter.

References: repository preparation and SFTP, backup behavior, restore workflow and retention and pruning.

Reviewed October 15, 2026. The local fixture’s backup, full data check and byte comparison were executed in a disposable container. No external storage, production timer, performance benchmark or full VPS recovery was tested.