Category
Backup and object storage
A backup you have not restored is a rumour. A backup the source machine can delete is not a backup at all, it is a second copy waiting for the same accident.
There is one question here and everything else follows from it: can the machine you are backing up destroy the backup? If the answer is yes, you have a second copy, not a backup. A second copy protects you against a dead disk. It does not protect you against the two things that actually take people's data: a mistake you make yourself, and software running as you that deletes or encrypts everything it can reach.
That is why append-only matters more than compression ratios, and why a permanently connected external drive is worth less than the same drive plugged in on Sundays.
The default: restic, off the box, append-only#
restic is the sane default: one static Go binary, no daemon, no agent, no account, writing encrypted deduplicated snapshots to almost any target. It idles around 100 MB, scores 2 on ops load, and the same repository format works from Linux, macOS, Windows and a NAS.
Point it at a rest-server running with --append-only on a different machine. That single flag is the difference between a backup and a second copy: a compromised client can add snapshots and cannot remove them. Prune from the server side, on a schedule, with credentials the client never sees.
Budget two things restic will not warn you about. prune loads the repository index into RAM, so a multi-terabyte repository with millions of blobs gets OOM-killed on a 2 GB VPS. And a run that dies leaves a lock that blocks the next one until you restic unlock or pass --retry-lock 10m.
Two cases argue for something else.
Your only destination is an SSH account. Then BorgBackup, which needs nothing on the far side but a borg serve binary and gives you the same append-only guarantee through a forced command in authorized_keys. Run the 1.4 line: 1.4.5 shipped in July 2026, and 2.0 is still labelled testing-only after four years with an incompatible repository format.
Other people in the house need to click restore. Then Kopia, which has a real desktop GUI and a repository server, so laptops never hold the storage credentials. It costs about 200 MB and one habit: only one client performs full maintenance, and if that machine is reimaged nobody reclaims space, so check kopia maintenance info occasionally. If the destination is a consumer cloud like OneDrive or Google Drive, Duplicati speaks those natively and finally shipped stable in January 2025.
What a file copy cannot save#
81.9 percent of the tools profiled here cannot be safely backed up by copying files while they run. That is not a warning about exotic software, it is the ordinary case: anything on Postgres, MariaDB, MongoDB or SQLite. The failure is quiet. The copy succeeds, the archive looks the right size, and the restore produces a database that will not open.
So a real backup job is not one command. Dump the database, then snapshot the dump alongside the data directory, in that order. Seafile documents why the order matters, and it is the general rule: dump first, so every database record points at an object that already exists.
The mistakes people actually make#
- Confusing sync with backup.
rclone syncmakes the destination match the source, deletions included, and rclone's own docs say to test with--dry-runfirst. For anything backup-shaped use--backup-dir remote:archive/$(date +%F), or put restic on top and let rclone be the transport it is excellent at. - Running
forgetwithoutprune.restic forgetonly drops snapshot references. Nothing is reclaimed and your storage bill does not move untilpruneruns. Borg has the same trap withpruneandcompact. - Unscoped retention.
restic forgetwithout--hostor--tag, orborg prunewithout--glob-archives, applies your policy across every machine in the repository. One machine's seven-daily rule deletes another machine's monthly history. - Keeping the passphrase on the machine being backed up. restic wraps the master key with your passphrase and there is no recovery path, no vendor, no backdoor. If it only exists in an env file on the dead host, the backup died with it. Run
restic key addand store the second one elsewhere. - Assuming deletion frees space. Kopia's snapshot deletion is a metadata operation; blobs go after full maintenance and safety delays, which is hours to days. Do not start a second repository because the bill did not move.
What to read next#
Backups that actually restore is the build sheet for the default above, and Backing up a running database is what to read before trusting any file copy. Size it with Backup planner and check your exposure with Resilience scorecard. ZFS, btrfs, mdadm or one disk explains what RAID does and does not buy. Head to head: restic vs BorgBackup, restic vs Kopia, Duplicati vs restic and MinIO vs Garage. The full findings are in The backup blind spot.
Every backup tool we profile#
Sorted by operational load, lightest commitment first. Every row links to a full profile with the resource numbers, the upgrade traps and the restore path.
| Tool | Ops load | Idle RAM | Licence | Identity | Backup shape |
|---|---|---|---|---|---|
| BorgBackup | 2, Light | 80 MB | BSD-3-Clause | Not applicable | Mixed |
| Kopia | 2, Light | 200 MB | Apache-2.0 | Local accounts only | Mixed |
| rclone | 2, Light | 40 MB | MIT | Not applicable | File copy |
| restic | 2, Light | 100 MB | BSD-2-Clause | Not applicable | Mixed |
| Duplicati | 3, Moderate | 200 MB | MIT | Local accounts only | SQLite backup |
| Garage | 3, Moderate | 150 MB | AGPL-3.0-only | Not applicable | SQLite backup |
| MinIO | 4, Heavy | 250 MB | AGPL-3.0 (repository archived) | Local accounts only | File copy |
Profiles#
BorgBackup
Deduplicating, compressed, authenticated-encryption backups over plain SSH
ops 2/5 · 200 MBKopia
Deduplicating encrypted snapshots with a real desktop GUI and a repository server
ops 2/5 · 40 MBrclone
rsync for cloud storage: 70+ backends, one config file, and no snapshot history
ops 2/5 · 100 MBrestic
Encrypted, deduplicating snapshots to almost any storage target from one static Go binary
ops 3/5 · 200 MBDuplicati
Web-managed encrypted backup to any cloud target, finally out of beta
ops 3/5 · 150 MBGarage
Small, geo-distributed S3 storage that does less than MinIO on purpose
ops 4/5 · 250 MBMinIO
The S3-compatible object store everyone used, now archived upstream
Head to head in this category#
- Duplicati vs resticDuplicati is finally stable. The database rebuild is still the reason people leave it.
- MinIO vs GarageThis stopped being a fair fight in 2026. MinIO is archived; here is what to do about it.
- restic vs BorgBackupBorg 2 is still beta and the 1.x move is a repository rewrite. That decides more than the feature list.
- restic vs KopiaKopia has the nicer interface. That is not a reason to pick a backup tool, and here is what is.
Guides for this category#
- Backups that actually restoreThe difference between a backup and a sync, append-only repos, snapshot ordering, and a restore rehearsal with a number attached.
- Backing up a running database without corrupting itTorn reads, WAL files, pg_dump versus snapshots, and why a filesystem snapshot is safe when a copy is not.
- Moving a self-hosted service to a new machineThe six-step move, the file ownership trap that breaks most migrations, and the keys you must bring with you.
- What a home server actually costs to runThe five-year arithmetic, and the point at which self-hosting stops losing money.
- Your first self-hosted server: the decisions that are hard to undoThe OS, the disk layout, remote access and backups are hard to undo. Everything else is an afternoon.
- Storage layout: ZFS, btrfs, mdadm, or just one diskThe write hole, the resilver window, the RAM appetite, and one recommendation per situation.
- When not to self-hostFive categories where self-hosting is a bad trade, one decision test, and the cases where it genuinely wins.
Questions#
Is a RAID array a backup?
No. RAID protects against one specific failure, a disk dying, and against nothing else. It does not help with an accidental rm -rf, a bad upgrade that corrupts a database, ransomware, a failed PSU that takes several drives with it, theft, or fire, because every one of those changes hits all mirrors at the same instant. Mirroring is an availability feature: it keeps the service up while you replace hardware. If your only copy is a ZFS mirror in one chassis, you have one copy. Aim for three copies, on two kinds of media, with one off-site.
Can I back up a running app by copying its files?
For most of them, no. 81.9 percent of the tools profiled here cannot be safely backed up by copying files while they run, because they sit on Postgres, MySQL, MongoDB or SQLite. A live cp of a WAL-mode SQLite file restores corrupt often enough to ruin an evening, and a Postgres data directory copied under load is simply not consistent. The fix is per engine: pg_dump, mariadb-dump --single-transaction, sqlite3 db ".backup out.db", or stop the container for the 20 seconds the copy takes.
How often should I test a restore?
Once when you set it up, and then once every six months or after any change to the backup job. The test is not restic check, which only validates the repository structure. The test is restoring into a scratch directory or a throwaway container and logging in. Vaultwarden is the clearest example: a nightly cp of the SQLite file appears to work for a year, and you find out it does not on the day you need it. Time the restore too, so your recovery estimate is measured rather than imagined.
restic or Borg?
restic if your destination is object storage, a bucket at a provider, or you want the same tool on Linux, macOS and Windows writing one repository format. Borg if your destination is an SSH account on a box you or a friend owns, since it needs nothing there but borg serve. Both give you append-only push backups, which is the property that matters. Borg's version answer for 2026 is 1.4: 2.0 has been in beta for years, repositories are not compatible, and migration is a borg transfer into a new repository needing space for both copies.
What should I exclude from backups?
Anything the application can regenerate, which is usually the bulk of the bytes. Immich's thumbs/ and encoded-video/ rebuild from the admin jobs page. Nextcloud's appdata_*/preview tree is often the largest single directory on the disk. Jellyfin's /cache and transcode scratch are disposable, as are Docker images and /var/lib/docker/overlay2. What you must never exclude is the thing that encrypts everything else: APP_KEY, SECRET_KEY, storage.encryption_key, an LLDAP key seed, a restic passphrase. Those belong with the backup, not inside it.
Do I need S3-compatible storage at home?
Only if an application demands an S3 endpoint. As a backup target it buys you little on one machine, and MinIO is no longer the answer regardless: the repository was archived on 25 April 2026 with no further security releases, and the May 2025 release had already removed the management console and OIDC login from the community build. Garage is the maintained AGPL alternative, at the cost of three-way replication (a three-node cluster gives you a third of your raw disk) and no object versioning or object lock, so it cannot be made immutable at the S3 layer.
How do I stop ransomware deleting my backups?
Make the source machine unable to delete history. With Borg, force borg serve --append-only as the command on the backup account's SSH key, so a compromised client can write new archives but not remove old ones. With restic, run rest-server with --append-only, or use a bucket with object lock and credentials that cannot disable it. Pruning then happens from somewhere else, on a schedule, using a different key. Anything that runs rclone sync from the infected host propagates the damage in minutes, by design.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.