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 suppose decide your choice na where backup go land. Restic get native support for S3 and other object storage APIs, so bucket na direct target and you no need install anything for the other side. Borg need the borg program installed for the machine wey dey hold the repository, because Borg repository dey serve through process, no be filesystem or API. If your target na object storage, answer don clear. If your target na another Linux box wey you control, Borg fit work and e often dey faster.

Every other difference small pass. Both tools dey split files with content-defined chunking, so if 40 GB directory change by 200 MB, upload go roughly 200 MB. Both dey encrypt data 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 version na 0.19.1, while 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.

Repository model na di real difference

A restic repository na directory of files: config, keys/, snapshots/, index/, and data/ wey 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 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 Borg no get S3 backend and why the project never add one. No process dey wey 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 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 take am reach am late

Borg don dey compress since 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 for cases wey bytes matter pass minutes, while auto dey run one heuristic for every chunk so data wey don already compress 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 values auto, off or max. Old format 1 repository go remain uncompressed until you migrate am. So if your restic repository older than 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 two dey almost the same, and read plus hash speed for the source na wetin limit both. Borg dey usually win for high-latency SSH link wey get plenty small files, because a borg serve process for the far side fit answer index questions without network round trip for every chunk. Restic dey usually win when na object storage be the target, because Borg no fit use am directly.

BorgBackup fit back up go S3 or Backblaze B2?

No be directly. A Borg repository na the borg serve process dey serve am through SSH, and no such process dey run inside bucket. People dey work around this by mounting object storage as filesystem with rclone, but Borg project no recommend am, because if mount drop halfway through transaction, e fit corrupt 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 go second server for fast local restore, restic go object storage for offsite copy. Dem share nothing, so you go pay read and hash cost two times, 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?

Data no fit recover for both tools. Restic dey derive e 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. For keyfile mode, you also need key file from ~/.config/borg/keys/. Keep password inside 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 July 2026, Borg 2.0 still dey beta, for 2.0.0b22, and project mark am as testing only. The stable series na 1.4, currently 1.4.5. Start with 1.4 now. Borg 2 dey change repository format and e get documented upgrade path, so if you start today, e no go leave you stranded.