You run one VPS. It hosts your app, your database, and probably a couple of side projects you haven’t thought about since you deployed them. There’s no ops team, no second engineer to catch a bad rm -rf, and no budget for a dedicated backup vendor. This is exactly where the 3-2-1 backup rule for solo sysadmins and small teams in 2026 earns its keep: it isn’t a compliance checkbox lifted from a Fortune 500 playbook, it’s a specific, cheap way to make sure one mistake, one dead disk, or one hosting incident doesn’t end your project. The rule itself is short: three copies of your data, on two different types of storage, with one copy offsite. Making that real on a single box with no infrastructure team is the part most guides skip, and it’s what this one covers.
What is the 3-2-1 backup rule, and does it hold up for a one-person setup?
The rule comes from photography and archival storage, not from server ops, but the logic transfers directly: keep three copies of anything you can’t afford to lose, store them on two different kinds of media so a single storage-type failure (a bad disk, a corrupted volume) can’t take out more than one copy, and keep at least one of those copies somewhere physically or organizationally separate from the rest, so a single site or account incident can’t take out everything at once.
The usual objection from a solo sysadmin is that 3-2-1 was designed for organizations with a NAS, a tape rotation, and someone whose job title includes the word backup. That objection misreads the rule as a specific piece of hardware rather than a shape. Nothing about “three copies, two media, one offsite” requires headcount. It requires a database dump, a cron job, and a storage bucket that isn’t run by the same provider as your VPS. The scale changes for a one-person setup; the structure doesn’t.
The more honest reason solo operators skip it is time. A single VPS provider snapshot feels like enough coverage, and setting up a second, independent storage leg looks like a project rather than a five-minute task. It usually is a project the first time. It’s also the kind of project that costs an afternoon to do once and nothing to run afterward, against a failure mode (a wiped disk, a locked account, a bad migration with no way back) that costs a project, a client, or a weekend if it happens with no backup in place.
What actually counts as “three copies” on a single VPS?
This is where most solo setups quietly fail the rule without realizing it. “Three copies” does not mean three servers. It means your live, primary data counts as copy one, and you need two more copies derived from it, each independent enough that losing one doesn’t threaten the others.
On a typical single-VPS stack that’s: copy one is the running database and application data on the VPS itself. Copy two is a backup file (a database dump, a tarball of uploads) written somewhere other than the same disk the production data lives on, ideally a separate attached volume. Copy three is that same backup pushed to offsite object storage. The failure mode this catches is the one that actually happens to solo operators: a full-disk failure or a botched migration wipes the VPS, but the offsite copy is untouched because it was never reachable from that disk in the first place.
The mistake to watch for is treating a second directory on the same disk as a real second copy. A nightly dump written to /root/backups on the same volume as the production database is convenient, and it will save you from an accidental DROP TABLE, but it does nothing against a disk failure, a corrupted filesystem, or an account-level incident with your VPS provider. It’s a copy in name only if it shares a failure domain with the thing it’s backing up.
A concrete version of this on a typical small app: a Postgres database and a handful of user-uploaded files sit on a single VPS. Copy one is that live database and upload directory. Copy two is a nightly pg_dump plus a tarball of the uploads directory, written to a separate attached volume so a root-disk failure doesn’t take out the dump alongside the data it was dumped from. Copy three is that same file, pushed to an object storage bucket a few minutes later. If the VPS disappears entirely tomorrow, restoring means provisioning a new box and pulling the last dump from the bucket, not reconstructing anything from memory.
Which two storage media actually make sense on a small budget?
For a solo setup, the two media that make practical sense are local disk (or a separate attached block-storage volume) for fast, cheap, frequent backups you’d reach for first during a restore, and S3-compatible object storage (Backblaze B2, Cloudflare R2, Wasabi, DigitalOcean Spaces) for the durable, offsite copy. Local disk gives you a restore in seconds without touching the network; object storage gives you a copy that survives the VPS itself disappearing.
Watch for the fake-diversity trap: two buckets in the same cloud account, even in different regions, are not real media diversity. They share one login, one billing relationship, and one account that can be suspended, locked, or compromised in a single event, taking both “copies” with it. Genuine diversity means a storage medium your VPS provider doesn’t operate and, ideally, an account you access with different credentials than the ones that run your server. Pairing a local volume with one object storage provider that isn’t your hosting provider covers this cheaply: most providers in this tier price well under ten dollars a month for the amount of data a small VPS backup set actually produces.
Backblaze B2, Cloudflare R2, and Wasabi are the three that solo operators reach for most, and the meaningful differences between them are egress pricing and minimum retention, not storage cost, which is close to identical across all three at a few dollars per terabyte per month. Whichever one you pick, the point of this section isn’t the specific vendor, it’s making sure it’s a different vendor than the one hosting your VPS.
Why does offsite mean more than a different folder or a snapshot?
VPS provider snapshots are the easiest backup you’ll ever set up: one click, no scripting, done. They’re also not offsite in the sense the 3-2-1 rule means. A snapshot lives in the same account, under the same billing relationship, often in the same region as the server it’s a snapshot of. If your account gets suspended over a billing dispute, if the provider has a regional incident, or if credentials to that account are compromised, your snapshot is exposed to the exact same event as your live server.
Genuine offsite means a different provider, a different login, and ideally a different payment method, so that no single incident, technical or administrative, can reach both your production server and your backup at once. Snapshots are a useful extra layer for fast whole-server rollback, and they’re worth keeping, but they don’t satisfy the “1” in 3-2-1 on their own.
What should a solo sysadmin actually back up on a single VPS?
Not everything on a VPS deserves backup effort. The goal is capturing what you cannot regenerate from a base image and a deploy script. On a typical single-VPS stack, that’s:
- Database dumps:
pg_dump,mysqldump, ormongodumpoutput, not a raw copy of live data files. - Application data directories: user uploads, generated files, anything not reproducible from your git repo.
- Web server and process config: your nginx/Caddy vhost files and systemd unit files, since rebuilding these from memory after an incident is slow and error-prone.
- SSH host keys and
~/.ssh/authorized_keys: losing these means every client reconnecting to a rebuilt server gets a host-key warning, and losing authorized_keys means locking yourself out. See the complete guide to SSH security for how these fit into a server’s broader security posture. - TLS certificates, if you’re not on fully automated Let’s Encrypt renewal (if you are, these are cheap to reissue and lower priority).
- Crontab entries and systemd timer definitions, and any
.envfiles, handled carefully since these often contain secrets that need encryption at rest even in backup form.
What’s safe to skip: installed OS packages and binaries, which a provisioning script rebuilds faster than any backup restores; framework dependency directories like node_modules or vendor folders, which lockfiles reproduce exactly; and logs beyond whatever retention window you’ve already set, which are rarely worth the storage cost of a second copy.
How much does a real 3-2-1 setup cost?
A realistic solo pipeline looks like this: a scheduled job dumps the database and tars up application data to local disk, then a second job pushes that local backup set to an S3-compatible bucket with a tool built for it, rather than hand-rolled scp. restic and rclone both handle this well, with restic adding deduplication, encryption, and integrity checks on top.
# dump the database to local disk
pg_dump -Fc mydb > /var/backups/mydb-$(date +%F).dump
# archive application data
tar czf /var/backups/app-data-$(date +%F).tar.gz /srv/app/uploads
# push the local backup set offsite, encrypted, deduplicated
restic -r s3:s3.us-west-000.backblazeb2.com/mybucket backup /var/backupsObject storage in this tier typically runs a few dollars per terabyte per month, and a small VPS backup set (database dumps plus application data, not full disk images) is usually a few gigabytes, so realistic monthly cost for the offsite leg is often under two dollars. The VPS itself is a sunk cost you’re already paying for, and the local disk leg is usually just a few gigabytes carved out of storage you already have. Total incremental cost for a real 3-2-1 setup on a small project is commonly under five dollars a month, well below the cost of a single hour of downtime or data loss on anything you’d call production.
The bulk of the actual work isn’t the storage bill, it’s wiring the two jobs together reliably: a systemd timer or crontab entry that runs on schedule without manual intervention, retention rules so old backups don’t accumulate indefinitely and quietly fill the bucket, and alerting when a job fails silently instead of just not running. A minimal crontab entry to kick off the pipeline above looks like 0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1, run nightly at 3am with output captured so a failure leaves a trace instead of vanishing. Automating server backups with cron and offsite storage walks through that full pipeline, including retention and failure alerting, end to end.
Is 3-2-1 still enough in 2026, or do you need 3-2-1-1-0?
3-2-1-1-0 is an extension that’s become more common as ransomware and accidental bulk-deletion have become the more likely failure mode, rather than pure hardware failure. It adds one immutable or air-gapped copy, meaning a backup that can’t be modified or deleted even by an attacker (or a mistaken script) with valid credentials, typically via object-lock or versioning on the offsite bucket, and zero errors, meaning your restore process is actually verified rather than assumed to work.
For a solo project or a small team, 3-2-1-1-0 is a maturity step, not a starting requirement. It’s worth adopting once you’re handling other people’s data, holding a paid uptime commitment, or simply have the time to add object-lock to a bucket you’ve already set up, which is a small configuration change on top of an existing 3-2-1 setup, not a rebuild.
How do you know your backups actually work?
A backup job that runs on schedule and reports success is not the same as a backup that restores. The only real test is restoring: spin up a throwaway server or container, pull the latest backup down, restore it, and verify the data is actually usable. Quarterly is a reasonable minimum cadence for a solo project; monthly is better for anything that would genuinely hurt to lose. Tools like restic support a built-in restic check to verify repository integrity between full restore drills, which catches silent corruption earlier than waiting for the day you actually need the data back.
It’s also worth keeping an eye on the box that holds your local backup copy day to day, since a backup job that’s been silently failing because the disk filled up is a common and entirely preventable failure. Monitoring disk usage on a Linux server without third-party tools covers exactly this without adding another dependency to the box you’re trying to protect. And once you’ve verified a restore works in principle, you still need a documented, repeatable order of operations for doing it under pressure: a disaster recovery runbook for a single VPS turns “I think I know how to restore this” into a written checklist you can follow at 2am without improvising.
A minimal 3-2-1 checklist for solo sysadmins and small teams
- Three copies: production data, a local backup file on separate storage, and an offsite copy. Not three servers, three independent copies.
- Two media: local disk or a separate volume, plus S3-compatible object storage from a provider other than your VPS host.
- One real offsite copy: different account, different provider, ideally different payment method than your production server.
- Back up database dumps, application data, web server and process config, SSH host keys and authorized_keys, TLS certs if not auto-renewed, and cron/systemd definitions. Skip reinstallable packages, dependency directories, and old logs.
- Automate the dump-then-push pipeline with cron or systemd timers rather than running it by hand. See automating server backups with cron and offsite storage for the full setup.
- Test a real restore on a schedule, not just a job success notification, and keep a written recovery runbook. See a disaster recovery runbook for a single VPS.
- Consider 3-2-1-1-0 (an immutable copy plus verified restores) once you’re handling other people’s data or a paid uptime commitment, not before.
Where termique fits around your backup and recovery workflow
None of the pipeline above requires termique, and it shouldn’t: 3-2-1 is a data-storage discipline, not a product feature. Where termique does help is the SSH layer wrapped around it. The credentials and keys your backup jobs use to reach a bastion host or push to a remote box are worth managing the same way you manage the data itself: termique’s SSH key vault keeps those keys generated, tracked, and out of scattered files, and if you run backup jobs or manual restores from more than one machine, a synced, end-to-end encrypted credential vault means you’re not copying private keys around by hand to get a second laptop working.
The per-command audit log is useful in the moment a restore actually happens: a dated record of exactly which commands ran on which host during a recovery, without setting anything up in advance for that specific incident. And termique’s built-in SFTP file browser is a fast way to pull a single file off a remote box mid-restore, without opening a separate SFTP client just for one file. termique is free for a solo setup: 3 hosts, unlimited terminal sessions, and SSH key management at no cost, with Pro adding unlimited hosts and audit logs for $5 a month if a small team grows past the free tier.
