Restic vs BorgBackup
Restic and BorgBackup (Borg) compared for encrypted, deduplicated server and workstation backups: storage backends (S3, B2, SFTP, SSH), encryption, compression, Windows support, append-only setups, pruning and the state of Borg 2 in 2026.
Quick Answer
Restic is the better default when backups go to object storage or you need Windows: one Go binary that writes directly to S3, B2, Azure, Google Cloud Storage, SFTP, its REST server or anything rclone reaches, with VSS snapshots on Windows. BorgBackup 1.4 is the pick for Linux and BSD servers backing up to a disk or an SSH host running Borg, with a choice of compressors (lz4, zstd, zlib, lzma) and mature tooling; its object-storage support only arrives with Borg 2, which is still beta and not for production.
Last updated October 22, 2026. Covers restic 0.19.1 (5 July 2026) and BorgBackup 1.4.5 (19 July 2026), with restic's current backend list and Borg 2's beta status as stated in its docs in October 2026.
| Feature | Restic | BorgBackup |
|---|---|---|
| Price | Free | Free |
| Licence | BSD-2-Clause | BSD-3-Clause |
| Distribution | Single Go binary | Python 3.10+ (C/Cython core); single-file binaries for Linux, macOS, FreeBSD |
| Platforms | Linux, BSD, macOS, Windows | Linux, macOS, FreeBSD, OpenBSD, NetBSD; Windows only via experimental WSL/Cygwin |
| Storage Backends | Local, SFTP, REST Server, S3 and S3-compatible, Swift, B2, Azure Blob, GCS, rclone | Local paths and ssh:// (Borg on the remote host); cloud backends only in beta Borg 2 |
| Encryption | Always on: AES-256-CTR + Poly1305-AES, scrypt KDF | Optional: repokey/keyfile (AES-CTR-256 + HMAC-SHA256 or BLAKE2b), authenticated-only, or none |
| Compression | auto / max / off (repo format v2, restic 0.14+) | lz4, zstd, zlib, lzma |
| Append-Only / Ransomware-Resistant Mode | Yes, via rest-server --append-only | Yes, borg serve --append-only |
| Mount Snapshots (FUSE) | Yes (restic mount) | Yes (borg mount, FUSE) |
| Verify Backup Data | Yes, check --read-data / --read-data-subset | Yes, borg check (repository and archive checks) |
| Windows VSS Snapshots | Yes (--use-fs-snapshot) | No (no native Windows support) |
| Latest Stable Release | 0.19.1 (5 Jul 2026) | 1.4.5 (19 Jul 2026) |
Restic
Open-source backup program written in Go, shipped as a single executable, that stores encrypted, deduplicated snapshots in a repository on local disk, SFTP, its own REST server or cloud object storage.
Pros
- Writes directly to many backends: local, SFTP, REST Server, Amazon S3 and S3-compatible (MinIO, Wasabi, Alibaba OSS), OpenStack Swift, Backblaze B2, Azure Blob, Google Cloud Storage, and anything rclone supports
- Runs natively on Linux, BSD, macOS and Windows, with Windows VSS support via --use-fs-snapshot
- Single executable, no server-side component needed for cloud or SFTP targets
- Append-only backups through rest-server --append-only, which allows new backups but blocks deletion and modification
- restic check --read-data / --read-data-subset verifies pack contents, and restic copy moves snapshots between repositories
- Every repository is encrypted: AES-256 in counter mode with Poly1305-AES authentication, keys derived with scrypt
Cons
- Compression has only three settings (auto, max, off) and needs repository format version 2 (restic 0.14+)
- Encryption cannot be turned off, which some users backing up to trusted local disks do not need
- Still on a 0.x version line (0.19.1)
- Pruning large cloud repositories means downloading and rewriting packs, which costs time and egress on object storage
Best For
Backups to S3, B2 or other object storage, mixed Linux/macOS/Windows fleets, and anyone who wants one binary and no software on the storage side.
BorgBackup
Deduplicating backup program (Python with C/Cython hot paths) that uses content-defined chunking, optional client-side authenticated encryption and selectable compression, storing archives in local repositories or on remote hosts over SSH.
Pros
- Choice of compressors per backup: lz4, zstd, zlib and lzma, trading speed against ratio
- Flexible encryption modes: repokey or keyfile with AES-CTR-256 and HMAC-SHA256 or BLAKE2b, plus authenticated-only modes when you don't want encryption
- borg serve --restrict-to-path and --append-only lock a client's SSH key to its own repository and append-only writes
- Performance-critical chunking, compression and encryption in C/Cython, with local index caching and fast detection of unchanged files
- Mountable archives via FUSE (borg mount) for browsing and restoring
- Mature 1.x line with BSD-3-Clause licence and single-file binaries for Linux, macOS and FreeBSD
Cons
- Borg 1.4 repositories are local paths or ssh:// hosts only; there is no native S3, B2 or cloud backend
- Windows is not directly supported: WSL and Cygwin are described as experimental, and FUSE does not work under WSL
- Remote backups work best with Borg installed on the server, so plain object storage or a bare NAS share is a poor fit
- Borg 2 (with sftp, S3, B2 and rclone backends) is still beta and its docs say not to use it for production backups
- Freeing space after prune or delete needs a separate borg compact run
Best For
Linux and BSD servers backing up to a local disk or an SSH host with Borg installed, where you want tunable compression, flexible encryption modes and restricted, append-only SSH access.
Where the backups can go
This is the deciding factor for most people. Restic's repository docs list local paths, SFTP, its own REST Server, Amazon S3, MinIO and other S3-compatible services (Wasabi, Alibaba Cloud OSS), OpenStack Swift, Backblaze B2, Microsoft Azure Blob Storage, Google Cloud Storage, and any other service through rclone. Restic talks to these directly from the client; nothing runs on the storage side unless you choose rest-server. BorgBackup 1.4 accepts local filesystem paths and SSH URLs (ssh://user@host:port/path, plus the deprecated scp-style form). Its feature list says Borg can store backups on any remote host reachable over SSH and that installing Borg on the remote host improves performance; in practice that means a VPS, a NAS with SSH and Borg, or a storage service that provides Borg over SSH. There is no S3 or B2 backend in 1.4. Borg 2's development docs list sftp://, s3://, b2:// and rclone: remotes, which would close most of this gap. But the same docs say Borg2 is in beta, may get breaking changes between betas, and in bold: do not use Borg2 for production backups. As of October 2026 the stable line is 1.4.5. If the target is object storage, restic is the straightforward choice. If it is a disk or another Linux box you control, both work.
Encryption, compression and integrity checks
Restic encrypts everything, always. Its design reference says all repository data is encrypted with AES-256 in counter mode and authenticated with Poly1305-AES, with keys derived from your password using scrypt. You cannot create an unencrypted repository. Compression arrived with repository format version 2 (restic 0.14.0 and newer, now the default) and exposes three modes: auto (the default, very fast), max (better ratio for more CPU) and off. Borg makes both optional and configurable. borg init offers repokey and keyfile modes using AES-CTR-256 with HMAC-SHA256 or BLAKE2b, authenticated-only modes that sign but do not encrypt, and none. The docs recommend repokey with a strong passphrase, and the BLAKE2b variants on CPUs without hardware SHA-256. Keyfile mode keeps the key off the repository, but you must export a backup of it with borg key export or lose access. Compression is chosen per backup from lz4, zstd, zlib and lzma. For verification, restic check can also read and verify pack data with --read-data, or a slice of it at a time with --read-data-subset, which is useful on large cloud repositories where a full read is slow and costs egress. Borg's check command verifies repository and archive consistency. Both can mount snapshots as a filesystem (restic mount, borg mount over FUSE) to browse and restore individual files.
Ransomware resistance and access control
A backup client that holds delete rights can be used by an attacker to delete its own backups. Both tools have an answer, in different places. Restic's rest-server has an --append-only mode that, per its README, allows creating new backups but prevents deletion and modification of existing ones. Pair it with --private-repos so each user can reach only the repository matching their username. Pruning then has to run from a trusted machine with full access. Borg puts the control on the SSH side. In the server's authorized_keys you force each client's key to run borg serve with --restrict-to-path, limiting it to its own repository directory, and optionally --append-only. Borg's own docs note that append-only only restricts the low-level repository structure: delete and prune still run, but they only tag data as deleted in a new transaction, and an administrator can roll the repository back to an earlier transaction as long as borg compact has not run since. With restic on direct S3 or B2, the equivalent is storage-side: object lock or versioning plus credentials that cannot delete. That is a bucket policy outside restic, so plan it when you set up the bucket.
Platforms, packaging and day-to-day operation
Restic is one Go executable for Linux, BSD, macOS and Windows. On Windows, backup --use-fs-snapshot uses the Volume Shadow Copy Service so files locked by other processes are still captured, with vss.* options for tuning. For database dumps, --stdin-from-command aborts the backup if the dump command fails, which is safer than piping into --stdin. Restic's tuning docs list a default pack size of 16 MiB and five connections per backend, adjustable for fast links. The latest release is 0.19.1 (5 July 2026), a bug-fix release. Borg needs Python 3.10 or newer when installed from source, and its project publishes single-file PyInstaller binaries for x86-64 Linux, macOS and FreeBSD; ARM binaries come from a third party. OpenBSD and NetBSD have packages without xattr/ACL support. Windows support is limited to WSL and Cygwin, both marked experimental, and FUSE mounting does not work under WSL. The current stable release is 1.4.5, which the changelog dates 19 July 2026 and which included a low-severity security fix. One operational gotcha in Borg: deleting or pruning archives does not free space until you run borg compact, so add it to your retention job. Restic's forget --prune does removal and repacking in one step, at the cost of rewriting packs on the backend.
Verdict
Choose restic if your backups go to S3, Backblaze B2, Azure, Google Cloud Storage or any rclone remote, if you back up Windows machines, or if you want one binary with nothing to install on the storage side; put rest-server in --append-only mode in front of it if you need ransomware-resistant backups. Choose BorgBackup 1.4 if you back up Linux or BSD servers to a local disk or to an SSH host where you can install Borg, and you want lz4/zstd/lzma compression choices, optional encryption and borg serve's restricted, append-only SSH keys. Do not pick Borg 2 for production yet: its own docs say it is beta and may change incompatibly. Both are free, both deduplicate and both can mount snapshots for restores.