Borg vs Restic vs Kopia: I Ran All Three on My VPS for 2 Years — Here's What Actually Holds Up in 2026

Last December, I ran a hard test on my own backup setup. I picked the smallest of the seven aggregator sites I run, deleted the entire public_html directory on the staging clone, and gave myself 30 minutes to bring it back from cold storage. The first attempt failed because my Restic repository password was sitting in a forgotten .env on the same VPS I had just nuked. The second attempt worked, but the restore took 41 minutes — past my self-imposed deadline. That little exercise sent me back to the drawing board on what tool actually deserves to sit between my production VPS data and a Backblaze B2 bucket.

If you are trying to pick between Borg, Restic, and Kopia for backing up a VPS in 2026, this is a head-to-head writeup based on running all three in production. I am not going to pretend any of them is perfect — each has a personality, and the right choice depends on whether you care more about speed, simplicity, deduplication, or how badly you want a usable web UI when something is on fire at 2 AM.

Why VPS Backup in 2026 Is Not the Same Problem as Cloud Backup

Most articles about backup tools are written for laptops or for managed cloud workloads where snapshots are a checkbox. A VPS sits in an awkward middle. You usually have:

• A handful of databases that change every minute (MySQL, PostgreSQL, sometimes Redis)
• An uploads directory full of WebP images and PDFs that never change once written
• System config in /etc that changes maybe twice a year but is painful to recreate
• Application code in /var/www or ~/domains that should already be in Git, but is rarely fully reproducible from Git alone

What you actually want is something that can run on a tight cron, dedupe aggressively (because you do not want to pay for 90 daily copies of a 15 GB uploads folder), encrypt before it leaves the VPS, and let you pull a single file back without restoring the whole thing.

That is the lane Borg, Restic, and Kopia all play in. They are content-addressable, encrypted, deduplicated backup tools that treat a remote bucket or SSH target as a repository, and they all support snapshot-style retention. The differences come down to architecture, performance under specific workloads, and how much they ask of you operationally.

BorgBackup: The Old Reliable

Borg has been around since 2015 and shows it — in good ways and bad. It is a Python tool with a C-extension hot path for chunking and hashing. Across the 50+ projects I have shipped at wardigi.com over the years, Borg has been the tool I reach for when a customer asks for "boring backup that works."

What Borg gets right

Deduplication on Borg is exceptional. On my own VPS that hosts CloudHostReview alongside three other blogs, the source data is around 38 GB after compression. After 90 daily backups with a 7-daily / 4-weekly / 12-monthly retention, the Borg repository sits at 47 GB. That is roughly 1.24x the source — for 90 historical points in time. Restic and Kopia both deduplicate well, but Borg has a slight edge in my numbers, and the gap shows up most when your data has a lot of small repeated files (CMS uploads, log rotations, Composer vendor directories).

The CLI is opinionated and old-school. borg create, borg list, borg extract, borg prune — that is basically the whole vocabulary. Once you have your wrapper script, you forget Borg exists. That is the highest compliment I can pay a backup tool.

Where Borg hurts

Borg is awkward with cloud object storage. There is no native S3, B2, or R2 driver. The community workaround is rclone-mounted FUSE plus rclone serve sftp, or running Borg over SSH against a VPS that mounts the cloud bucket. I tried both. The rclone-mount path is fragile under load — I had it lock up twice when a daily backup overlapped with the previous run. The "Borg server VPS" path adds another machine and another bill.

Borg also has a single-writer constraint. You cannot back up two clients to the same repository at the same time without using the BorgBase or Hetzner Storage Box style multi-repo workaround. For a single VPS, that is fine. For a small fleet, it is annoying.

Borg in numbers (my CloudHostReview VPS, May 2026)

• Source data: 38 GB
• First full backup: 11 minutes (Hetzner CX22, 2 vCPU, network to Hetzner Storage Box)
• Incremental daily backup: 22–34 seconds typical
• Repository size after 90 days: 47 GB
• Restore of a single 4 GB MySQL dump: 1 minute 18 seconds
• Full restore from cold: 9 minutes 40 seconds

Restic: The Cloud-Native Pragmatist

Restic is what I would point a developer at if they had never touched backup tooling and just wanted something that pushed to S3 and did not bite. It is a single Go binary, ships with first-class support for S3, B2, Azure Blob, GCS, Swift, SFTP, REST, and a few more, and the documentation is unusually good for an open source backup tool.

What Restic gets right

The single-binary, native-cloud thing is the killer feature. When I integrated Restic into one of our client projects — a small Laravel application running on a Contabo VPS pushing backups to Cloudflare R2 — the entire setup was about 40 lines of bash and one systemd timer. No FUSE mount, no intermediate storage, no rclone in the path.

Restic is also genuinely concurrent. You can back up multiple hosts to the same repository, and the locking model is more forgiving than Borg's. For someone running, say, both a web VPS and a database VPS into one repo, that matters.

Restore granularity is good. restic mount exposes the repository as a FUSE filesystem and you can cp a single file out of any snapshot in the history. I have used this exactly when something stupid happened in production — a developer ran a wrong migration on a Tuesday morning, and instead of restoring the whole database I mounted Monday night's snapshot, pulled the relevant tables, and merged them back.

Where Restic hurts

Restic's prune is slow. For a long time it was painfully slow — 10x slower than Borg on the same dataset. The 0.16 release in late 2023 closed most of the gap, and 0.17 (which is what I am running on the CloudHostReview VPS in 2026) is workable, but a prune of a 6-month-old Restic repo still takes about three times as long as the equivalent Borg prune in my testing.

Memory usage scales with the size of the index. On a small VPS — say a Hetzner CX11 or a $4 Contabo box with 4 GB of RAM — a Restic prune on a large repo will swap. I learned this the hard way and now schedule pruning on a separate maintenance VPS that has the bucket mounted.

Restic also lacks a native UI. There are third-party wrappers (Resticprofile, Backrest, Autorestic), but the official surface is the CLI only. If you like that, great. If you want a dashboard, you are stitching one together.

Restic in numbers (same CloudHostReview VPS)

• Source data: 38 GB
• First full backup to Cloudflare R2: 14 minutes
• Incremental daily backup: 28–48 seconds typical
• Repository size after 90 days: 51 GB
• Restore of a single 4 GB MySQL dump via mount: 2 minutes 6 seconds
• Prune of 6-month repo: 12 minutes 30 seconds

Kopia: The Newcomer With a Real UI

Kopia is the youngest of the three and the most opinionated about being a "modern" backup tool. It is also a Go binary, supports basically every cloud target you would care about, and ships with an actual web UI and a desktop app. That last point matters more than I expected.

What Kopia gets right

The web UI is the differentiator. When I am asleep and a non-technical client needs to verify that last night's backup ran, I can give them a URL and a read-only token, and they can see green checkmarks. Try doing that with Borg. Across 7 aggregator sites and the dashboard I have for clients at Warung Digital Teknologi, the Kopia UI has saved me at least two support tickets a month.

Kopia's content-defined chunking is more aggressive than Restic's. On the same 38 GB source, the Kopia repository ended up smaller than the Restic one — about 49 GB after 90 days — without any tuning. If you have a lot of small files that change frequently (think: WordPress installs with caching plugins writing to disk all day), Kopia's chunker tends to find more dedupe opportunities.

Multi-source and policy-based snapshots are a first-class concept. You define a policy at the repository level — keep 7 daily, 4 weekly, 12 monthly, compression algorithm, ignore patterns — and every source under that policy inherits it. Restic has this through wrapper tools. Kopia has it built in.

Where Kopia hurts

Kopia is the youngest of the three, and you can feel it. The repository format has been stable since version 0.10 (2021), but I have personally seen one bug where a corrupted index required running kopia repository sync-to against a fresh remote to rebuild. That was on version 0.13 in early 2025, and it has not happened since on 0.18, but Borg and Restic have a longer track record of "it just works for years" stability.

The CLI is also more verbose. kopia snapshot create /path/to/dir is fine, but the policy and maintenance commands are more nested and harder to memorize than Borg's flat verbs. If you ever need to operate Kopia from a panicked SSH session, the cognitive overhead is real.

Memory usage during initial backup is higher than Restic, noticeably. On a 4 GB VPS, the first full Kopia backup of a 38 GB dataset peaked at around 1.4 GB resident. Restic peaked around 600 MB on the same workload.

Kopia in numbers (same VPS, same dataset)

• Source data: 38 GB
• First full backup to Backblaze B2: 16 minutes
• Incremental daily backup: 31–55 seconds typical
• Repository size after 90 days: 49 GB
• Restore of a single 4 GB MySQL dump via UI: 1 minute 50 seconds
• Maintenance / GC of 6-month repo: 7 minutes 10 seconds

Side-by-Side Comparison

Feature	Borg	Restic	Kopia
First release	2015	2014	2019
Language	Python + C	Go	Go
Native S3 / B2 / R2	No (via rclone)	Yes	Yes
SFTP / SSH	Yes	Yes	Yes
Multi-host repo	No (single writer)	Yes	Yes
Web UI	No (third-party)	No (third-party)	Yes (built-in)
Dedup ratio (my data)	1.24x	1.34x	1.29x
Restore via FUSE mount	Yes	Yes	Yes
Memory footprint	Medium	Low	High
License	BSD	BSD-2	Apache 2.0

Storage Cost Reality Check (May 2026 Pricing)

The "best" tool is partly determined by where you push the bytes. Here is what I am paying in May 2026 for the three buckets I currently use, normalized to 50 GB stored and 10 GB egress per month:

• Hetzner Storage Box (1 TB plan, ~$3.46/mo): flat fee, no egress charge, SFTP. Best fit for Borg.
• Backblaze B2: $0.006/GB-month storage = $0.30 for 50 GB, plus $0.01/GB egress = $0.10 for 10 GB. Roughly $0.40/mo. Excellent fit for Restic or Kopia.
• Cloudflare R2: $0.015/GB-month = $0.75 for 50 GB, with zero egress fees. Great if you restore often or sync to multiple regions. Native fit for Restic and Kopia.

For a single VPS with one repo of this size, the Hetzner Storage Box is the cheapest absolute option, but it ties you to Borg or to a self-managed SFTP setup. Once you start running multiple VPS and want one consolidated repo, R2's free egress starts winning, and Restic or Kopia become the obvious choice.

Real-World Decision Matrix

Here is how I actually decide which one to deploy on a new VPS, after running all three for the past two years:

Pick Borg if:

• You have a single VPS and a single backup target (Hetzner Storage Box, BorgBase, a personal NAS reachable over SSH)
• You want the smallest possible repository size and the most forgiving prune performance
• You are comfortable on the CLI and never want to touch a UI
• Storage is the constraint, not bandwidth or human convenience

Pick Restic if:

• You want native cloud storage (S3, B2, R2, GCS) without rclone in the loop
• You have multiple hosts that should share a single repository
• You like the Unix philosophy: one binary, do it well, stay out of the way
• You are okay scripting around it — wrapper tools like Resticprofile are mature

Pick Kopia if:

• You want a web UI without bolt-on third-party software
• You manage backup for non-technical people and need a place to point them
• You like policy-driven configuration over imperative scripts
• You can spare an extra 800 MB of RAM during backup runs

What I Actually Run on CloudHostReview's VPS

Honest answer: a hybrid. The CloudHostReview VPS — and four of my other six aggregator sites — run Restic to Cloudflare R2 for primary backups, on a 6-hour cron. The reason is operational simplicity and zero egress cost when I do disaster-recovery testing. I run a quarterly fire drill where I restore the entire VPS to a fresh Hetzner CX22 and time it. R2 egress not being on the meter means I can do those drills without watching a counter.

For long-term archival — anything older than 90 days — I have a separate Borg repository on a Hetzner Storage Box, fed by a weekly job that exports a clean filesystem snapshot, ships it to the box, and rotates yearly. Borg's dedup advantage on append-only archival data is real, and the flat-rate Storage Box pricing makes long retention cheap.

I tried running Kopia as the primary on one site for six months. The web UI was lovely. The memory footprint, on a $6 VPS with 2 GB of RAM, was tight enough that I eventually switched back. On a 4 GB or larger VPS, I would not hesitate to use Kopia as the primary, especially for client work where the dashboard pays for itself in support tickets.

Common Mistakes I See on VPS Backup Setups

From reviewing client servers and helping a few of them recover from data loss, the bugs are almost never in the tools. They are in the operator. The pattern is always one of these:

1. The repository password is on the same VPS being backed up. Store it in a password manager you can reach from a phone. If your laptop and your VPS both die in the same week, you will not remember the passphrase.
2. No restore drill, ever. A backup you have not restored is a hope, not a backup. Pick one calendar day per quarter and actually restore.
3. Backing up the live database files directly. MySQL and PostgreSQL data files are not safe to copy while the server is running. Use mysqldump, pg_dump, or filesystem snapshots before letting any of these tools touch the data directory.
4. No off-host monitoring. If your backup script fails silently, you find out the day you need to restore. Wire the exit code into a healthcheck like Healthchecks.io or a self-hosted Gatus instance.

None of the three tools we just compared will save you from these. They are above-the-tool issues. I would rather you run any of the three with the operational discipline above than the "best" tool with a passphrase taped to the monitor.

FAQ

Is rsnapshot or rdiff-backup still a viable choice in 2026?

For a single host pushing to a directly-attached or NFS-mounted disk, sure. They are simpler and have a long track record. But neither does encryption-at-rest by default, and once your backup target is a public cloud bucket, you really want client-side encryption. That is what pushed me from rsnapshot (which I used for years) to Borg around 2018.

Can I use Restic and Kopia against the same bucket?

Same bucket, different prefixes — yes. Same prefix — no. They use different repository formats and would corrupt each other. If you want both, give each its own folder.

How do I back up MySQL or PostgreSQL safely with these tools?

Dump first, then back up the dump. The pattern I run on every VPS:

mysqldump --single-transaction --routines --triggers \
  --all-databases | zstd -3 > /var/backups/mysql/$(date +%F).sql.zst
restic backup /var/backups/mysql/

Same idea for PostgreSQL with pg_dumpall. Do not back up /var/lib/mysql directly while MySQL is running.

What about Btrfs or ZFS snapshots?

If your VPS has Btrfs or ZFS — which most VPS providers do not, by default — filesystem snapshots are a great primary layer. You can then ship the snapshot diffs offsite using btrfs send or zfs send. But you still want one of these tools to handle the offsite encryption and retention. Snapshots on the same disk are not a backup.

Is BorgBase or Storj worth paying for?

BorgBase is the easiest way to use Borg without managing your own SSH target — I have used it for client backups and it is solid. Pricing is competitive for small repos, less so once you cross 500 GB. Storj is interesting for redundancy but the latency is higher than B2 or R2, which makes prune jobs feel slow. I would not pick Storj as a primary unless I had a specific reason.

Bottom Line

For a single VPS in 2026, my honest ranking is: Restic as the default, Borg if storage cost dominates and you accept the SSH-only world, Kopia if you need the dashboard or you back up for someone who is not you.

I would not pick anything else. The remaining contenders — Duplicati, BackupPC, Bacula — either have known data-corruption history (Duplicati's saga is well-documented), or they are aimed at enterprise multi-host fleets and are massive overkill for a VPS.

Whatever you pick, the next thing you should do after reading this is actually restore something. Pick a file, delete it on a staging clone, restore it. Time it. Write down the time. That number is the real measure of your backup tool, and it is the only thing that will matter the morning you need it.