TL;DR / Summary: A small VPS is a good offsite backup target because it is far from your house and costs less than a streaming subscription. Restrict the SSH account, size storage for your real data plus retention, and prove a restore before you trust it.
What the VPS is for, and what it is not
This box holds one job: receiving encrypted backup snapshots from machines you own. It is not a media server, not a seedbox, and not a second home for your working files. The moment it becomes a general-purpose server, someone installs a control panel, a database, and a mail daemon, and the disk you budgeted for backups is gone.
Small is genuinely fine. A 1 vCPU, 1 GB machine with 100 GB of disk will hold years of incremental snapshots for a laptop and a small NAS, because restic stores each file once and only adds what changed. The workload is disk-bound and mostly idle.
Size storage against your real backup volume
Measure before you buy. Run one backup, then read the repository size with restic stats. A laptop with 300 GB of files may produce a 120 GB repository once compression and deduplication are applied, and then grow by two to five gigabytes per month.
Now do retention math. Keeping thirty daily, twelve weekly, and twelve monthly snapshots does not multiply the repository size, because unchanged data is shared across snapshots. What grows is metadata, roughly a few hundred megabytes per thousand snapshots. A 100 GB plan with a 300 GB source is comfortable; a 40 GB plan is not.
Leave room for the prune
The prune step temporarily needs free space proportional to the data it must repack. A disk at 95 percent capacity will fail a prune and then refuse new snapshots. Keep at least fifteen percent headroom, and check free space on a schedule rather than discovering it during a restore.
The SSH-only user that cannot get a shell
Create a dedicated account, generate a key pair on the client, and install only the public key. Then restrict what that key can do. The simplest safe pattern is a command= restriction in authorized_keys that forces an sftp session, plus a home directory that contains nothing but the repository.
Better still, run a restic-aware server so the client can only speak the repository protocol. A small container running rest-server or rclone serve restic in append-only mode means a compromised laptop cannot delete your history. That property matters more than any firewall rule, because ransomware deletes backups first.
Repository layout and retention policy
One repository per source machine, not one giant repository for everything. Separate repositories keep the blast radius small, let you set different passwords, and make a single corrupted index a partial problem rather than a total one. Name them by machine and year, for example laptop-2026 and nas-2026.
Write the retention flags once and put them in the backup script, not in your memory. A workable starting point: --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 1. Run forget and prune weekly, in a low-traffic window, and log the output so you can see whether the repository is growing faster than expected.
Testing a restore before you trust the vault
An untested backup is a hypothesis. Once a month, restore three files you can recognise: a photo from last summer, a document you edited recently, and one randomly chosen file from the oldest snapshot you keep. Compare contents, not just names.
Do one full restore to spare disk in the first month. It is slow, it exercises every part of the chain, and it will surface problems with permissions, ownership, or a missing password before those problems matter. Record how long it took, because that number defines your real recovery time, not the marketing figure on the provider’s page.
A backup you have restored once is worth more than three you have only watched complete.
Bandwidth, cost, and the monthly transfer question
Most budget plans include a monthly traffic allowance measured in terabytes, and backup traffic is asymmetric: uploads dominate, downloads are rare until you need them. A first full backup of 300 GB is a one-off hit, so schedule it late at night and check whether the provider throttles sustained uploads.
Watch the port speed rather than the allowance. A 100 Mbit link moves roughly 45 GB per hour at best, so a 300 GB first snapshot takes most of a day regardless of how much traffic is included. Incremental snapshots afterward are measured in minutes, which is the actual experience you are buying.
What happens when the provider reboots or suspends you
Small providers reboot for kernel updates, migrate hosts, and occasionally suspend an account for a billing card that expired. None of these should end your backup history. Make sure the repository lives on a normal disk path that survives a rebuild, and keep the repository password in a password manager you can reach from a phone.
Keep a second copy of the most critical ten gigabytes somewhere entirely different, because a single offsite target is still a single point of failure. The VPS handles volume; a cheap object-storage bucket or an external drive at a relative’s house handles the irreducible core.
Once that works, write the recovery runbook. Print or save one page with the repository URL, the environment variable name for the password, the exact restore command, and the three files you test every month. Include the one line that lists snapshots, because “which snapshot do I want” is the question that stalls a recovery at eleven at night.
Anyone who can read that page should be able to recover data without you. Run through it once with a person who has never touched restic, and fix whatever they had to guess.
Deciding how many copies is enough for your data
Three copies, two formats, one offsite is still a sensible default, and a budget VPS can be the offsite one. It is not glamorous work — no dashboard to admire, no service to share with friends — but it is the job that turns a bad week into an inconvenience. Affordable VPS hosting with enough disk for your retention window is the whole requirement.


