restic vs borg vs kopia: measured on 6 GB

All three tools did the job without errors, so the choice comes down to repository size, speed and memory on your data. On this test’s data, restic with its default settings produced the smallest repository and the fastest restore. Kopia was fast to back up but slow to restore with default flags. Borg had the lowest peak memory in all three phases (117 MiB, 109 MiB and 104 MiB).

This is one dataset on one virtual machine, so read the numbers as relative behavior, not as what your data will do. The dataset below is deliberately mixed, and one part of it (the compressible files) was built to favor tools that compress by default.

What was measured

The dataset is generated from a fixed seed by gen_dataset.py and was regenerated a second time to confirm that the SHA-256 manifest is identical. The 5% change used for the incremental run rewrites 2,000 of the 40,000 small files and overwrites one contiguous 5% region in each of the 9 large files; the duplicates are untouched.

Each of the three cycles used a fresh repository, a rebuilt source tree and a cold page cache before every timed step. Repositories lived on the VM’s own virtual disk, so network and cloud storage behavior is not in these numbers. The tools were installed as restic’s official release binary, borg’s standalone release binary (borg-linux-glibc231-x86_64, not a pip or distribution package) and kopia’s .deb; a different packaging of borg could start and run differently. Peak memory is the resident set size from /usr/bin/time -v, shown in MiB. Restore checksum check means every restored file was hashed and the full manifest (paths and SHA-256) compared with the source after the 5% change. File modes, timestamps and empty directories were not compared.

Defaults recorded

These are the settings each tool used with no tuning flags. Borg has no default encryption mode, so the test chose repokey-blake2; the borg docs list the modes. The borg create docs give lz4 as the default compression. The restic docs state that new repositories use format version 2, which adds compression support. Kopia’s own output reported “Compression disabled.” for its global policy, and its compression docs describe compression as a policy setting.

What the numbers say

• Repository size is mostly a compression story here. Restic’s repository (3.86 GB) is smaller than both others on a 6.10 GB source that includes 2.68 GB of low-entropy data. Borg’s default lz4 and kopia’s disabled compression left those files close to their original size. A dataset of already-compressed media would likely narrow the gap; that was not tested.
• The incremental backup after a 5% change grew the repository by 0.21 GB for restic, 0.29 GB for borg and 0.31 GB for kopia, and took 7 s, 17 s and 7 s.
• Kopia’s restore (140 s, range 122-168) was the surprise. It was slow in all three cycles (122, 140 and 168 s) and also had the highest peak memory (455 MiB), against 14 s and 195 MiB for restic. The test used kopia’s default restore command and did not try its parallelism options, so this says nothing about a tuned kopia.

What went wrong

The first full attempt of this test failed for kopia on every cycle because the --cache-directory flag was placed on the wrong subcommand; kopia exited with “unknown long flag”. The whole test was then rerun from scratch so that all three tools share one run; the raw output of the failed attempt was not kept, and every number on this page comes from the final run. Nothing else was retried.

The test script

#!/usr/bin/env bash
# Test backup-bench: restic 0.19.1 vs borg 1.4.5 vs kopia 0.23.1 on a seeded ~6 GB dataset.
set -uo pipefail
source "$(dirname "$0")/../_common/lib.sh"
ID=backup-bench; NAME=c-$ID; D="$ROOT/lab/tests/$ID"; E="$ROOT/evidence/tests/$ID"; RAW="$E/raw"
rm -rf "$RAW"; mkdir -p "$RAW"
trap 'vm down $NAME' EXIT
host_env "$RAW"
vm up $NAME || exit 1
gssh 'sudo apt-get install -y -qq time bzip2 >/dev/null 2>&1; sudo mkdir -p /srv/work && sudo chown lab:lab /srv/work'
# pinned official release artifacts
gssh 'set -e; cd /tmp
curl -fsSL -o restic.bz2 https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2 && bunzip2 -f restic.bz2 && sudo install -m755 restic /usr/local/bin/restic
curl -fsSL -o borg https://github.com/borgbackup/borg/releases/download/1.4.5/borg-linux-glibc231-x86_64 && sudo install -m755 borg /usr/local/bin/borg
curl -fsSL -o kopia.deb https://github.com/kopia/kopia/releases/download/v0.23.1/kopia_0.23.1_linux_amd64.deb && sudo dpkg -i kopia.deb >/dev/null; which kopia'
gssh 'sudo ln -sf /usr/bin/kopia /usr/local/bin/kopia; sha256sum /usr/local/bin/restic /usr/local/bin/borg /usr/bin/kopia' > "$RAW/binary-sha256.txt"
vm scp-to "$D/gen_dataset.py" /srv/work/; vm scp-to "$D/apply_change.py" /srv/work/; vm scp-to "$D/guest.sh" /srv/work/
gssh 'bash /srv/work/guest.sh' > "$RAW/guest-stdout.txt" 2>&1
vm scp-from /srv/work/raw/. "$RAW/"
guest_env "$RAW" 'restic version; borg --version; kopia --version; python3 --version'
python3 "$D/summarize.py" "$RAW" "$E"

The guest-side steps are in guest.sh, gen_dataset.py and apply_change.py next to it. The exact commands per tool were:

# restic
restic init -r /srv/repo
restic backup -r /srv/repo /srv/src
restic restore latest -r /srv/repo --target /restore

# borg (encryption mode chosen by the test)
borg init --encryption=repokey-blake2 /srv/repo
borg create --stats /srv/repo::s1 /srv/src
borg extract /srv/repo::s2      # run from inside /restore

# kopia
kopia --config-file=<cfg> repository create filesystem --path /srv/repo --cache-directory=<dir>
kopia --config-file=<cfg> snapshot create /srv/src
kopia --config-file=<cfg> snapshot restore <snapshot-id> /restore/srv-src

Passwords were lab-only-not-a-secret through each tool’s environment variable.

What this test did not cover

• Network or cloud repositories (S3, SFTP, rclone). Everything ran against a local path on one virtual disk.
• Other data shapes: millions of tiny files, already-compressed media, databases, very large single files.
• Tuning: compression levels, kopia restore parallelism, restic pack size, borg chunker parameters. All three ran with defaults except borg’s mandatory encryption choice.
• Repository maintenance (prune, compact, check), long-running repositories with many snapshots, and behavior after an interrupted backup.
• Memory under a smaller VM than 3 GB, and on slower disks. Timings come from a VM with 4 vCPU and 3 GB RAM on a shared host; run-to-run ranges are in the table but a busier host would change them.
• Security properties of the encryption schemes beyond what each project documents.