Restic vs BorgBackup: Which One You Go Run?

Restic vs BorgBackup, for one paragraph

Restic and BorgBackup dey do the same main work: deduplicated, encrypted, incremental backup for Linux server. The main difference wey decide the choice na where the backup go land. Restic natively dey support S3 and other object storage APIs, so bucket na direct target and you no need install anything for the other side. Stable Borg need the borg program installed for the machine wey dey hold the repository, because Borg repository dey run through process, no be filesystem or API. If your target na object storage, that one don answer the question. If your target na another Linux box wey you control, Borg dey available and e often faster.

Every other difference smaller. Both split files with content-defined chunking, so if 40 GB directory change by 200 MB, upload go roughly be 200 MB. Both encrypt data for the client side. Both mount snapshot with FUSE (filesystem in userspace), so you fit copy one file comot. As of October 2026, restic dey version 0.19.1, while Borg stable series na 1.4, currently 1.4.5. Borg 2.0 don dey beta for years and dem still mark am as testing only, so na 1.4 you suppose deploy today.

Repository model na the real difference

A restic repository na directory of files: config, keys/, snapshots/, index/, and data/ wey full of pack files. Nothing else dey needed to read am. Na why restic fit work with plenty backends. Any store wey fit put, get, list, and delete blobs fit hold restic repository. Na this make one binary support local paths, SFTP, im own REST server, S3, Backblaze B2, Azure, Google Cloud Storage, and anything wey rclone fit reach.

Borg repository too na files for disk, but Borg no dey talk to am through dumb transport. For remote repository, Borg go start borg serve for the other side through SSH, then e go use im own protocol talk to that process. The server side dey do real work: e hold the repository, apply the transaction, and answer index questions. Na why stable Borg 1.4 series no get S3 backend. No process dey wey fit run inside bucket. Borg 2 change this: e move storage enter new layer wey dem call borgstore, and im documentation describe sftp://, rclone:remote:path and s3: or b2: repository URLs. But Borg 2 still be beta wey the project say make people no use for production, so for real backups today, the S3 gap still dey.

Na this one design fact dey cause most of the practical differences wey follow.

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

Encryption: one of dem fit off

Restic dey always encrypted. E no get unencrypted mode. restic init go ask for password, use scrypt derive key from am, and every pack file wey e write after that go dey encrypted and authenticated. If you lose the password, the data don go, because recovery path no dey by design.

Borg make encryption be choice when you create repository, and you no fit change the choice later. borg init --encryption=repokey keep the encrypted key inside repository, so passphrase alone fit restore am. --encryption=keyfile keep the key for client inside ~/.config/borg/keys/, so person wey steal the complete repository still no get anything, and you must back up that key file separately or your archives no go readable. Every mode get -blake2 variant wey authenticate with BLAKE2b instead of HMAC-SHA256, and e dey faster for hardware wey no get SHA acceleration. --encryption=none dey available too, and e make sense when repository dey on encrypted disk wey you own.

The practical rule be: use repokey-blake2 for normal server backup, use keyfile when repository dey somewhere wey you no fully trust, and never use none for rented machine.

Compression, and why restic add am late

Borg don get compression since the beginning. The default na lz4, because e fast enough make you leave am on for everything. zstd accept levels 1 to 22 and e default to 3, zlib and lzma dey for cases where bytes matter pass time, while auto run heuristic for every chunk so data wey don already get compression no go compress twice.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

Restic no get compression at all until repository format 2, wey need restic 0.14.0 or newer. Format 2 na the default for new repository now, and you set compression with --compression using one of five values: auto (the default), off, fastest, better or max. fastest and better modes enter for restic 0.19.0, so older binaries only accept auto, off and max. Old format 1 repository go remain without compression until you migrate am. So if your restic repository old pass 0.14 and you never migrate am, you still dey pay full size for text, logs and database dumps.

Remote targets: S3 versus SSH

Na here people usually make the choice.

Restic fit reach S3 with credentials for the environment, and nothing else need dey run anywhere. The same setup work with bucket wey you host by yourself. This na common pairing: run MinIO for S3 API for your own VPS and point restic to am.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

Borg need SSH to reach remote repository, plus Borg installation for the other side. The version for there must also compatible with the client. This fit cause wahala if you no own the other side. But e no be problem if na second server wey you already dey administer. E also give you the strongest protection against ransomware wey either tool fit offer: an append only SSH key. Force the key to run borg serve. Then the client fit add archives but e no fit delete dem. So if machine get breached, e no fit wipe its own history.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

Restic get equivalent option only when you run its own REST server, and that server support append only mode. With plain S3, bucket policy or object lock fit give you the same result. Na the provider dey handle that, no be restic. Lock down the transport too, because SSH side need the same care like any other login: apply key only SSH with restricted authorized_keys entry to the backup account.

Speed: wetin each design mean

Neither project publish benchmark wey you suppose trust for your own data, so reason from how each one work instead.

Borg over SSH dey fast for connection wey get latency because the server side dey smart. The client ask question, the remote borg serve process answer am from the repository index, and the transaction commit for one place. Chunk lookups no turn into network round trips for every small file.

Restic for object storage no get server side, so e must build the picture from index files and pack files wey e fetch over HTTP. To keep request count reasonable, e pack plenty small chunks inside bigger pack files before e upload dem, and e keep local cache for ~/.cache/restic so the next run no need fetch the whole index again. If you delete that cache, the next backup go slow while e rebuild am. For high-latency connection with millions of small files, na this situation make restic feel slower than Borg for the same data.

For local disk or fast LAN, the difference mostly go close, and both tools go eventually depend on how fast dem fit read and hash the source.

Locking, and backing up several machines

Borg 1.4 dey take exclusive lock for the repository throughout the whole operation. Two clients wey dey write to one repository at the same time no go work: the second one go wait, then fail when lock timeout happen. The supported pattern na one repository for each client. This also mean say deduplication only dey happen inside one machine repository, so ten servers wey nearly dey identical go store ten copies of the same base system.

Restic allow several clients to back up into one repository at the same time, because backup dey take shared lock, while only maintenance work like prune dey take exclusive lock. Ten similar servers wey point to one restic repository go deduplicate against each other, and the second server onward often go store very little. The cost na bigger blast radius: one password and one repository dey hold everything, so if password loss, all ten go loss.

Retention: forget plus prune, versus prune plus compact

Tools two dey separate “decide wetin to keep” from “reclaim the space”, and both make you run the second step.

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

The trap na the same for both tools, and e good make we talk am plainly. For Borg, borg prune removes archives but e no free disk space by itself. Space go come back when borg compact runs. So, cron job wey dey prune but e never compact go leave repository wey dey grow forever, even though archive list short. For restic, forget without --prune only removes snapshot references. The data go remain until prune runs.

Run restic check after pruning. E go verify the repository structures and tell you if anything don damage. This better pass to discover the problem during restore.

Restore, naim dey count

Both tools fit mount snapshot make you browse am. Na the fastest way to bring back one file.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

Notice the path format for borg extract. Paths inside archive dey stored without the slash for front, so etc/nginx correct, while /etc/nginx no match anything and extract nothing. E no go show error to tell you why. Extraction still writes into the current working directory, so first change go scratch directory. Otherwise, old files fit overwrite live files.

Restore wey finish without error still no prove say everything correct. Application wey dey on top get its own meaning of complete restore. For example, Immich server wey you rebuild from copy of the Postgres data directory fit get every photo for disk, but timeline still show nothing. Na the problem backing up and restoring Immich suppose handle.

Any tool wey you choose, schedule na only half of the work. Run restore into scratch directory with timer wey you dey really monitor. Do am the same way the full walkthrough for the restic backup guide for a VPS dey do am with systemd timer.

Which one fit win for which work

Choose restic when your target na object storage, when you want one binary and no software for the other side, when several machines need deduplicate against each other, or when the person wey go restore the data fit no be you. Na one static binary with a URL for repository, and operationally, e hard to beat.

Choose Borg when your target na Linux box wey you control, when the link get latency and the dataset get millions of small files, when you want append only SSH key as protection against ransomware, or when you want tune compression for each job. Na the older tool, and its stable series dey move slowly. For backup software, this na advantage.

Both answers dey correct. The wrong answer na the one wey you never test. If you already dey take application level dumps, keep dem. The pattern for the Nextcloud on Docker setup with database dumps apply to either tool, because if you copy a live database file at a random time, e no be database backup.

FAQ

restic or BorgBackup dey faster?

For local disk or fast LAN, dem dey close, and both dey limited by read and hash speed for source. Borg dey usually win for high-latency SSH link wey get plenty small files, because borg serve process for the other side fit answer index questions without network round trip for every chunk. restic dey usually win when target na object storage, where stable Borg no fit work at all.

BorgBackup fit back up to S3 or Backblaze B2?

No be with stable 1.4 series. Borg 1.4 repository dey served by borg serve process over SSH, and no such process dey run inside bucket. Borg 2 add s3:, b2: and rclone: repository URLs through its borgstore layer, but as of October 2026 Borg 2 still dey beta, and the project say make people no use am for production. With 1.4, people dey work around this gap by mounting object storage as filesystem with rclone. Borg FAQ advise against network filesystems for repository storage and warn say FUSE and network filesystems fit cause slowness or corruption. If you need object storage for production backups today, use restic.

I fit run both tools against the same data?

Yes, and some people dey do am: Borg go second server for fast local restore, restic go object storage for offsite copy. Dem no share anything, so you go pay read and hash cost twice, and you get two passwords wey you must store safely. Do this only if you don test both restores.

Wetin go happen if I lose repository password?

The data no fit recover for both tools. restic dey derive its key from password with scrypt, and no bypass dey. Borg for repokey mode dey store encrypted key inside repository, so passphrase alone fit restore am, while for keyfile mode you also need key file from ~/.config/borg/keys/. Keep password for password manager wey no dey on the server wey you dey back up, and export Borg key with borg key export if you use keyfile.

I suppose wait for Borg 2.0?

No. As of October 2026, Borg 2.0 still dey beta, for 2.0.0b25 (released 27 September 2026), and the project label am as testing only. Stable series na 1.4, currently 1.4.5. Start with 1.4 now. Borg 2 change repository format and ship documented upgrade path (borg transfer --from-borg1), so if you start today, you no go get stranded. Borg 2 na also where native S3, B2 and rclone support go arrive, once e stable.