💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Prologue — Backups Are Boring, Until They Are Not

Every company has this conversation at least once.

Engineer: "The DB is gone."

PM: "Backups?"

Engineer: "Yes. From last November."

PM: "...have you ever tried to restore one?"

Engineer: "No."

This scene plays out somewhere in the world every single day in 2026. Taking backups and being able to restore them are **two different things**. And running a backup system is a completely different problem from `cron`-ing a tar to a NAS.

This article is a map of the 2026 open source backup ecosystem — from file-level tools like Restic, BorgBackup, Kopia, and Duplicati; through sync-based ones like rclone and rsnapshot; to enterprise OSS like Bacula, Bareos, and Amanda; K8s backup tools like Velero and Kasten; DB tools like pgBackRest and WAL-G; and cold storage like LTO tape, B2, Wasabi, and Storj.

1. The 3-2-1 Rule — and the 2026 3-2-1-1-0 Variant

The golden rule of backup strategy was formalized in the 1980s by photographer Peter Krogh as the **3-2-1 rule**.

- **3** copies — the original plus two backups

- **2** media types — different media (e.g., SSD + tape, NAS + cloud)

- **1** offsite — at least one physically remote

In the late 2020s ransomware era, this evolved into **3-2-1-1-0**.

- **1** immutable / air-gapped copy

- **0** errors verified by regular checks

When ransomware encrypts your backups too, "one immutable copy" is no longer a luxury. AWS S3 Object Lock, B2 Object Lock, immutable tape, write-once optical media — all fall into this category.

Key insight: **the value of a backup lies in the restore.** A backup you have never restored from is not a backup — it is just a file taking up disk space.

2. Backup Types — Full, Incremental, Differential, Synthetic Full

Let us define terms. Using the same word for different things is a bad tradition of the backup industry.

| --- | --- | --- | --- | --- |

Modern tools like Restic, Borg, and Kopia use a **forever-incremental + content-defined chunking + dedup** model. Each run behaves like a full backup but only stores changed chunks. This has become the de facto standard of the 2020s.

3. Restic 0.18 — The Go-World Standard

**Restic** (Alexander Neumann, 2014) is an open source (BSD 2-clause) backup tool written in Go. As of 2026 the stable line is 0.18, and it has become the near-standard among self-hosters and the SRE community.

Highlights.

- **Encryption by default** — AES-256-CTR, Poly1305-AES MAC, scrypt KDF

- **Content-defined chunking + dedup** — Rabin fingerprinting, average 1 MiB chunks

- **Many backends** — Local, SFTP, REST server, S3-compatible (AWS S3, Minio, Wasabi, Backblaze B2, ...), Azure Blob, Google Cloud Storage, OpenStack Swift, rclone (50+ clouds)

- **Single static binary** — Go means zero runtime dependencies

- **Snapshot-based** — each backup is an immutable snapshot

Basic workflow.

Init the repo (once)

export RESTIC_REPOSITORY="s3:s3.amazonaws.com/my-backups"

export RESTIC_PASSWORD="strong-passphrase"

restic init

Backup

restic backup /home/user --tag daily

List snapshots

restic snapshots

Restore

restic restore latest --target /restore

Integrity check

restic check --read-data-subset=10%

Retention (keep 7 daily, 4 weekly, 12 monthly)

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Pros and cons.

- Pros: safe, fast, rich choice of backends, active community

- Cons: lock contention with concurrent jobs on a single host, prune historically slow (improved from 0.17)

Bottom line: if you are starting from scratch, **Restic + an S3-compatible backend (B2, Wasabi, Storj)** is the safe 2026 default.

4. BorgBackup 1.4 / 2.0 — The Python Classic

**BorgBackup** (started as Attic in 2010, forked to Borg in 2015) is a BSD-licensed backup tool written in Python. As of 2026, 1.4 is stable and 2.0 is in beta.

Highlights.

- **Client-server architecture** — runs over SSH, integrates with ssh-agent

- **Compression** — choice of lz4, zstd, lzma

- **Dedup + chunking** — Buzhash-based

- **Encryption** — AES-256-CTR + HMAC-SHA256

- **Append-only mode** — clients cannot delete old backups (ransomware-resistant)

Basic usage.

Init the repo

borg init --encryption=repokey-blake2 user@backup.example.com:./backups

Backup

borg create --stats --progress \

user@backup.example.com:./backups::myhost-{now} \

/home /etc /var

List

borg list user@backup.example.com:./backups

Mount to explore (before restore)

borg mount user@backup.example.com:./backups::myhost-2026-05-16 /mnt/borg

Restore

borg extract user@backup.example.com:./backups::myhost-2026-05-16

Retention

borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=12 \

user@backup.example.com:./backups

**Borgmatic** — a declarative wrapper for Borg. YAML config manages schedule, retention, hooks, and notifications. Together with systemd timers or cron it is one of the most popular self-hosting combinations.

Borg vs Restic — a short comparison.

| Dimension | BorgBackup | Restic |

| --- | --- | --- |

| Language | Python | Go |

| Backend focus | SSH (rsync.net, hetzner storagebox, ...) | Many native cloud backends |

| Concurrency | Single-client preferred | Multi-client OK |

| Compression | lz4 / zstd / lzma | (None until 0.16, then optional) |

| Mount | FUSE | FUSE (mount command) |

| Package | Python deps | Single static binary |

Bottom line: for single-server self-hosters using SSH backends (rsync.net, Hetzner Storage Box), Borg is still the first choice. For multi-client or cloud-native backends, Restic is more convenient.

5. Kopia 0.18 — Cloud-Native with a GUI

**Kopia** (Jarek Kowalski, 2019, Apache 2.0) is a Go-based backup tool that distinguishes itself by shipping both a CLI and a polished GUI.

Highlights.

- **CLI + GUI (Desktop App)** — KopiaUI is an Electron-based GUI shipped separately

- **Content-addressable storage** — essentially a "Git for backups"

- **Many backends** — S3, B2, GCS, Azure, WebDAV, SFTP, Filesystem

- **Compression** — zstd, gzip, s2

- **Encryption** — AES-256-GCM

- **Policy-based** — per-directory and global policies

Basic usage.

Create repo (S3 backend)

kopia repository create s3 \

--bucket=my-kopia-backups \

--access-key=$AWS_ACCESS_KEY_ID \

--secret-access-key=$AWS_SECRET_ACCESS_KEY

Backup

kopia snapshot create /home/user

List

kopia snapshot list

Restore

kopia snapshot restore <snapshot-id> /restore

Verify

kopia content verify

Policy

kopia policy set --keep-daily=7 --keep-weekly=4 /home/user

Pros: a real GUI makes it friendly for families and small teams; KopiaUI can live in the menu bar and show progress automatically.

Cons: less operational wisdom accumulated than Borg/Restic; some backends are community-reported.

Bottom line: **Kopia is close to the answer if you want to start with a GUI on macOS or Windows.**

6. Duplicati 2.0 — Cross-Platform GUI on .NET

**Duplicati** (started 2008, LGPL) is a .NET-based, GUI-first backup tool. As of 2026, 2.0 is the stable line (still carrying a "beta" stigma in some circles, though most users run it in production).

Highlights.

- **Web GUI** — accessible at `http://localhost:8200`

- **Almost every cloud** — 50+ backends (S3, B2, OneDrive, Google Drive, Dropbox, FTP, SSH, WebDAV, Mega, ...)

- **AES-256 encryption**

- **Block-based dedup**

- **Windows, macOS, Linux, Docker** support

Pros: GUI-friendly, marketed to general users. Popular on small NAS and home server setups.

Cons: .NET runtime dependency, historical database-corruption issues (largely fixed in 2.0), and slower restore speed compared to peers.

Bottom line: if a non-technical user wants to back up via a GUI, Duplicati works. But test restores become even more critical.

**Duplicacy** — a similarly named but separate commercial tool. $20 one-time personal license. CLI is open source, GUI is commercial. Its differentiator is lock-free dedup.

7. rclone 1.68 — "rsync for Cloud Storage"

**rclone** (Nick Craig-Wood, 2014, MIT) is strictly speaking not a backup tool but a **cloud storage sync tool**. Yet by 2026 it has become a core component of so many backup workflows that we cannot skip it.

Highlights.

- **50+ cloud backends** — S3-compatible, B2, GCS, Azure, OneDrive, Google Drive, Dropbox, pCloud, Mega, FTP, SFTP, WebDAV, Yandex, Box, ...

- **Commands** — `copy`, `sync`, `move`, `mount`, `serve`, `bisync`, ...

- **Crypt backend** — `rclone crypt` adds an encryption layer on top of any other backend

- **Dedup** — `rclone dedupe`

- **Bandwidth limiting, parallel transfers, encryption**

Typical uses.

- **Backend adapter** — Restic and Borg can use `rclone:` to access 50+ clouds

- **Standalone sync** — `rclone sync /home gdrive:backup`

- **Encryption layer** — `rclone crypt` for client-side encryption on Google Drive, OneDrive, etc.

Configure remote (once)

rclone config

Sync (one-way)

rclone sync /home/user remote:backup --progress

Bidirectional (beta)

rclone bisync /home/user remote:backup

Mount (read/write)

rclone mount remote:backup /mnt/cloud --vfs-cache-mode=full

Size

rclone size remote:backup

Bottom line: **rclone is most powerful as a backend adapter rather than a backup tool itself.** Restic + rclone has become the de facto self-hoster standard in 2026.

8. rsync + rsnapshot — Classics That Still Work

**rsync** (Andrew Tridgell, 1996) is a file synchronization utility rather than a backup tool, but it is the most basic and most widely used building block.

Common pattern.

Local to remote over SSH

rsync -avzP --delete /home/user/ user@remote:/backup/user/

Hard-link based incremental (built-in)

rsync -avzP --delete --link-dest=/backup/2026-05-15 \

/home/user/ /backup/2026-05-16/

**rsnapshot** (Perl) is a tool that uses rsync to manage time-based snapshots automatically. A single config declaratively runs hourly/daily/weekly/monthly retention. It has barely changed since 2002 and is rock-stable.

/etc/rsnapshot.conf (tab-separated)

snapshot_root /var/backups/rsnapshot/

retain alpha 24 # hourly, keep 24

retain beta 7 # daily, keep 7

retain gamma 4 # weekly, keep 4

retain delta 12 # monthly, keep 12

backup /home/ localhost/

Pros: simple, 30 years of battle-tested wisdom, works on any Unix.

Cons: no encryption (SSH-in-transit only), file-level dedup (not block-level), no compression.

Bottom line: for simple scenarios like NAS-to-NAS, it is still a fine choice. As soon as cloud and encryption enter, moving to Restic/Borg is standard.

9. Bacula / Bareos — Enterprise OSS

**Bacula** (Kern Sibbald, 2000, AGPLv3) is an enterprise-grade backup, restore, and verification system. Components are split out.

- **Director** — manages backup jobs (schedule, catalog)

- **Storage Daemon** — handles actual reads/writes to media (disk, tape, cloud)

- **File Daemon** — runs on the client, touches the filesystem

- **Catalog DB** — MySQL/MariaDB/PostgreSQL for backup metadata

**Bareos** (Bacula fork, 2010, AGPLv3) is the more open-source-friendly fork — more active development, better web UI, faster RHEL/SUSE packaging.

When to use it.

- Tens to hundreds of clients

- Tape library operations (LTO)

- Strict RPO/RTO and audit requirements

- VSS, BMR (Bare Metal Restore) needs

- Existing Bacula/Bareos operational know-how

Cons: steep learning curve, component separation makes setup complex, definitely not "set and forget".

Bottom line: under 50 hosts, Restic/Borg plus central storage is simpler. Over 100 hosts with tape and audit requirements, Bareos is a serious choice.

10. Amanda — Another Enterprise Classic

**Amanda** (Advanced Maryland Automatic Network Disk Archiver, started 1991 at the University of Maryland) is a 30+ year-old backup system, BSD-licensed, with commercial support from Zmanda.

Highlights.

- One server backs up many clients

- Supports tape, disk, and cloud media

- Uses a holding disk (staging)

- Leverages tar, dump, samba, and more as backup backends

When to use it.

- Legacy operational environments (especially academic/financial)

- When you want something simpler than Bacula

Cons: no modern UI, near-zero new adoption.

Bottom line: not a strong choice for new projects. But it remains a stable maintenance target for existing deployments.

11. UrBackup — Integrated Client-Server Solution

**UrBackup** (Martin Raiber, 2011, AGPL) is a client-server backup tool with strong user-friendly features: web UI, Windows VSS, image-level backups.

Highlights.

- Web UI at `http://server:55414`

- Windows VSS integration — backs up files in use

- Both file and image (full disk) backups

- Client push/pull

- Can leverage BTRFS/ZFS

Pros: strong on home and small-office Windows environments, works out of the box.

Cons: not for large enterprise, some users report database corruption.

Bottom line: a good tradeoff for SOHO Windows-centric environments.

12. Veeam Alternatives — Commercial vs Open Source

Veeam Backup and Replication is the de facto standard in VM backup. But it is expensive and lock-in-prone, so demand for alternatives is always present.

Commercial alternatives.

- **Cohesity DataProtect** — converged backup appliance, immutability, AI search

- **Rubrik** — SaaS backup with the Polaris cloud control plane

- **Commvault Cloud (Metallic)** — 30-year veteran, transitioning to SaaS

- **Druva** — 100% SaaS, edge-to-cloud

- **Acronis Cyber Protect** — backup plus cybersecurity in one

Open source / free.

- **Veeam Community Edition** — free for up to 10 VMs/machines

- **Proxmox Backup Server (PBS)** — for Proxmox VE; dedup, encryption, verification, sync

- **Vinchin Backup and Recovery** — supports VMware, KVM, Proxmox, etc.; free edition

- **Nakivo Backup and Replication** — VM-NAS-SaaS backup; free edition

**Proxmox Backup Server** has become the de facto standard for Proxmox VE clusters. Dedup, incremental, verification, sync — all for free without separate licensing.

Bottom line: PBS for Proxmox, Veeam CE or paid Veeam for VMware, Vinchin/Nakivo for multi-hypervisor.

13. Cloud-Native Backup — AWS, Azure, GCP

**AWS Backup** — unified backup for EBS, EFS, RDS, DynamoDB, FSx, EC2 AMIs, S3, Aurora, Neptune. Policy-based with vault-lock for immutability.

**Azure Backup** — VM, SQL, SAP HANA, Files, Blobs. Recovery Services Vault.

**Google Cloud Backup and DR** — Actifio-based, application-aware backup.

Vendor-managed, so operational overhead is low — but **lock-in** is the inherent downside. Multicloud users get more portability from cross-cloud OSS (Restic + multiple backends).

**Tarsnap** (Colin Percival, 2008) — "online backups for the truly paranoid". Strong client-side encryption, dedup, priced at $0.25/GB/month (compressed, deduped). The headline price looks high, but after dedup the actual bill is often very small. Popular with security-conscious individuals and small businesses.

**Backblaze B2** — $6/TB/month, S3-compatible API. Often combined with Restic and rclone.

**Backblaze Personal** — $9/month unlimited (Mac/Win desktops). The non-technical alternative.

**Wasabi** — S3-compatible, $6.99/TB/month, free egress (with a fair-use policy). A cold-storage candidate.

**Storj** — decentralized S3-compatible, $4/TB/month. Data is erasure-coded across many nodes.

14. LTO Tape — Cold Storage That Refuses to Die

Tape is not dead. In fact, in 2026 it leads the field in GB/$ for cold and archive workloads.

| --- | --- | --- | --- |

| LTO-7 | 6 TB | 15 TB | 2015 |

| LTO-8 | 12 TB | 30 TB | 2017 |

| LTO-9 | 18 TB | 45 TB | 2021 |

| LTO-10 | 36 TB | 90 TB | 2025 |

LTO-9 raw capacity is sometimes quoted as 24 TB in some vendor whitepapers, but the standard native (uncompressed) capacity of an LTO-9 cartridge as of 2026 is **18 TB**. LTO-10 launched in 2024-2025 at 36 TB raw.

Pros: 30-year archive life, inherent air gap, lowest GB/$, zero power when shelved.

Cons: expensive drives (LTO-10 drives cost thousands), slow random access, operational overhead.

Bottom line: under 50 TB, cloud cold storage is reasonable. Over 500 TB long-term archive, tape still wins.

15. Database Backup — pgBackRest, WAL-G, Percona XtraBackup

Database backup is a **different problem** from file backup. Just copying the data directory of a running database gives an inconsistent snapshot.

PostgreSQL.

- **pgBackRest** — differential/parallel/incremental, S3-compatible storage, encryption, async archiving

- **Barman** — Postgres backup/PITR manager, streaming or file-based

- **WAL-G** — multi-DB (Postgres, MySQL, MongoDB), cloud-native

MySQL/MariaDB.

- **Percona XtraBackup** — hot, non-blocking, InnoDB-friendly

- **mysqldump** — logical backup, suitable for small DBs

- **MariaBackup** — MariaDB fork of XtraBackup

- **WAL-G** (using mysqlbinlog)

MongoDB.

- **mongodump** — logical backup

- **mongoshake** — replica-set-based

- **Percona Backup for MongoDB** — consistent distributed backups

Redis.

- **RDB snapshot** plus **AOF append-only file**

- Use a replica node as a backup target

Bottom line: DB backups must be **PITR-capable** (point-in-time recovery). The pattern is "last full plus WAL/binlog archive since" giving you any point in between. A plain `pg_dump` is only enough for very small databases.

16. Kubernetes Backup — Velero, Kasten K10

Kubernetes workload backup is another dimension. Manifests (YAML state), PVs (data), and cross-cluster migration all matter.

- **Velero** (CNCF, VMware Tanzu) — the de facto K8s backup standard. CRDs, PV snapshots, S3 backend, CSI snapshot integration.

- **Kasten K10** (Veeam-owned) — enterprise K8s backup with GUI, RBAC, multi-tenancy

- **CloudCasa by Catalogic** — SaaS K8s-only backup

- **TrilioVault for Kubernetes** — application-consistent backup

- **Stash by AppsCode** — k8s-native with the operator pattern

Velero basics.

Install

velero install \

--provider aws \

--bucket my-velero-bucket \

--secret-file ./credentials-velero \

--backup-location-config region=us-east-1

Backup

velero backup create my-backup --include-namespaces=production

Restore

velero restore create --from-backup my-backup

Schedule

velero schedule create daily --schedule="0 2 * * *" --include-namespaces=production

Bottom line: for K8s operators Velero is near-essential. For enterprise environments needing GUI, RBAC, multi-tenancy, Kasten K10.

17. OS-Level Snapshots — ZFS, Btrfs, LVM, APFS, Time Machine

Filesystem-level snapshots are the fastest, most consistent foundation for backups. But **snapshots are not backups** — if they live on the same disk and that disk dies, they die together. Think of snapshots as the **starting point** for backups.

**ZFS**.

Snapshot

zfs snapshot tank/data@2026-05-16

List

zfs list -t snapshot

Send (replicate to another pool)

zfs send tank/data@2026-05-16 | ssh backup-host zfs recv backup/data

**Btrfs**.

Snapshot

btrfs subvolume snapshot -r /data /data/.snapshots/2026-05-16

Send

btrfs send /data/.snapshots/2026-05-16 | ssh backup-host btrfs receive /backup/

**LVM**.

lvcreate --snapshot --size 10G --name data-snap-2026-05-16 /dev/vg0/data

**APFS (macOS)** — Time Machine relies on APFS local snapshots for hourly point-in-time restore. macOS 11+ takes them automatically every hour.

**TrueNAS Scale 24.04**, **OpenMediaVault** — NAS OSes that wrap ZFS snapshots and replication in a UI.

**Synology Hyper Backup** (DSM 7.2), **QNAP HBS 3** — integrated backup solutions for home NAS that fan out to multiple destinations (other NAS, cloud, USB external) simultaneously.

Bottom line: filesystem snapshots are unbeatable for "roll back to yesterday in 1 second". They are useless against full disk loss. **Snapshots plus external backups** is what a real backup looks like.

18. Encryption and Key Management — Lose the Key, Lose the Game

The single most important decision in backup encryption is **where to store the key**.

- Key alongside backup → not really encryption (attacker takes both)

- Lose the key → you have lost the backup too

Options.

1. **Passphrase-based** — KDF (scrypt, argon2) derives the key. Default for Restic and Borg.

2. **Public-key-based** — encrypt with the receiver's public key; private key stored separately. `age`, experimental `restic --pubkey`.

3. **External key manager** — HashiCorp Vault, AWS KMS, GCP KMS, 1Password Connect, Bitwarden Secrets Manager.

4. **Yubikey + KDF** — hardware token based.

Principles.

- **Write the passphrase on paper and store it in a separate safe** — relying on a single password manager is risky

- **Back up the keys for your 3-copy backup too** — the key manager itself needs a backup strategy

- **Algorithms** — AES-256-GCM or ChaCha20-Poly1305 are the 2026 norm

- **Post-quantum?** — not a top priority yet for backups, but worth reviewing for long-term archives (20-30 years)

Bottom line: key management can be the single point of failure for the entire backup system. **Lose the passphrase = lose the data** — any backup design that does not take this seriously is incomplete.

19. Verification and Restore Drills — The Real Value of Backups

**A backup you have never restored is not a backup.** This one line must never be forgotten.

Verification steps.

1. **Checksum verification** — per-tool commands

- Restic: `restic check --read-data-subset=10%`

- Borg: `borg check --verify-data`

- Kopia: `kopia content verify`

2. **Sample restore** — restore a few random files and compare hashes

3. **Full restore drill** — quarterly, restore to a clean environment

4. **Disaster simulation** — game day: "assume the DB is gone, restore in one hour"

**Monitoring**.

- Backup success/failure alerts (Slack, Discord, PagerDuty, healthchecks.io)

- Backup size trend (sudden 0 is an incident)

- Last backup timestamp (alert if older than 24 hours)

- Verification results (monthly automated)

**healthchecks.io** — the "your backup should ping me daily" pattern. No ping triggers an alert. The simplest dead-man-switch via cron plus curl.

Bottom line: a backup that fails early is lucky. A backup that fails late is a disaster. A good backup system is one that finds out as early as possible.

20. Self-Hosting in Korea and Japan — A NAS-Centric Culture

Korea and Japan have unusually high home-NAS adoption. Synology, QNAP, Buffalo, and ASUSTOR are well established.

**Korean scenario**.

- Home Synology DS923+ plus external USB plus Synology C2 / B2 cloud sync

- Container-leaning self-hosters: Proxmox plus ZFS plus Restic to B2

- Photo/video: PhotoSync plus Synology Photos plus Glacier Deep Archive

**Japanese scenario**.

- Strong Buffalo TeraStation presence (enterprise NAS)

- Synology and QNAP popular at home

- Local Japanese clouds like Nifty Cloud and Sakura Internet as backends

**Common pattern**: home NAS to cloud sync (B2, Wasabi, S3), plus a quarterly external-disk copy stored in a safe. This is the most common real-world implementation of the 3-2-1 rule.

Bottom line: a NAS is single media. Even with RAID 5/6 it is not a backup by itself. RAID is for availability; backup must be separate.

21. Common Pitfalls — Skip Them and It Is Not a Backup

In 2026, ninety percent of repeating backup incidents come from one of these traps.

1. **No restore tests** — most common, most catastrophic. Quarterly minimum, no excuses.

2. **Single medium** — only one NAS, or only one cloud. Ignoring 3-2-1.

3. **No encryption** — full exposure on theft or loss. For cloud backends, client-side encryption is mandatory.

4. **No monitoring** — the "discovered six months later that yesterday's backup failed" pattern.

5. **Lost passphrase** — single-managed key. Paper backup needed.

6. **Permission errors** — running without `sudo`, so files are silently missed. Use dry-run plus permission checks.

7. **Backing up a DB as files** — tarring up a running DB's data directory gives an inconsistent set. Use `pg_dump` or pgBackRest.

8. **No ransomware defense** — if the backup server is reachable from clients, it gets encrypted too. Append-only or air-gapped.

9. **No retention policy** — store forever, then storage costs explode or GDPR retention limits are violated.

10. **Cloud-only backup** — get hacked out of your cloud account and you are done. You also need a local backup of cloud data.

Bottom line: hit five or more of these and your backup system needs to be redesigned from scratch.

22. Decision Matrix — What Should Your Team Use?

| Scenario | First choice | Second choice |

| --- | --- | --- |

| Personal laptop (Mac) | Time Machine plus Kopia/Restic to B2 | Backblaze Personal |

| Personal laptop (Linux) | Restic to B2/Wasabi | Borg plus rsync.net |

| Home NAS | Synology Hyper Backup to cloud | rclone plus B2 |

| Self-hosting 1-5 hosts | Borg/Restic plus SSH backend | Kopia plus S3 |

| Self-hosting 5-50 hosts | Restic plus central REST server | Bareos |

| Enterprise 100+ hosts | Bareos plus tape | Commvault/Veeam |

| K8s cluster | Velero plus S3 | Kasten K10 |

| Postgres production | pgBackRest plus WAL archive | Barman |

| MySQL production | Percona XtraBackup plus binlog | WAL-G |

| VM backup (Proxmox) | Proxmox Backup Server | Vinchin |

| VM backup (VMware) | Veeam (paid) or CE | Vinchin/Nakivo |

| Photo/video (family) | Synology Photos plus Glacier Deep Archive | iCloud plus external |

| Long-term archive (10+ years) | LTO tape plus offsite | Glacier Deep Archive |

23. Cost — Converted to Per-GB

Approximate prices as of May 2026 (USD/TB/month).

| Option | Price (USD/TB/month) | Notes |

| --- | --- | --- |

| Backblaze B2 (hot) | $6 | egress $10/TB |

| Wasabi (hot) | $7 | free egress (fair use) |

| Storj | $4 | decentralized, egress separate |

| AWS S3 Standard | $23 | most expensive hot |

| AWS S3 Glacier Instant | $4 | retrieval $10/TB |

| AWS S3 Glacier Deep Archive | $1 | retrieval 12-48h |

| Azure Blob Cool | $10 | |

| Azure Blob Archive | $1 | rehydrate time required |

| GCP Coldline | $4 | 90-day minimum |

| GCP Archive | $1.2 | 365-day minimum |

| Home NAS (amortized) | $1-3 | 4-bay NAS plus HDDs |

| LTO-9 (amortized) | $0.3 | 18 TB cartridge, at volume |

Bottom line: under 1 TB, Backblaze Personal at $9/month unlimited is the cheapest. 10-100 TB range — B2/Wasabi/Storj make sense. 100 TB+ long-term archive — Glacier Deep Archive or LTO.

24. Future — 2026 Backup Trends

- **Immutability everywhere** — Object Lock, immutable snapshots, WORM, becoming a default option for every backend.

- **AI/ML integration** — automatic PII detection in backup data, anomaly detection to flag ransomware early.

- **K8s backup mainstreaming** — Velero is becoming standardized, multi-cluster and multi-cloud restore.

- **Decentralized storage** — Storj, Sia and similar P2P/decentralized storage expand from niche to common.

- **Post-quantum on the radar** — some tools begin reviewing it for long-term archives, gradual adoption.

- **Backup as data governance** — GDPR, CCPA, PII detection becoming a built-in feature.

- **Edge backup** — IoT and edge-K8s backup becoming its own category.

Bottom line: backup in the 2020s is far more than copying files — it is evolving into a unified platform for data protection, disaster recovery, and compliance.

25. Conclusion — Boring But the Most Important Thing

Backups really are boring. When they work, no one cares. When they fail, everyone is angry. The reward is asymmetric.

Yet backups are **the conscience of an infrastructure**. Teams that run backups well also run other operations well. Teams whose backups are a mess soon have other incidents too. A backup system is a measure of a team's diligence.

If you have read this far, do exactly one thing today.

**Restore the most recent backup of your most important data — actually restore it.**

If it works, good. If it does not, today is the luckiest day of your life — you found out before it mattered.

Appendix · References (real URLs)

1. Restic — https://restic.net/

2. Restic Documentation — https://restic.readthedocs.io/

3. BorgBackup — https://www.borgbackup.org/

4. Borgmatic — https://torsion.org/borgmatic/

5. Kopia — https://kopia.io/

6. Duplicati — https://www.duplicati.com/

7. rclone — https://rclone.org/

8. rsnapshot — https://rsnapshot.org/

9. Bacula — https://www.bacula.org/

10. Bareos — https://www.bareos.com/

11. Amanda — http://www.amanda.org/

12. UrBackup — https://www.urbackup.org/

13. Velero — https://velero.io/

14. Kasten K10 — https://www.kasten.io/

15. pgBackRest — https://pgbackrest.org/

16. Barman — https://pgbarman.org/

17. WAL-G — https://github.com/wal-g/wal-g

18. Percona XtraBackup — https://www.percona.com/software/mysql-database/percona-xtrabackup

19. Proxmox Backup Server — https://www.proxmox.com/en/proxmox-backup-server

20. Backblaze B2 — https://www.backblaze.com/cloud-storage

21. Wasabi — https://wasabi.com/

22. Storj — https://www.storj.io/

23. Tarsnap — https://www.tarsnap.com/

24. LTO Ultrium — https://www.lto.org/

25. healthchecks.io — https://healthchecks.io/

26. Veeam Community Edition — https://www.veeam.com/virtual-machine-backup-solution-free.html

27. Synology — https://www.synology.com/

28. QNAP — https://www.qnap.com/

29. TrueNAS — https://www.truenas.com/

30. 3-2-1 Backup Rule (CISA) — https://www.cisa.gov/news-events/news/data-backup-options