Restic vs BorgBackup: Which One You Go Run?

Restic vs BorgBackup, for one paragraph

Restic and BorgBackup both dey do the same main work: deduplicated, encrypted, incremental backups for Linux server. The difference wey go decide your choice na where the backup dey land. Restic natively dey speak S3 and other object storage APIs, so bucket na direct target and you no need install anything for the other end. Borg need the borg program installed for the machine wey dey hold the repository, because Borg repository dey use process to serve am, 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 dey faster.

Every other difference na smaller matter. 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 data for client side. Both fit mount snapshot with FUSE (filesystem in userspace), so you fit copy one file comot. As of July 2026, restic dey for 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.

Repository model na be 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 so one binary fit support local paths, SFTP, im 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 dey start borg serve for the other side through SSH, then e dey use im own protocol communicate with 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 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 fit dey off

Restic dey always encrypted. E no get unencrypted mode. restic init dey ask for password, 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.

For Borg, encryption na choice wey you make when you create repository, and you no fit change am 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 you no go fit read your archives. Each 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 sef dey available, and e make sense when repository dey on encrypted disk wey you own.

The practical rule be say: 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 e start. 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 minutes, and auto dey run one 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 values auto, off or 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 dey make the choice.

Restic wey dey reach S3 need credentials for environment, and nothing else need run anywhere. The same pattern work with bucket wey you host by yourself. This one dey common: 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 wey dey reach remote repository need SSH plus Borg installation for the other side. The version there must also compatible with the client. This fit cause wahala if you no own the other side. 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 only when you run its own REST server, wey support append only mode. For plain S3, bucket policy or object lock fit give you the same effect. Na the provider dey handle that part, no be restic. Lock down the transport too, because the 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 dem work instead.

Borg over SSH fast for connection wey get latency because the server side dey intelligent. The client ask one question, the remote borg serve process answer am from the repository index, and the transaction commit for one place. Chunk lookups no turn to 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 the number of requests reasonable, e pack plenty small chunks inside bigger pack files before uploading, and e 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 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 close, and both tools end up 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 throughout the whole operation. Two clients no fit write to one repository at the same time: the second one go wait, then e go fail when lock timeout happen. 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 back up to one repository at the same time, because backup dey take shared lock, while only maintenance work like prune dey take exclusive lock. If ten similar servers point to one restic repository, dem go deduplicate against each other, and the second server onward fit store very little. The cost na blast radius: one password and one repository dey hold everything, so if password lost, all ten backups go lost.

Retention: forget plus prune, versus prune plus compact

Tools all combine “wetin to keep” with “how to recover the space”, and for both of dem you must 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 dey the same for both tools, so make we talk am plainly. For Borg, borg prune removes archives but e no free disk space by itself. Space go return 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 remain 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 repository structures and tell you if anything don spoil. This better pass to discover the problem during restore.

Restore, na only test wey count

Both tools fit mount a snapshot so you fit 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

Notice 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 no extract anything. E no go show error to tell you why. Extraction too dey write inside current working directory, so change go scratch directory first. Otherwise, old files fit overwrite live files.

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

Which one dey win for which job

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

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

Both answers 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 live database file wey you copy at random moment no be database backup.

FAQ

Restic or BorgBackup dey faster?

For local disk or fast LAN, dem near each other, and both dey limited by read and hash speed for the source. Borg usually dey win over 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 usually dey win when target na object storage, because Borg no fit connect there at all.

BorgBackup fit back up go S3 or Backblaze B2?

No be directly. A Borg repository dey served by the borg serve process through 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 this, because mount wey disconnect 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 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 to store safely. Do this only if you don test both restores.

Wetin go happen if I lose repository password?

You no fit recover the data 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, but 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 the 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, and current version na 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, you no go get stranded.