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 backups for Linux server. The main difference wey go decide your choice na where the backup dey land. Restic dey support S3 and other object storage APIs natively, so bucket fit be direct target without installing anything for the other end. Borg need the borg program installed for the machine wey dey hold the repository, because Borg repository dey run through a process, no be filesystem or API. If your target na object storage, that one don already answer the question. If your target na another Linux box wey you control, Borg fit work and e often dey faster.

Every other difference smaller. Both dey split files with content-defined chunking, so if 40 GB directory change by 200 MB, e go upload roughly 200 MB. Both dey encrypt for the client side. Both fit mount snapshot with FUSE (filesystem in userspace), so you fit copy one file comot. As of July 2026, restic dey version 0.19.1 and Borg stable series na 1.4, specifically 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.

Na repository model na the real difference

A restic repository na directory wey get files: config, keys/, snapshots/, index/, and data/ full of pack files. You no need anything else 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 so one binary fit 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 simple transport. For remote repository, Borg dey start borg serve for the other side through SSH, then e dey use im own protocol talk to that process. The server side dey do real work: e dey hold the repository, apply the transaction, and answer index questions. Na why Borg no get S3 backend and why the project never add one. No process dey wey you fit run inside bucket.

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 turn off

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

Borg dey make encryption a choice when you create repository, and that choice permanent. borg init --encryption=repokey dey keep the encrypted key inside the repository, so passphrase alone fit restore am. --encryption=keyfile dey 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. Each mode get a -blake2 variant wey authenticates with BLAKE2b instead of HMAC-SHA256, and e faster for hardware wey no get SHA acceleration. --encryption=none still dey available, and e be real choice 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 get am late

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

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 fit set compression with --compression to values auto, off or max. Old format 1 repository go remain uncompressed until you migrate am. So if your restic repository old pass 0.14 and you never migrate am, you still dey use full size for text, logs and database dumps.

Remote targets: S3 vs SSH

Na here choice dey usually happen.

Restic fit reach S3 when credentials dey for the environment, and nothing else need dey run anywhere. The same pattern work with bucket wey you host by yourself. Na common pairing be this: 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 plus Borg installation for the remote side before e fit reach remote repository. The version for that side must also compatible with the client. This fit cause problem if you no own the remote side. But e no be problem if na second server wey you already dey administer. E also give you the strongest ransomware protection wey either tool 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 only when you run its own REST server, because e 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 you must protect the SSH side like any other login. Apply key only SSH with restricted authorized_keys entry to the backup account.

Speed: wetin each design mean

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

Borg over SSH dey fast for link wey get latency because the server side dey intelligent. The client dey ask question, the remote borg serve process dey answer am from the repository index, and the transaction dey commit for one place. Chunk lookups no dey 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 through HTTP. To keep the number of requests reasonable, e dey pack many small chunks inside bigger pack files before e upload dem, and e dey keep local cache for ~/.cache/restic so the next run no go fetch the whole index again. If you delete that cache, the next backup go slow while e dey rebuild am. For high latency link with millions of small files, na this situation make restic feel slower than Borg with the same data.

For local disk or fast LAN, the difference mostly dey close, and both tools eventually dey limited by 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 for the whole operation. Two clients wey dey write to one repository for the same time no go work: the second one go wait, then e go fail with lock timeout. The supported pattern na one repository for each client. This one mean say deduplication only dey happen inside one machine repository, so ten servers wey nearly identical be dey store ten copies of the same base system.

Restic allow several clients to back up into one repository for 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 fit store very little. The cost na bigger blast radius: one password and one repository wey hold everything, so if password loss, all ten go loss.

Retention: forget plus prune, versus prune plus compact

Both tools 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 plain. 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 prunes but never compacts go leave repository wey dey grow forever while archive list remain short. For restic, forget without --prune only drops snapshot references, and the data go remain until prune runs.

Run restic check after pruning. E dey verify the repository structures and tell you if anything don damage, wey better pass to discover am during restore.

Restore, na im be the only test wey count

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

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

Take note of the path format for borg extract. Paths inside archive dey store without the leading slash, so etc/nginx correct, while /etc/nginx no match anything and e extract nothing, without any error to show you why. Extraction too dey write inside the current working directory, so first change enter a scratch directory. Otherwise, you fit overwrite live files with old ones.

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

Which one wins for which job

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

Pick Borg if your target na Linux box wey you control, if the connection get latency and the dataset get millions of small files, if you want the append only SSH key as protection against ransomware, or if you want compression wey you fit tune for each job. Na the older tool e be, e stable series dey change slowly, and for backup software, na feature be that.

Both answers correct. The wrong answer na the one wey you never test. If you already dey take application level dumps, keep them: the pattern for the Nextcloud on Docker setup with database dumps apply to both tools, because copying a live database file at random time no be backup of a database.

FAQ

Restic abi BorgBackup dey faster?

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

BorgBackup fit back up to S3 or Backblaze B2?

No be directly. One borg serve process dey serve Borg repository over SSH, and no such process dey run inside bucket. People dey work around am by mounting object storage as filesystem with rclone, but Borg project no recommend am, because mount wey drop halfway through transaction fit corrupt the repository. If you need object storage, use restic.

I fit run both tools against the same data?

Yes, and some people dey do am: Borg to second server for fast local restore, restic to object storage for offsite copy. Dem no share anything, so you go pay read and hash cost twice, and you get two passwords to 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 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, but for keyfile mode you still need key file from ~/.config/borg/keys/. Keep password inside password manager wey no dey live on the server wey you dey back up, and export Borg key with borg key export if you dey use keyfile.

I suppose wait for Borg 2.0?

No. As of July 2026, Borg 2.0 still dey beta, for 2.0.0b22, and the project label am as testing only. The stable series na 1.4, currently 1.4.5. Start with 1.4 now. Borg 2 changes repository format and ships documented upgrade path, so if you start today, you no go get stranded.