VPS Backup and Restore — 3-2-1 on Root Servers

Three copies, two media, one tested restore: run 3-2-1 backups on a root server. Depot storage from $30 list, $24/TB annual-eff. Crypto only.

Published 2026-08-30 · Updated 2026-10-10 · FYRHost Editorial · 18 min read

Most of your disk is not worth backing up

The reflexive full-disk tar backs up the ninety percent you can rebuild and starves the ten percent you cannot, which is why the first backup decision is a line, not a tool. Draw it before you schedule anything: state is what cannot be regenerated — databases, uploaded files, TLS keys, the configs that took a week to get right — and everything else is rebuildable by definition, no matter how much it hurts to re-download.

Restore speed comes from automating the rebuild, not from imaging the disk. A short Ansible playbook or cloud-init seed that installs packages, drops configs, and starts services — kept in version control and actually updated — beats a golden image you forgot existed, because the script gets exercised on every rebuild while the image silently rots. Inventory what belongs where with dpkg --get-selections or the RPM equivalent, and commit /etc to a private repo so the line between state and rebuildable is visible in a diff.

The state set is smaller than the anxiety suggests. On a typical root server it fits in a few paths: /var/lib/postgresql or its engine-equivalent, the upload directory, /etc/letsencrypt, and whatever config files have diverged from package defaults. Everything else on the disk — the OS, the package set, the stock unit files — is reproducible from the internet plus your script, and paying to store it three times buys exactly nothing.

The typical mistake runs one of two ways: tar-the-root, which produces massive archives that restore slowly and still miss the live database's consistent state; or the opposite — excluding /etc to save space, then discovering that a week of tuning lived only there. Both come from skipping the line-drawing step, and both are invisible until the restore, which is the only moment the design gets graded.

Draw the line first and every later decision gets cheaper — the copy set shrinks, the schedules become sane, the restore test has something meaningful to compare — because a backup strategy aimed at the right ten percent will always outperform a bigger, more expensive strategy aimed at the whole disk, and the line itself, once written down, becomes the most valuable document in the whole operation.

3-2-1, translated to a root server

The textbook rule says three copies, two media, one off-site, and it translates cleanly: copy one is the live data; copy two is an on-box snapshot for second-level rollback; copy three is an off-box, encrypted repository on separate storage — a different account, provider, or cold medium. The one in 3-2-1 is not a copy at all: it is one tested restore, scheduled, because an untested backup is a rumor with a cron entry.

The snapshot leg answers the most common emergency — a bad deploy, a broken config push, a deleted table — in seconds, precisely because it lives on the same platform as the box. Take the snapshot add-on at checkout — $9.50 on VPS plans — for that fast-rollback layer, and let the off-box repository carry the real disasters, because a snapshot and its source share a provider, a cluster, and a fate, which disqualifies it from being a strategy on its own.

The off-box leg is where the pattern earns its keep, and it can stay inside the same rails: a Depot 1 box — 1 TB NVMe, $30.00 list, $24.00 on the annual term — serving as a Borg or Restic target keeps copies inside the same crypto-only, no-KYC checkout while still being a different machine on different hardware. The virtualisation guide explains why the platform under that target matters; the short version is that reserved memory and honest disks make backup targets predictable.

The failure that eats people is counting the second NVMe in the same chassis as copy two: same power feed, same kernel panic, same provider outage, same ransomware with root. Media diversity in 3-2-1 means a different failure domain, not a different partition — a snapshot plus a second disk in one box is still one copy wearing two names, and it will introduce itself as such during the first platform-level incident.

Translated this way, the old office rule survives contact with root servers intact — three copies with genuinely separate failure domains, two media that cannot die together, and one restore exercise on a calendar — and the translation itself is most of the engineering, because once the domains are honest, the tools are interchangeable and the schedules are arithmetic instead of philosophy.

Encrypt at the source, not at the target

If the backup target holds plaintext, the backup is also a liability — a second copy of production sitting on someone else's disk, one misconfiguration away from being the breach instead of the recovery. Borg and Restic both encrypt client-side by default, so the target stores opaque chunks, never holds a key, and a compromised repository is an annoyance rather than an incident report.

The mechanics are one command at init and then nothing: borg init --encryption=repokey ssh://depot.example/./repo embeds the key in the repository while keeping a copy in your keyring, and restic -r sftp:depot.example:/srv/repo init generates a repository password you must then guard. Chunks are deduplicated before encryption, which is why the second backup of a 40 GB set takes seconds and a few megabytes, and why per-TB pricing on the target stretches further than raw sizes suggest.

Operations stay boring on purpose: restic backup /srv on a schedule, borg create repo::{hostname}-{now} for the same job in Borg, retention applied with restic forget or borg prune so the repository holds a ladder rather than an avalanche. The Restic documentation and the BorgBackup documentation both cover the scheduler integration; systemd.timer units beat cron for jobs whose success you want logged.

The failure modes cluster around the key, not the cipher: a repository password stored in the same encrypted volume as the repository's SSH key, a passphrase held only in the head of whoever wrote the script, or environment variables with credentials sitting world-readable in /etc — fix that one with chmod 600 and a proper secrets file. Lose the key and the backup turns into entropy; that outcome deserves a section of its own.

Source-side encryption is the difference between a backup system and a second production system you did not mean to run — it lets the off-box copy live anywhere, including on a provider you barely trust, because trust in the target stops being required the moment the target can only store ciphertext, and that single design choice buys more security than any amount of target-side hardening ever will.

Sizing the target: the Depot math

Per-TB price falls as tiers grow, so the cheapest gigabyte usually lives one tier above your data — until idle cost flips the answer back. The five Depot tiers run $30 to $70 list for 1–5 TB NVMe, which works out to $30.00 per TB at Depot 1 falling to $14.00 per TB at Depot 5 on list, and to a flat $24/TB on the annual term — arithmetic worth doing before reflexively buying the smallest tier.

The concrete spread: Depot 1 is 2 vCPU, 8 GB ECC, 1 TB NVMe behind a 2.5 Gbps port at $30.00 list; Depot 3 is 4 vCPU, 16 GB DDR5 ECC, 3 TB at $50.00, or $13.33 per TB; Depot 5 is 8 vCPU, 32 GB DDR5 ECC, 5 TB at $70.00, $11.20 per TB on the annual term. Order Depot 1 at $30.00 list — $24.00 on the annual term — and point the first Borg repo at it tonight; upsizing later is a migration of one directory.

Restore bandwidth is the spec people skip and later pray for: the Depot ports run unmetered from 2.5 to 10 Gbps, and that number decides what a 3 a.m. restore feels like — a 400 GB set pulls in about 21 minutes at 2.5 Gbps versus roughly 9 hours on a 100 Mbps link. When the RTO matters, the port speed on the target is worth more than the price per terabyte, and it costs nothing extra to prefer it.

The typical mistake is sizing to today's bytes while ignoring two multipliers: growth, and what deduplication actually does to your set — Borg and Restic compresses databases poorly but dedupes unchanged files perfectly, so the honest way to size is one measured borg create --dry-run --stats over the real state set, then a tier with a year of headroom, because re-tiering at 2 a.m. during a restore is nobody's idea of capacity planning.

Do the two-part math — per-TB curve plus restore bandwidth — and the sizing decision becomes a five-minute exercise with defensible numbers instead of a guess defended by vibes: a tier that fits the set with room to grow, a port that moves the set back inside your stated RTO, and a bill that stays flat while the data underneath it doubles, which is exactly what you want from infrastructure that exists to be forgotten about.

Databases refuse to be files

Copying a running database directory usually produces a file set that restores as garbage — the engine had unflushed pages in flight, and the copy captured the middle of a transaction. A database must either quiesce, dump consistently, or stream its own transaction log; anything that treats /var/lib/postgresql as ordinary files is manufacturing a backup that fails precisely when you need it, and failing quietly at that.

The dump route is the floor: pg_dump -Fc produces a compressed, consistent, restorable artifact for PostgreSQL, and mysqldump --single-transaction does the equivalent for InnoDB tables without locking readers — the mysqldump manual documents the flag's guarantees. Schedule dumps daily as the baseline, per the pattern in the PostgreSQL backup chapter, and keep at least one dump generation on the off-box target, not only on the database host.

The point-in-time route is the upgrade: continuous WAL archiving plus a base backup replays the database to any second, not just to the last nightly dump — the continuous archiving chapter is the reference implementation. Run both where the data deserves it: dumps as the boring, portable floor; WAL shipping for a recovery point objective measured in minutes. Files keep the simple cadence — daily — because their change pattern is human-scale.

Two failure modes account for most database-backup horror stories: rsync of the data directory while writes continue, which produces the corrupt-at-first-write copy described earlier; and a WAL archive configured onto the same disk as the base backup, so the one failure domain that eats the database eats its recovery path too. A third variant: dumps that accumulate but have never once been restored — a dump that has never restored is a rumor you pay storage for monthly.

Give the engine its own pipeline and the database stops being the scariest line in the restore plan — dumps prove restorability weekly, WAL bounds the loss window to minutes, and the file-level backup system handles everything the engine does not own, with the boundary between the two pipelines written down so the next person to touch the server knows which tool answers for which bytes.

The restore test is the only audit that counts

Backup jobs report success by writing bytes; restores decide truth. An untested backup is a hope with a schedule, and hopes fail in specific, boring ways — a repository corrupted months ago, a passphrase nobody can find, a restore path that was renamed in a refactor. The quarterly restore test exists to convert those slow failures into loud ones while the stakes are still a scratch directory instead of a production incident.

The mechanism is a scheduled job, not a heroics session: pick the newest snapshot, restore it into /srv/restore-test with restic restore latest --target /srv/restore-test, compare against live with diff -r on checksums or a sha256sum manifest, and report the exit code somewhere a human reads. The diff(1) manual covers the comparison flags; a systemd.timer runs the whole thing quarterly without anyone remembering to care.

Time the run and record the number, because restore minutes are your real recovery time objective — not the figure in the runbook, the one you measured. A 60 GB state set that restores in eleven minutes makes most downtime arguments moot; the same set taking four hours changes the architecture conversation. Measure quarterly, on the real target hardware, and let the number move the design instead of the other way around.

The failure modes of restore tests are subtle: tests that only exercise the test server, so production's restore path never runs; comparisons that succeed by diffing the wrong path and comparing nothing; and the worst one — a test that has never failed, because nothing real was ever checked, which means the test itself is decorative. Alert on failure, log the timing, and read the report; a restore test nobody reads is a backup ritual, not an audit.

Run it quarterly and the entire backup stack earns the only certificate that matters — a file tree that was ciphertext on another machine this morning, alive and byte-identical by lunch — and every other metric, from dedup ratios to job durations, falls into place as instrumentation rather than evidence, because the evidence was produced by an actual restore and the instrumentation merely explains how it got so fast.

Metal, other providers, and cross-host pushes

Dedicated boxes lose the snapshot leg — no platform snapshots exist on metal — so the off-box repository carries the whole 3-2-1 pattern, and the sizing math from earlier sections applies directly: a storage tier matched to the data set, pulled with Borg or Restic on a schedule. What RAID provides on metal is disk-failure tolerance, and the sentence worth taping to the rack is the old one: RAID is not a backup — it guards against a dead drive, not a deleted table, a compromised key, or a fire.

The second copy on metal deserves scrutiny precisely because the box is big: a second internal disk is still the same chassis, power feed, and failure domain, so copy two on a dedicated server should be either an on-host encrypted archive on separate hardware or, better, the off-box repository itself — leaving the raid array as acceleration for the production workload rather than pretending it is part of the recovery story at all.

Cross-host pushes keep the pattern honest for sources on other providers too: any server with SSH can push to your storage box over SFTP or the native Borg and Restic protocols, and the target never learns where the source is hosted — encryption at the source, covered earlier, is what makes that true. A fleet spread across hosts converges on one repository per server, one retention ladder, one restore test, all pointed at the same Depot hardware.

The mistake specific to this section is geography theatre: backing up a VPS to storage at the same facility and calling the pattern complete — same site, same flood plain, same upstream. For true disaster cases the off-box leg wants a second site or a cold copy, which for most real workloads means: repository at another facility, plus the platform snapshot for operational mistakes, and an honest note in the runbook about which class of failure each layer answers.

Extend the pattern this way and it stops mattering where the source lives — VPS or metal, this provider or another, every machine converges on the same three honest copies and the same tested restore — which is the point of a pattern in the first place: the same six commands, the same calendar, and the same proof, applied wherever a root prompt and a state set happen to meet.

Retention, keys, and the human layer

The technically weak link is rarely throughput — it is retention nobody reviews and keys nobody can find during an incident, and both problems are solved by calendar entries rather than better software. Retention decides how far back history reaches; keys decide whether any of that history is readable; and the human layer is the runbook that connects a 3 a.m. operator to both without a phone call to whoever wrote the scripts.

A sane ladder keeps cost flat while history deepens: borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6, or the Restic equivalent restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6, gives seven days of surgical rollback, a month of weekly archaeology, and half a year of milestones for roughly double the space of a naive seven-day pile. Apply retention after verification — prune what restic check and borg check have pronounced healthy, not what a job exit code claims.

Keys need two homes and one test: the repository passphrase and the target's SSH key each live in two independent places, and the quarterly restore test doubles as the decryption drill — the key that opens the repository gets exercised by the same job that proves the bytes. Document where the copies live, in the runbook, in full sentences, because a note that says ask Dave is not a key management policy.

The failure mode is quieter than data loss: retention that silently keeps everything, so the repository grows until the tier is full and jobs start failing — the one signal they produce being the one nobody wired to alerting. The inverse failure: aggressive pruning validated by nothing, so the day you need last March, the ladder explains calmly that March was pruned in April. Both are one-line schedule reviews away from being impossible.

Run the human layer with the same discipline as the bytes — retention reviewed quarterly against the bill, keys tested quarterly by the restore, the runbook updated the week anything changes — and the backup system survives its creator's departure, its own bit rot, and your future self's memory, which are the three failure modes that outlast every tool you will ever use to store things.

The backup cycle, in the order to run it

Day zero: draw the state line — databases, uploads, TLS keys, diverged configs get copies; the OS gets a rebuild script — and commit the script to version control where it will actually be maintained. This single decision sizes everything downstream, because a copy set that is a few dozen gigabytes of genuine state can live on cheap tiers with fast ports, while a whole-disk copy set buys nothing but storage bills and slower restores.

Week one: build the three legs in order. Turn on the platform snapshot for the fast-rollback layer, initialize the off-box repository encrypted at the source with Borg or Restic on a Depot tier sized by measured state plus a year of growth, and run the first full backup — then restore it once by hand, end to end, because the first restore should happen while the old backups still exist to catch the mistake.

Week two onward: schedules take over. Database dumps daily with WAL shipping where the data justifies it, files daily, retention applied with borg prune or restic forget after checks pass, and job outcomes wired to something a human reads. The credential discipline from the signup guide applies here too — the repository key and the storage box's SSH key each need two homes, because a backup system with a single point of key failure is a locked safe whose combination you wrote on the door.

Quarterly: the restore test — newest snapshot, restore into scratch, compare, time it, read the report — plus the decryption drill and a retention review against the bill. Annually: rebuild the whole box from the script onto fresh hardware and re-run the restore on top of it, which exercises the one scenario the quarterly test does not: everything gone at once. Both exercises have predictable costs in hours and unpredictable costs only when skipped.

Incident posture, then, is just the cycle running at an unhappy time: restore order is configs first, then database, then files; the RTO is the number you measured, not the one you hoped; and if the source machine itself is the casualty, the migration playbook re-provisions while the repository restores in parallel. When a workload finally retires its server, snapshot before decommissioning — the add-on rides the checkout — and let the platform guide explain why the replacement should keep owning its kernel; the backup cycle, run in this order, makes every one of those days boring, which is the entire point.