Open Source Backup Tools 2026 — A Deep Dive into Restic, BorgBackup, Kopia, Duplicati, Rclone, Bacula, Amanda, and Veeam Alternatives

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.

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-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?

23. Cost — Converted to Per-GB

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

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