VPS Backups That Actually Restore

A backup strategy is never tested on the night the server dies. It is tested weeks earlier, in three quiet decisions nobody writes down: where the copy goes, who is allowed to delete it, and whether anyone has ever actually read one back.

Hosting that never asked for your identity gives something up in exchange, and this is the honest place to say it. There is no account manager to call, no ticket that resurrects a wiped volume, and our own retention policy is blunt about the reason: server data is destroyed within 24 hours of termination, disks are cryptographically wiped rather than formatted, and no backups are retained. That is the same property that makes the platform worth buying, seen from the other side. Anything you would want back after a bad night has to already be somewhere else, and you are the one who puts it there.

What actually destroys servers

Almost nobody loses a server the way they imagine. Catastrophic hardware failure is real but rare, and it is the one case a competent host already engineers against. The losses that actually happen are duller, and each one defeats a different kind of copy — which is why "I have a backup" is not an answer until you say which of these it survives.

Read that table as a checklist rather than a list of fears. A nightly copy to a second disk in the same machine answers row one and nothing else. A snapshot in the same panel answers rows one and two. Only a copy held somewhere the server cannot reach, under a key you still have, answers all five.

A snapshot is not a backup, and your host is not one either

Snapshots are excellent at what they do: they roll back an upgrade that went wrong, in seconds, with no transfer. What they cannot do is survive the thing that took the server, because they share every failure domain with it — the same provider, the same account, the same billing token, the same country, often the same storage cluster. A snapshot protects you against yourself. A backup protects you against everything else.

The distinction matters more here than at a mainstream host, because the usual safety nets were removed on purpose. Nobody logs into customer servers, so nobody notices that your backup job has been failing since March. There is no identity attached to the account, so there is no human path to "prove who you are and we will restore it". And termination is genuinely terminal: an expired balance is a data-loss event, not a billing event.

3-2-1, rewritten for people who never showed ID

The classic rule says three copies, on two kinds of media, one of them off-site. It was written for an era of tape and spinning disk, and the media clause has quietly stopped meaning anything: your production disk is NVMe, your backup target's disk is NVMe, and calling that "two media" is a story you tell yourself. The clause worth keeping is the one about distance, and for offshore infrastructure distance is not measured in kilometres.

Rewrite it as three copies, two providers, two jurisdictions. The failures that take out both copies at once are almost never physical — they are an account you lost access to, a provider that had a bad week, or a legal instrument that lands in one country and has no reach in another. Two servers in the same rack are one copy with extra steps; two servers under the same legal regime are barely better. Our jurisdiction guide covers how to pick a second one that does not simply mirror the first's exposure.

In practice this is cheap. A backup target does not need cores, and it barely needs a network — it needs disk and an address. The smallest VPS tier in a different one of our seven locations is a competent restic or Borg endpoint, and for archives measured in terabytes a dedicated box with real drives costs less per terabyte than any object store. Where the data is genuinely large and rarely read, the economics favour bare metal by a wide margin.

One thing people get right on production and wrong on the backup target: pay for it the same way. A second server bought with a card in your own name quietly re-attaches the identity you spent effort removing from the first, and it now holds a complete copy of everything on it. If the production box is paid for in Monero, the backup box deserves the same treatment.

The third copy is the one most people skip, and it is the only one immune to every remote failure at once: a disk you physically hold, updated occasionally, kept offline. Once a month is enough for most people. It costs a coffee's worth of attention and it is the copy that survives scenarios the other two share.

Push, pull, and the mistake that lets one bad night eat both copies

Here is the arrangement almost everyone builds first. A job on the production server runs nightly, holds a key or a token for the backup target, connects, and pushes. It works, it is simple, and it has a property that only becomes visible on the worst day of the server's life: whoever controls the production box also controls the backups.

That is not a hypothetical. Deleting or encrypting the victim's backups before announcing themselves is standard practice for anyone doing this commercially — the credentials are sitting in a cron job or an environment file, and finding them takes about a minute. A copy your attacker can delete is not a second copy. It is a mirror of the first one with a delay.

There are two clean fixes, and they compose well with the basic hardening you should already have done.

• Append-only targets. Both major tools support a mode where a client can add data and cannot remove it. Borg does it by pinning the SSH key on the target to borg serve --append-only; restic does it with a REST server started with --append-only. The production server writes every night and is structurally incapable of destroying history. Pruning old snapshots then happens on the target, in a session the production box cannot start.
• Pull instead of push. Invert the direction: the backup host connects to production, reads, and stores. Production holds no credentials for the target at all, so there is nothing to steal. Restrict the key it uses on the production side with restrict and a forced command= so a stolen backup key cannot become a shell.

Pull is the stronger model and slightly more work to run; append-only is nearly free if you are already using Borg or restic. Either one turns "the attacker deleted my backups" from an outcome into an attempt. If you take one thing from this guide, take this section.

Encrypt at the source, then decide who holds the key

Both serious tools encrypt on the machine being backed up, before anything crosses the network. The target stores blobs it cannot interpret — which is precisely what makes the cross-provider copy safe. Your second host does not need to be trustworthy, or even friendly; it needs to be reachable and to have disk. That single property is what turns "a server in a country I know nothing about" from a risk into infrastructure.

This is a different mechanism from encrypting the server's own disk, and the two answer different questions — our guide on full-disk encryption on a VPS works through what disk encryption does and does not protect while the machine is running. Backup encryption is the easier and more valuable of the two, because the threat model is honest: the data is at rest, on hardware you do not control, and the key never goes there.

Which moves the entire risk onto key custody. The passphrase is now a single point of total loss, and it is a worse single point than people expect, because losing it is silent — nothing breaks, backups keep running, and you find out at the exact moment you needed them. Three habits fix it:

• Keep the passphrase on the server only as a file readable by root alone, referenced with --password-file, so it never appears in a process list or a shell history.
• Keep a human-readable copy off every machine involved. Paper in a drawer genuinely beats a password manager that syncs to an account you may also lose access to.
• Add a second key to the repository — restic key add, or an exported Borg key — so that one forgotten passphrase is an inconvenience rather than the end of the archive.

The rule underneath all three: if the only copy of the key lives on the machine the backup exists to replace, you do not have a backup. You have an encrypted pile of blocks and a story about them.

Choosing a tool, in one table

Tool choice matters less than the direction of the connection and the state of your key, which is why it comes sixth rather than first. That said, the differences are real, and picking the wrong shape for the job creates work later.

For a single server, restic to a second VPS is the shortest path to something correct. For a seedbox, a media archive or anything with many similar large files, Borg's deduplication is the difference between a full disk and a comfortable one — the seedbox guide covers the storage side of that workload in more detail.

Anything that is running is not a file

The most common corrupt backup in the world is a straight file copy of a live database. It completes without an error, it weighs the right amount, and it restores into a table the engine refuses to open. The database was mid-write when the copy passed; what you saved is a photograph of a page being turned.

Three ways out, in increasing order of effort. Dump it: mysqldump --single-transaction gives a consistent InnoDB dump without locking writers, and pg_dump does the same for PostgreSQL. Snapshot it: freeze the filesystem or take an LVM or ZFS snapshot, copy from the snapshot, release it — this is how you handle data sets too large to dump nightly. Or stop it: for a small service, two minutes of downtime at 04:00 is a perfectly respectable consistency strategy, and it is the only one with no edge cases.

The same logic reaches past databases. A container's writable layer is disposable, but its volumes are not, and neither is the docker compose file and environment beside them — a backup that restores the data but not the definition leaves you reconstructing the stack from memory. Message queues, Redis with persistence enabled, and a mail spool being written by an MTA all deserve the same treatment: quiesce, snapshot, or dump, but never straight-copy and hope.

What to back up, and the parts everyone forgets

Most people back up the obvious payload — the database and the application directory — and rebuild the rest by hand under pressure. The rebuild is where the hours go. A backup that returns you to a working system, rather than to a pile of correct data, includes the boring layer:

• /etc in full, plus the systemd units and timers you wrote, and any crontabs that live outside it.
• TLS certificates and their private keys, or at minimum the ACME account key, so certificates renew rather than restart from zero.
• Firewall rules and the package list, which together reconstruct the machine's shape faster than any memory of it.
• Application secrets and environment files — the ones deliberately excluded from your code repository, and therefore present nowhere else.
• DNS records exported as text, including reverse-DNS and PTR entries, which live at the provider and not on the server.

A restore you have not tested is a rumour

Backup software reports on itself, and it reports honestly about the wrong thing. "Snapshot completed" means data was written to a repository. It says nothing about whether the repository can be read on a machine that is not this one, by a person who does not remember what they configured eleven months ago.

Start with the cheap integrity checks — restic check --read-data-subset=5% or borg check --verify-data on a schedule — and understand that they verify the archive, not your ability to use it. The real drill is different and takes an afternoon, once. Order a fresh server by the hour in a location you do not otherwise use. Restore onto it with nothing but the repository address, the passphrase, and your own notes. Bring the service up. Time the whole thing. Then destroy the machine. Total cost: a few dollars, and it is the only exercise that produces a number you can trust.

What it reliably exposes is never the data. It is the missing package nobody wrote down, the config that lived outside the backed-up paths, the passphrase that only ever existed in the shell history of the server you are trying to replace, and the tool version that reads your repository format. Every one of those is trivial to fix in advance and miserable to discover during an outage.

Write down the two numbers the drill gives you: how long a restore took, and how much work the schedule can lose. Those are the backup policy. Everything above is implementation detail in service of them.

Automating it so it keeps happening

Run the job from a systemd timer rather than cron. You get logs in one place, a real record of the last run, and a schedule that survives reboots — none of which cron gives you without extra work. Keep the passphrase out of the unit file itself, which anyone with shell access can read straight out of systemctl cat.

Then solve the failure mode that actually gets people, which is not an error but silence. A backup that stopped running six weeks ago looks exactly like one that ran perfectly, because both produce no output. Alert on absence, not on failure. Have the job ping a monitor on success and let the monitor complain when the ping does not arrive — and put that monitor anywhere except the server it watches, since a box that is down cannot report that it is down.

Set retention deliberately rather than by default. Something like --keep-daily 7 --keep-weekly 4 --keep-monthly 6 covers the mistakes you notice tonight and the corruption you notice in spring, without growing forever. Run the pruning on the target side if you have gone append-only, which is the point of having gone append-only. Transfer volume is rarely the constraint on our network — bandwidth is unmetered on every plan — so schedule for consistency rather than for a quota, and check the timing against your own quiet hours. The wider habits around all of this are covered in the server OpSec guide.

The short version

If you do nothing else with this page, do these six things, roughly in this order:

• Put one copy at a second provider, in a second jurisdiction, paid for the same private way as the first.
• Make that copy append-only, or pull it from the target, so a compromised server cannot destroy it.
• Let the tool encrypt at the source, and keep the key off both machines involved.
• Dump databases and stop or snapshot anything that is running; never straight-copy live state.
• Back up the identity keys separately — onion, WireGuard, DKIM, node seeds — because those cannot be regenerated.
• Restore onto a throwaway server once, time it, and write down what was missing.

None of this is exotic, and none of it takes a weekend. It is an afternoon of setup and one drill, against a category of loss that ends projects. On a platform that deliberately keeps nothing about you, the copy you made yourself is the only one that exists — which is the cost of the arrangement, and a fair one. Spin up a second server in a jurisdiction that is not your first, and give tonight's backup somewhere to land.