Backing up a server you could lose overnight

Backup advice is written for a world where the disk dies and the provider survives. Offshore inverts that. Hardware is rarely the thing that takes you off the internet — losing the entire machine in a single move is, along with everything the provider was holding on your behalf.

The failure you are planning for

On an ordinary host the realistic disaster is mechanical: a drive fails, a filesystem corrupts, somebody pastes the wrong command into the wrong window. Those still happen offshore. They are simply no longer the events most likely to end you.

The offshore list is shorter and faster. A court order with jurisdiction over the facility. A region that goes dark for reasons that have nothing to do with you. A renewal that lapses while you are travelling. Or the ending described in our note on bulletproof hosting, where a provider stops answering on a Tuesday and is never heard from again. Each of those removes the machine and the account at the same instant.

Why a snapshot is not a backup

Snapshots are the feature everyone reaches for, ourselves included, because they cost one click and restore in minutes. They are excellent against the mistake you made ten minutes ago. They are worth nothing against the list above, because a snapshot sits with the same company, in the same jurisdiction, behind the same login, and it goes when the account goes.

Where the second copy belongs

The old three-two-one rule still holds, but the word offsite has to be read strictly. Offsite is not another region from the same provider, another brand owned by the same group, or another rack in the same building. It means a different operator, in a different country, reached with credentials that are not stored on the machine being backed up.

Legal distance counts here for the reason it counts when choosing a region. A backup sitting one order away from the origin has not really moved.

The shape that works

1. 01Encrypt before it leavesCompress and encrypt on the source, then ship ciphertext. The destination should never hold anything readable, so that using it never requires trusting whoever runs it.
2. 02Pull, never pushLet the backup host reach in and fetch on a read-only key. A server that gets rooted can then destroy its own data, but not the history of it.
3. 03Keep the keys off both endsA passphrase stored on either machine protects nobody. Recovery material belongs somewhere that survives losing both, and that you can still reach without either.
4. 04Keep versions, not one copyRetain enough history to undo something you only noticed a week later. A bad deploy and a ransom note both look like a perfectly successful backup for days.
5. 05Restore on purposeOnce a quarter, rebuild the service from the archive onto a fresh machine and time it. A backup that has never been restored is a hypothesis, not a plan.

Copy the data, not the machine

The instinct is to image the whole disk. It is usually the wrong unit: a full image is large, slow, tied to one kernel and one partition layout, and mostly made of packages that reinstall in four minutes. Copy the parts nobody can regenerate.

• Database dumps taken through the engine, not a file copy of a data directory that was being written to at the time.
• Uploads, media, and anything else produced by people rather than by a build step.
• Configuration, held in a repository rather than in your memory of what got edited at two in the morning.
• Secrets, kept apart from all of the above and never inside the same archive as the data they unlock.
• The things that are not files at all: DNS records, the registrar login, and any address somebody else has allowlisted for you.

Restoring while the clock runs

A restore during an incident is nothing like a rehearsal. If the origin is gone you are rebuilding somewhere new under time pressure, which is the situation set out in moving a site after a suspension. The gap between two hours and two days is almost never the size of the data. It is whether the person doing the work has done it before.

So write the restore down as a runbook, in the order it has to happen, and store that document anywhere other than the server it describes. Two paragraphs and a list of commands is enough. It only has to be legible to a tired version of yourself at four in the morning.

We keep snapshots for our own customers and we restore them without complaint. We also think you should hold a copy we cannot reach, in a country we do not operate in, and we would rather say that plainly than have you discover the distinction during an incident.

Published by NoDMCAVPS, an offshore host that files automated DMCA notices instead of forwarding them. What we still remove is listed in the acceptable use policy.