How to back up a VPS to encrypted offshore storage

Almost nobody sets up backups on the day they deploy a server. It happens afterwards — after a disk fills during an upgrade, after a delete in the wrong directory, after a migration leaves a database that starts cleanly and answers wrong, after somebody gets in. The gap between running a machine that matters and holding a copy that outlives it is the most dangerous window in self-hosting, and most people live in it for months without noticing, because nothing goes wrong for a long time and then everything does at once. Closing it is not hard and it is not expensive. What makes it feel hard is that the word "backup" gets used for four different things, only one of which will still be there on the bad day.

The four things that are not backups

Every one of these is genuinely useful and worth having. None of them is a backup, and believing otherwise is the single most common reason people lose data they thought was safe. The distinction is not pedantic — each of these fails in exactly the situation you most need a backup for.

• RAID is uptime, not a backup. An array survives a dead disk without going offline, which is why our storage servers run RAID-6 and tolerate two failures at once. It does not survive a deleted directory, a bad upgrade, an encrypted-by-somebody-else file tree or a dropped table — every one of those is written faithfully to all the disks at the same instant.
• Snapshots are undo, not a backup. They live on the same storage as the data, they are usually visible to root on the same machine, and anything that destroys the volume or the host takes the snapshots with it. Fast to roll back, useless when the box is gone.
• Sync is replication, not a backup. A sync tool exists to make the far side match the near side, so a deletion or a corruption is propagated to the copy as fast as the network allows. Nextcloud, Dropbox and rclone sync all behave this way by design.
• Version history and trash bins are convenience, not a backup. They are features of the application, held in the application database, with a retention window measured in days. When the application is what broke, its own history goes with it.
• A copy on the same server is not offsite. If the failure is the machine, the provider account, the hypervisor or a seizure, every file on that machine is in the same failure domain, regardless of which directory it sits in.

A backup is a copy that is separate in space, separate in time and separate in control. Separate in space so a fire or a seizure does not take both. Separate in time so you can go back to before the damage rather than to a faithful copy of it. Separate in control so credentials stolen from the live machine cannot reach it. Anything missing one of those three is a convenience feature wearing a backup costume.

The 3-2-1 rule, and the version that survives 2026

The old rule is three copies of the data, on two different kinds of storage, with one of them offsite. It has aged well because it is really a rule about uncorrelated failure rather than about tapes. Two additions have earned their place since, and both exist because of things that did not commonly happen when the rule was written.

• Three copies. The live data, plus two more. Two copies means one failure away from a single point of failure, and single points of failure have a way of failing while you are still meaning to fix the first one.
• Two kinds of storage. Different hardware, different software, ideally a different provider. Two volumes on the same host share a hypervisor, a control panel and an account — which means they share the ways an account is lost.
• One offsite. Physically elsewhere, on infrastructure that does not go down when yours does. This is the copy that matters for fire, theft, seizure and an account closed without warning.
• One immutable or offline. Ransomware and a compromised root both look for backups first, and a destination your server can write to is a destination your server can erase. Append-only credentials or a pull-based design turns that from a catastrophe into an inconvenience.
• Zero unverified restores. A backup you have never restored is a hypothesis. This is the addition people skip most and regret hardest, because a backup job that has reported success for two years can have been writing unusable archives for two years.

What to back up: state, not the whole machine

The instinct is to image the entire server. It is usually the wrong shape: image backups are large, slow, awkward to restore selectively, and most of what they contain is a stock operating system you can reinstall in a minute. What you cannot regenerate is the state — the things that exist only because of what you did.

• Databases, dumped rather than copied. A live database file copied while the engine is writing is a torn file that may restore, may restore wrong, and will not tell you which. Use the engine's own dump tool, or stop the service, or take a filesystem snapshot and dump from that.
• Application data directories. Uploaded files, media, generated assets — the file tree that a database points at. It must be captured at the same point in time as its database, or you restore an index describing files that are not there.
• Configuration and the things you edited by hand. Web server and reverse-proxy configuration, systemd units, cron entries, firewall rules, the twenty small fixes you made at two in the morning and will not remember.
• Secrets and keys, handled separately and more carefully. TLS certificates and their private keys, SSH host keys, API tokens, and above all wallet files and seeds. These deserve their own encrypted copy that is not only on a rented machine.
• Container definitions and volumes. The compose files and environment files, plus the named volumes — which are the part people forget, because the containers themselves are trivially recreated and their volumes are not.
• The list of what is installed, not the installation itself. A short inventory of packages, versions and what runs where restores faster and smaller than an image of the whole root filesystem.

The dividing line is simple: if you can regenerate it from a script or a package manager in ten minutes, do not back it up — write down how. If it exists only because of something you or a user did, it needs a copy. That principle scales from a small site through a BTCPay instance, where the wallet and the database are everything and the rest is reinstallable, to a Nextcloud server, where the file tree and its database have to be captured together or neither is worth much.

Sizing the destination, and what it actually costs

People overestimate this badly, usually by pricing the first full copy and then multiplying by however many days they intend to keep. A modern backup tool does not work that way. It splits data into chunks, stores each unique chunk once, and compresses what compresses — so the second snapshot of a mostly-unchanged server costs almost nothing, and thirty daily snapshots are nowhere near thirty times the first.

• Budget roughly the size of your live state, plus thirty to fifty percent for history, for a typical retention policy on a server that changes at a normal pace.
• Retention drives growth far more than frequency does. Hourly snapshots kept for two days are cheaper than daily snapshots kept for three years. Decide how far back you would ever actually go, then prune to it automatically.
• Already-compressed data does not compress again. Video, photos, archives and encrypted blobs land at close to their original size, so a media-heavy server needs real capacity rather than clever settings.
• Databases dedupe poorly between dumps, because a compressed dump of a slightly different database is a completely different byte stream. Dump uncompressed and let the backup tool handle compression, and your storage cost drops sharply.
• The first upload is the only slow part. After that a nightly run moves the delta, which on most servers is megabytes. Transfer here is unmetered, so the first pass is a question of patience rather than of budget.

In practice this is the cheapest insurance in your stack. A storage server starts at $7.99/mo for 1 TB on RAID-6, which is far more than the state of a handful of VPS instances will occupy, and STO-2 at $12.99/mo doubles it. Media libraries and long retention are where capacity genuinely matters: STO-4 at $22.99/mo gives you 4 TB, STO-8 at $39.99/mo gives you 8 TB. The destination speaks rsync, SFTP and an S3-compatible API, so every mainstream backup tool talks to it without a plugin, and volumes are AES-256 encrypted at rest with bring-your-own keys supported — though as the next section argues, you should be encrypting before the data leaves the source anyway.

Choosing a tool, and what each one is actually for

There is no need to agonise here. Three tools cover essentially every case, they are all free, and the difference between them matters less than the difference between having one and not. Pick by the shape of your problem rather than by benchmark.

• restic — the default recommendation for most servers. Client-side encrypted, deduplicating, single static binary with no daemon, and it writes natively to SFTP, S3-compatible endpoints and plain directories. Its append-only mode is the easiest route to a destination a compromised server cannot wipe.
• BorgBackup — excellent deduplication and compression, very efficient over slow links, mature and well-proven. It wants its own agent available at the destination for remote repositories, which is a small constraint in exchange for being noticeably lighter on storage.
• rclone — the right tool when the job is really moving data between object stores, or when you want a mirror rather than a versioned history. Pair it with its crypt layer if you use it directly, and remember that a plain sync propagates deletions.
• Native dump tools, always, for databases. mysqldump, pg_dump and their equivalents produce a consistent logical copy that the engine can definitely read back. Dump to a file, then let restic or Borg pick that file up — do not try to replace the dump with a clever file-level copy.
• Provider snapshots as a fast local layer only. Take them for quick rollbacks around risky upgrades, and never count them as one of your three copies.

Step by step: a working encrypted backup in one sitting

1. 01Deploy the destination and lock it downA storage server in a different region from the servers it protects. Keys-only SSH, its own user, and no reuse of credentials from the machines that will write to it.
2. 02Decide the state list before touching a toolWrite down every path and every database that has to survive. Ten minutes with a text file now prevents the restore where you discover the one directory nobody listed.
3. 03Initialise an encrypted repositoryGenerate a strong repository password, initialise the repo over SFTP or S3, and store that password somewhere that is not the server being backed up. A repository whose key exists only on the dead machine is not recoverable.
4. 04Dump databases first, then archiveA wrapper script that dumps each database to a staging directory and then runs one backup pass over both the dumps and the file tree. That ordering is what makes the database and its files consistent with each other.
5. 05Run the first backup and watch it finishThe initial pass is the long one. Run it in a terminal multiplexer so a dropped connection does not kill it, and note how long it took — you now know your restore window too.
6. 06Set retention and prune automaticallySomething like seven daily, four weekly and six monthly snapshots suits most servers. Configure pruning in the same job, or the repository grows until the day it stops working.
7. 07Schedule it, then make failure loudA nightly timer or cron entry, plus an alert when the job does not report success. A silent backup job is indistinguishable from no backup job for however many months it takes to notice.
8. 08Restore something today, from the backup, on a different machineNot a listing of the archive — an actual restore of one real file and one real database onto a scratch server. Until you have done this once, you have a backup script, not a backup.

Making the copy survive the thing that killed the server

This is the part that separates a backup from an inconvenience for an attacker. If the server holds credentials that can delete the backups, then a compromised root, a ransomware run or a bad script reaches both copies in the same minute. The fix is structural, not a matter of stronger passwords.

• Use append-only credentials from the source. restic and Borg both support a mode where the writing machine can create new snapshots but cannot delete or prune existing ones. Pruning then runs from somewhere else, on a schedule, with a separate key.
• Prefer a pull design where you can. A destination that reaches into the source and fetches, rather than a source that pushes, means the source never holds credentials to the archive at all.
• Never reuse SSH keys or repository passwords across servers. One compromised machine should cost you one machine's backups, not the whole estate.
• Keep at least one copy in a different jurisdiction and a different failure domain. Region diversity is not paranoia — it is the difference between a hardware incident and a total loss.
• Store the repository key outside the infrastructure entirely. A password manager, a hardware token, paper in a safe. Anywhere except the machines the repository protects.
• Watch for backups that start succeeding suspiciously fast. A job that used to take twenty minutes and now takes forty seconds is usually backing up an empty or unmounted directory, and it will keep reporting success while doing it.

Region choice is a real decision here rather than a detail, because your backup and your production server should not be able to be seized in the same action. If that matters for what you run, picking the location deliberately is worth a few minutes, and putting the destination in a different legal regime from the source is the point of the exercise.

Restoring: the part nobody rehearses

Restores fail for boring reasons, and they fail at the worst possible moment because that is the only time most people attempt one. Every failure below is discovered in minutes during a drill and in hours during an outage.

• The repository password was only on the server that died, so the archives are intact and permanently unreadable.
• The database restored but the file tree came from a run three hours later, so the application shows records whose files do not exist.
• The backup captured a directory that had silently stopped being mounted, so it faithfully archived an empty folder every night for a year.
• Nobody knew the restore order — database first or files first, service stopped or running — and the half-restored state had to be thrown away and started again.
• The restore takes eleven hours over the link available, which nobody had measured, and the recovery plan assumed one.
• File ownership and permissions came back wrong, so everything is present and the application refuses to start.
• Only the newest snapshot was ever tested, and the corruption being recovered from started six weeks ago.

A drill twice a year fixes all of it. Deploy a throwaway VPS, restore into it from the real repository, start the service, look at the data, destroy the machine. It costs a couple of dollars and an hour, and it converts the entire backup system from a belief into a fact. Do it once with the runbook open and fix the runbook wherever it lied to you.

The privacy layer: a backup can undo your anonymity

This one is specific to running offshore, and it is easy to get right only if you think about it before the first upload rather than after. A backup is a complete, indexed, long-lived copy of your infrastructure sitting somewhere else, which makes it exactly as sensitive as the original and considerably easier to forget about.

• Filenames and directory structure are metadata even when contents are encrypted. Client-side encryption in restic and Borg covers the names too; a plain rsync mirror does not, and a directory listing is often enough to identify what a server is and who runs it.
• The destination account is part of the story. A backup vault rented with a card in your legal name attaches that name to everything the vault holds, no matter how carefully the source machine was kept clean.
• Backup traffic is a persistent, scheduled, high-volume link between two addresses. It is one of the more legible patterns a server produces, and it points at the destination every single night.
• Old snapshots outlive the decisions that made them. Something you stopped storing a year ago is still in the archive if retention never pruned it, which is a good property for recovery and a bad one for exposure.
• Logs and shell history get swept up with everything else. The archive frequently contains the IP addresses, commands and credentials you were careful about on the live machine.

The fixes are ordinary. Use a tool that encrypts names as well as contents. Rent the destination the same way you rented the source — from a host that never asked who you are, funded from a crypto balance, with a Monero top-up if you want the payment trail closed as well. Route the transfer over a WireGuard tunnel if the pattern itself bothers you. And apply the same first-ten-minutes hardening to the storage box that you applied to production, because a machine holding a copy of everything is not a lower-value target than the original — it is frequently a higher one.

Mistakes that cost people their data

• Trusting RAID, snapshots or a sync folder as the backup, and finding out which category they were in on the day it mattered.
• Keeping the only copy on the same server, the same account or the same provider as the thing being protected.
• Copying a live database file instead of dumping it, and restoring an archive that is subtly, silently wrong.
• Backing up the file tree and the database at different times, so neither matches the other on restore.
• Storing the repository password on the machine the repository is protecting.
• Giving the source full delete rights on the destination, so one compromise takes the archives with it.
• Never pruning, until the destination fills and the nightly job has been failing quietly for weeks.
• Backing up hundreds of gigabytes of public blockchain data while the wallet file sits in none of the archives.
• Configuring alerts on failure but never on absence, so a job that stopped running entirely reports nothing at all.
• Testing the newest snapshot only, and discovering during a real incident that the corruption predates it.

Backups are the least interesting thing you will configure and the only one whose absence is unrecoverable. Everything else on a server can be rebuilt from a package manager and an afternoon; the state cannot. Spend one sitting on it: list what has to survive, dump the databases, send an encrypted archive to a storage server in another country, prune on a schedule, alert on silence, and restore something real before you close the terminal. Then leave it alone. The measure of a good backup system is that you forget it exists until the one morning it turns a catastrophe into a slightly annoying hour.