Encrypted off-site backups for a VPS

People do the hard part and then leave the easy part undone. A server gets a hardening pass, keys instead of passwords, a default-deny firewall, maybe full-disk encryption so the disk is meaningless when the machine is off. Then every night a complete, plaintext copy of everything on that disk is pushed to a storage account opened years ago with a card, in a country nobody thought about, protected by a password that is also in the browser.

The copy deserves the same attention as the original, because it is the original, minus the uptime. It is worth being specific about what you are defending against, because the answers are different and only one of them is the one people picture:

• The machine dies. Hardware, hypervisor, a filesystem that comes back read-only. Rare, undramatic, and the case every backup handles.
• You break it yourself. A migration that half-ran, a rm with an ambitious glob, a configuration change that was fine until the reboot. Far and away the most common reason anyone restores anything.
• Someone else gets root. The case that decides your design. An attacker who wants leverage deletes the backups first and encrypts the server second; if your server holds a credential that can erase the repository, you have built a system that helps them.
• The account goes away. A payment that did not clear, a dispute, a suspension. If the original and the copy are behind the same login, they have the same single point of failure and it is not technical.
• Someone with authority arrives. Hardware can be taken or an account frozen by process rather than by attack. A copy in another jurisdiction is the only thing that helps, and only if you can still reach it.

Notice how many of those are untouched by a snapshot taken by your own provider, on your own account, in the same datacentre.

The rule comes from photography rather than from systems administration — Peter Krogh wrote it down for people with irreplaceable negatives — and it survived because it is short: three copies of the data, on two different systems, one of them off-site. Each digit is defending against a different item on the list above, which is what makes it more than a slogan.

The three copies answer ordinary loss: the live data, plus two backups, so that discovering a bad backup is an annoyance rather than the end. Two different systems answers correlated failure — two copies on the same host, the same array or the same account are one copy wearing a disguise. And the off-site copy answers everything that happens to a place rather than to a disk: fire, seizure, suspension, a provider that stops answering email.

The modern extension is 3-2-1-1-0, and the two extra digits are the ones that matter in 2026. The extra 1 is a copy that is immutable or offline — something an attacker with your credentials cannot delete, which is exactly what append-only mode gives you. The 0 is zero errors on verification: a backup you have checked, not merely one you have made.

For a single small VPS this reads more modestly than it sounds. The live server is copy one. A repository on a second machine in another country is copy two, off-site, on a different system, and append-only so it is also the immutable one. A monthly full restore into a scratch server is the zero. That is the whole rule, satisfied for the price of a second small server, and the rest of this guide is the mechanics of it.

Both tools do the same four things, and both do them well: they chunk your data by content so that a moved or renamed file is not re-uploaded, they deduplicate across every snapshot so a year of dailies costs far less than a year of copies, they compress, and — the part that matters here — they encrypt and authenticate on the client, before a single byte reaches the network. In both cases the storage holds ciphertext it cannot read and cannot alter undetected. That property is the reason this guide has no opinion about who runs your storage.

The real differences are about the far end.

• restic is a single static Go binary and asks nothing of the destination. It writes to SFTP, to S3-compatible object storage, to its own REST server, or to anything rclone can reach. Encryption is AES-256 with a Poly1305 authenticator; repository format 2 added compression. If your target is a bucket, or a box where you cannot install software, restic is the answer and there is not much to debate.
• Borg wants borg installed on both ends and talks to itself over SSH. In exchange it offers the thing restic needs a helper for: a genuine server-enforced append-only mode, pinned by the command= option in the remote account’s authorized_keys. A client — including a compromised one — can add archives and cannot remove them. For the threat model in the previous section, that is the single most valuable feature in either project.

So the decision is short. If you control the far end, use Borg with append-only. If you do not, use restic, and get the same property back either by running rest-server --append-only on the target or by using a bucket with object lock. Both paths are shown below.

One caveat before you commit to a repository: Borg’s command surface is not stable across its major lines — the repo::archive shorthand used below belongs to the 1.x series and changes in 2.x — so check borg --version against whichever documentation you are reading rather than the other way round. restic has been steadier here, at the cost of a repository format migration of its own.

One thing not to do is run both, on the theory that two backups are safer than one. Two half-maintained systems produce two repositories you have not verified and one restore procedure you cannot remember under pressure. Pick the one that fits your far end, and spend the effort you saved on testing it.

Everything above is standard advice. This is the part that is usually left out.

The ordinary way to back up a server is to give it a credential and let it push. That credential, almost always, can also delete — because pruning old snapshots requires deletion, and it was easier to grant one key that does everything. The consequence is that the attacker who owns your server owns your backups too, and the backup is worth precisely nothing in the one scenario you most wanted it for. There are exactly three ways out:

• Append-only at the target. The far end accepts new data and refuses removal, regardless of what the client asks. borg serve --append-only and rest-server --append-only both do this, enforced on the server, and deletion becomes something you perform deliberately from the backup host.
• Object lock. S3-compatible storage can hold objects immutable for a retention period. Effective, and it moves the trust to a provider and a billing relationship.
• Pull instead of push. The backup host connects in and reads. Nothing on the production server can touch the repository — but now the backup host holds a key into production, so you have inverted the trust rather than removed it. Reasonable when the backup host is genuinely more locked down; not obviously better otherwise.

The append-only option is the cheapest and the least conditional, so it is the one built below.

Then the question of where. A backup is a full copy of your server, and it sits under the law of the place you put it, on an account that belongs to somebody. Choosing a jurisdiction carefully for the server and then pushing nightly copies to a bucket somewhere else entirely is a common and quiet mistake — the jurisdiction of the copy is the jurisdiction of the data. Client-side encryption blunts this considerably: a demand served on your storage provider returns ciphertext. What it does not protect is availability, and it does not hide the fact that a repository exists, how large it is, or when it last changed.

Which is why the shape that solves the most problems at once is a second small server that you also own, in a different country from the first, rented the same way as the first: with an email address, no ID, and paid in Monero. Both ends are yours, both ends are cheap, the transfer never crosses a third party, and the copy is out of reach of whatever happens to the original’s jurisdiction or account.

Sizing it is easier than sizing a real server, because a backup target is disk with a CPU attached. What it does need is enough memory to run a prune and an integrity check without thrashing, which is the one operation that is genuinely hungry — so a gigabyte is thin and two is comfortable. From the plan grid:

• Cub — 1 vCPU / 2 GB / 40 GB NVMe, $5.00/mo. The default. A normal web or application server with 10–15 GB of live data and a year of daily retention fits here comfortably, because deduplication and compression are doing most of the work.
• Scout — 2 vCPU / 4 GB / 70 GB, $9.00/mo. Several servers into one repository, or a Nextcloud with photographs in it.
• Runner and Hunter — 100 GB at $14.00 and 140 GB at $19.00. Where a mail spool, a media library or several years of history end up.
• Pup — 1 vCPU / 1 GB / 25 GB, $3.50/mo. Fine for configuration and database dumps alone. Do not point a large file tree at it and expect maintenance to stay pleasant.

A working rule for the disk: budget two to three times the size of a single full backup, and you will have a year of history with room to be wrong. Put it somewhere that is not where the original is — Amsterdam, Paris, Bucharest and Sofia all sit at base price, Reykjavik multiplies by 1.20 and Zurich by 1.35, which makes a Cub in Switzerland $6.75 a month. The first upload is the only large transfer you will ever make, and traffic is unlimited at 1 Gbps, so seeding a repository does not produce an invoice at the end of the month.

Retention is where people quietly lose data they still had. Keeping seven daily snapshots feels responsible and defends only against problems you spot within a week. Silent corruption, a truncated database written by a bug, a file deleted in April and needed in June, an intruder who sat quietly before doing anything visible — all of these are discovered long after the seven days have rolled over, and by then every snapshot faithfully contains the damage.

The standard answer is a tiered policy, which costs almost nothing because deduplication means a monthly snapshot of slow-moving data is a rounding error:

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 2 --prune

borg prune --keep-daily=7 --keep-weekly=5 --keep-monthly=12 --keep-yearly=2 ::
borg compact

Two mechanical details are worth knowing, because both have surprised people. In restic, forget removes snapshots from the index but reclaims nothing; prune is the step that actually deletes data, which is why the flag is there. In Borg, prune removes archives but the repository does not shrink until borg compact runs — a separate command precisely so that it can be scheduled separately.

And there is a genuine tension with the previous section: pruning requires deletion, and you have just taken deletion away from the client. That is the correct trade rather than a design flaw. Resolve it by pruning from the backup host, where the repository is local and the client has no say — a weekly timer on the target, running while the production server is not involved at all. If that is more machinery than you want, the alternative is a second SSH key without --append-only, kept off the production server and used by hand every few months. What you should not do is put the unrestricted key back on the server to make a cron job simpler.

A backup job that stops running produces exactly the same output as a backup job with nothing to do: nothing. This is the defining operational property of backups and the reason most broken ones stay broken for months. Three things are worth wiring up, in increasing order of value:

• Alert on failure. A systemd unit can trigger another unit when it fails, with OnFailure=, and that unit can send you a message. Necessary, and the weakest of the three, because it only fires when something actually runs and reports an error.
• Alert on age. Ask the repository when it last received anything and complain if the answer is more than a day or two old. This catches the timer that was masked, the disk that filled, the host that stopped resolving — every failure that never produced an error because nothing ever ran.
• A dead man’s switch. Invert the logic: the job pings a URL on success and something external alerts you when the pings stop. This is the only one that survives the whole server going away, which is the failure you least want to learn about from a customer.

The check that pays for itself is the age one, and it is three lines:

#!/bin/sh
# alert if the newest snapshot is older than 36 hours
last=$(restic snapshots --json --latest 1 | grep -o '"time":"[^"]*"' | head -1 | cut -d'"' -f4)
[ $(( $(date +%s) - $(date -d "$last" +%s) )) -lt 129600 ] || echo "BACKUP STALE: $last"

Watch the disk on the target too. A full backup volume fails every job from then on, and it fails at the end — after the transfer, which is the most expensive way to discover it. An alert at eighty per cent gives you weeks of warning; the alternative gives you none.

Roughly in order of how often they turn a backup into a souvenir:

• The database was copied while it was running. An InnoDB data directory captured mid-write restores into a database that will not start, and it does so silently — the backup completes, the files are all there, the size looks right. Dump first. This is step three for a reason.
• The password was only on the server. A flawless encrypted repository whose passphrase lived in /root on the machine that burned down is high-quality noise. So is a passphrase in a password manager whose only copy syncs through that same server.
• Nobody ever restored. The exclude list was too aggressive, the database dump was empty for three months, the path was wrong. Every one of these is invisible until a restore, and obvious within ten minutes of one.
• The backups were on the same account. Same provider, same login, same billing relationship. It works for disk failure and for nothing else.
• The client could delete. Ransomware removes the backups before it touches the data, because that is the whole business model. Append-only, or accept that this scenario is not covered.
• The target quietly filled up. Retention never pruned, or a new large directory was added to the include list. Every job after that fails, and if you were not monitoring age, nothing tells you.
• The blockchain was in the backup. Backing up a Bitcoin or Monero data directory means paying to store a public ledger you can re-download for free. Back up the wallet and the configuration; exclude the chain.
• The exclude list ate something. A pattern meant for /var/cache that also matched an application’s cache directory containing state it never rebuilt. Read the file list of your first backup once, properly.
• The restore needed the key that was in the repository. Borg’s repokey mode keeps the key inside the repository, which is convenient until the repository is the thing you lost. borg key export to somewhere else, once, at the start.

Four honest limits, because a guide that oversells this is doing the same thing as an untested backup.

A backup is not high availability. It shortens an outage; it does not prevent one. Restoring a server means provisioning, pulling, extracting and reconfiguring — comfortably an hour for something small, and considerably more if the last time you tried was never. If an hour of downtime is unacceptable, the answer is a standby machine, and the backup remains necessary for everything the standby faithfully replicates, including your mistakes.

Encryption does not make the copy invisible. It makes it unreadable, which is not the same claim. Whoever hosts the repository can still see that it exists, how big it is, and when it last changed — and the account that pays for it is an identifying detail like any other. If the reason you rented the original with no ID still applies, it applies to the second machine as well; the same checkout covers both.

Encrypted at rest is not encrypted end to end in every sense. restic and Borg protect the repository. They do not protect the running server, where the data is plaintext by definition, and they do not help if the passphrase is compromised along with the machine that held it. Full-disk encryption on the source and a passphrase kept off both machines are complementary controls, not redundant ones.

And a copy in another country is friction, not immunity. Jurisdiction changes who has to ask whom, and how long it takes — a point the offshore hosting entry makes at length. Both machines here operate under the same plainly stated acceptable-use policy, with the same hard floor under it. What the arrangement genuinely buys is that no single failure — a dead disk, a bad command, an intruder, a frozen account — takes the original and the copy at the same time. That is what a backup is for, and it is enough.