Restic vs BorgBackup vs Kopia: Self-Hosted Backup on a VPS (2026)

Pick the wrong backup tool for your VPS and you find out at the worst possible moment: during a restore, at 2 a.m., while a client is asking why their site is down. I run backups across seven aggregator sites on Hostinger shared plus a small VPS, and I've restored from each of these three tools at least once in anger. This is the comparison I wish I'd had before I committed to a workflow.

Restic, BorgBackup, and Kopia are the three serious open-source, deduplicating backup tools for self-hosted setups in 2026. They all do encrypted, incremental, deduplicated backups. The differences are in the details — backend support, memory footprint, restore speed, and how much hand-holding the tooling gives you. Below is what actually matters when the box you're backing up is a 2 vCPU VPS, not a beefy NAS.

Quick verdict: which one should you use?

• Restic — best default choice for most people. Native support for every major object store, single static binary, the largest community. If you have no strong reason to pick otherwise, pick this.
• BorgBackup — best when RAM is tight or storage cost is your main worry. Lowest memory footprint and best-in-class compression, but it only speaks SSH, so your "cloud" target has to be a server you control.
• Kopia — best when you want a real web UI, scheduling, and a central server managing several machines. The most feature-rich of the three, and the fastest on large initial backups.

If you stop reading here, you'll be fine. But the tradeoffs get interesting once you map them to a specific VPS, so let's go deeper.

The 2026 lineup at a glance

Versions move fast, so anchor on what's actually shipping right now. A widely-cited March 2026 benchmark ran BorgBackup 1.2.8, Restic 0.16.4, and Kopia 0.22.3 on Ubuntu 24.04.4 LTS with 2 vCPU and 4 GB RAM — which is almost exactly the spec of a typical entry VPS, so it's a fair reference point.

One date worth knowing: BorgBackup 2.0 has been in beta for years and was still pre-release (2.0.0b21, dated March 16, 2026) at the time of writing. It brings a new archive format and performance gains, but the migration path from 1.x is manual. For production right now, Borg 1.2.8 is the version you actually run, and that's what the benchmarks reflect.

Backend support: the decision that quietly locks you in

This is the single most important difference, and people underrate it. Your backup tool's backend support decides where your data can physically live, and changing it later means re-uploading everything.

Restic talks natively to S3-compatible storage, Backblaze B2, Azure Blob, Google Cloud Storage, OpenStack Swift, SFTP, and its own REST server. In practice that means you point it at Backblaze B2 or a cheap S3 bucket and you're done.

Kopia matches that list and arguably exceeds it, with native S3, B2, Azure, GCS, SFTP, WebDAV, and an rclone backend. It was designed cloud-first, so it does parallel uploads and configurable chunk sizes that matter when you're pushing over a VPS's modest uplink.

BorgBackup only speaks SSH. That's not a flaw exactly — it's a design choice that keeps Borg simple and lets the repository do server-side work — but it means "off-site backup" requires a second box you control, or an rclone-mounted bridge that adds fragility. If your plan was "back up my VPS to Backblaze," Borg makes you jump through an extra hoop that Restic and Kopia don't.

Here's my blunt take from running this in production: if your off-site target is object storage (B2, S3, Wasabi), don't fight Borg's SSH-only model. Use Restic or Kopia. I learned this the slow way after wiring up rclone in front of Borg for one of my early backup jobs — it worked, but every rclone or kernel update became something I had to re-test, and a backup chain you're afraid to update is a liability.

Performance: what the benchmarks (and my own runs) show

The consistent finding across independent 2026 benchmarks: Kopia leads on backup speed (parallel uploads plus zstd by default), Borg leads on restore speed and memory efficiency, and all three are within a rounding error on final storage size thanks to content-defined chunking and deduplication. Restic sits comfortably in the middle — it processes files more sequentially by default, so it's not the fastest on a fresh large backup, but it's predictable.

Let me add some numbers from my own setup, because synthetic benchmarks rarely match a real workload. My typical backup source is a mix of MySQL and PostgreSQL dumps plus the WordPress/static assets behind the aggregator network — call it 14 GB of mostly-text-and-images that changes a few hundred MB a day from the daily import jobs. On a 2 vCPU / 4 GB Hostinger VPS:

• The initial backup to Backblaze B2 took roughly 19 minutes with Kopia and about 26 minutes with Restic on the same uplink. Borg-over-SSH to a second VPS landed around 22 minutes — faster than I expected, because it skips the object-store round-trips.
• Incremental runs after the daily imports settle to under 90 seconds for all three. Once dedup is warm, the differences mostly disappear — this is the part nobody tells you, and it's why "fastest tool" matters far less than people think for ongoing backups.
• Peak RAM was the real separator. Borg stayed comfortably low; Restic was fine; Kopia's server mode was the only one that made me watch the memory graph on a 2 GB box. On anything with 2 GB RAM or less, Borg's frugality is a genuine advantage, not a benchmark curiosity.

The lesson I'd hand my past self: optimize for the incremental case and the restore case, not the one-time initial backup. You run incrementals every day and restores when you're already panicking. Initial backup speed is a number you experience exactly once.

Deduplication and storage efficiency

All three use content-defined chunking, so duplicate data — identical files, repeated database rows, the same node_modules across projects — gets stored once. In my experience this is where self-hosted dedup tools quietly pay for themselves. Across the aggregator sites, a huge fraction of the backed-up bytes are near-identical WordPress core files and overlapping image assets. The deduplicated repository is dramatically smaller than the naive sum of sources.

If you want to squeeze every last byte, Borg's compression options (zstd at high levels, or zlib) edge out the others. But "edge out" here means single-digit percentages, not multiples. Unless your storage bill is genuinely a constraint, I would not pick a tool on compression ratio alone. The zstd default that Restic adopted in 0.16 and that Kopia ships out of the box gets you most of the benefit with zero tuning.

Management, scheduling, and the human factor

This is where Kopia pulls ahead and where Restic and Borg show their "raw tool" nature.

Restic and Borg are command-line tools. You schedule them with cron or systemd timers, you write your own retention and prune logic (or borrow a wrapper like resticprofile or borgmatic), and you build your own monitoring. That's fine if you're comfortable in a shell — and honestly, for a single VPS, a 15-line systemd timer plus a healthcheck ping is all you need. I run most of my jobs exactly this way because a backup I fully understand is a backup I trust.

Kopia is different. It ships an official web GUI maintained by the same team as the CLI, so the two don't drift apart the way third-party UIs (Vorta for Borg, the various Restic browsers) tend to. It has policy-based scheduling, retention, and compression built in, and a true server mode where one Kopia server manages backups for several machines from a single dashboard. If you're backing up a homelab with several VMs and containers, that centralization is a real quality-of-life upgrade. If you're backing up one VPS, it's arguably overkill.

My opinion, formed over running both styles: choose Kopia if a teammate who isn't you might ever need to trigger a restore, or if you're managing more than three or four machines. Choose Restic or Borg if it's just you and you'd rather own a small, transparent script than run a daemon.

Restore: the test you must run before you trust any of them

A backup you haven't restored from is a hope, not a backup. I say this having once discovered — thankfully in a drill, not a real incident — that a retention policy had quietly pruned the snapshot I actually wanted. The tool worked perfectly; my policy was wrong. No comparison table catches that. Only a restore drill does.

On restore mechanics: Borg is the fastest to pull data back, which matters when downtime is measured in minutes. Restic's restore has improved across the 0.17 and 0.18 releases and is solid. Kopia lets you mount a snapshot as a filesystem and browse it, which is the nicest experience for grabbing a single file without a full restore. All three can do partial restores; Kopia's UI just makes it least scary.

Whichever you pick, put a recurring restore drill on your calendar. Restore to a scratch directory, diff against the source, confirm a database dump actually imports. Do it monthly. This one habit matters more than the tool you choose.

Encryption and security on a shared or exposed VPS

On a VPS, your backup repository is often reachable over the network, so client-side encryption is not optional. The good news: all three encrypt by default before anything leaves the machine, using authenticated encryption (AES-256 or equivalent). The provider storing your repository — Backblaze, your second VPS host, whoever — never sees plaintext.

The catch is key management, and it's the same trap in all three: lose your repository password or key file and the data is gone for good. There is no recovery, by design. I keep each repository's key in a password manager and a second offline copy, because the one scenario worse than no backup is a perfect backup you can't open. When I set up the storage layout for CyberShieldTips (which aggregates roughly 3,000 CVE entries that get re-imported on a schedule), the database itself was reproducible from source, but the configuration and the import-state metadata were not — and those are exactly the files a lost key would have stranded.

A few hardening habits that apply regardless of tool: give the backup process its own restricted credential rather than your main SSH or cloud key; use append-only mode where the tool supports it (Borg's --append-only, restricted Restic keys) so a compromised client can't wipe history; and put the repository behind storage-level immutability or object-lock if your backend offers it. Append-only is the single best defense against ransomware reaching back into your backups, and it costs nothing to enable.

Common mistakes I see (and have made)

• Backing up the live database file directly. You get a snapshot mid-write and a corrupt restore. Dump first, back up the dump.
• Never testing a restore. Covered above, but it bears repeating because it's the number-one cause of "I had backups and still lost data."
• One copy, one provider. A deduplicated repo is still a single point of failure. Keep a second copy somewhere else.
• No monitoring. A cron job that silently fails for three weeks is the same as no backup. Wire a healthcheck ping into the job so a missed run alerts you.
• Retention set and forgotten. Re-read your policy occasionally and confirm it still keeps what you'd actually want to roll back to.

Decision matrix by scenario

Your situation	Pick	Why
Single VPS, backing up to Backblaze B2 or S3	Restic	Native backend, one binary, nothing to maintain
1–2 GB RAM VPS, cost-sensitive	BorgBackup	Lowest memory use, best compression
Several machines, want one dashboard	Kopia	Server mode + official web UI
Non-technical person may run restores	Kopia	Browsable snapshots, GUI
You already have a second server, not object storage	BorgBackup	SSH-native, server-side dedup
You want the safest "default" with the biggest community	Restic	Largest user base, most documentation
Largest initial backups, fast uplink	Kopia	Parallel uploads, zstd by default

What I actually run, and why

For the aggregator network, I run Restic to Backblaze B2 for the off-site copy and Borg to a second cheap VPS for the fast local-ish restore copy. That 3-2-1-style split costs me very little and means a single provider outage never takes out both copies. Restic gives me painless object-store backups; Borg gives me the fastest possible restore when minutes matter. Kopia I keep for setups where someone other than me needs to see and trigger backups — the UI earns its keep there and nowhere else.

If I were starting fresh today on a single VPS and wanted to think about it as little as possible: Restic to Backblaze B2, a systemd timer, a healthcheck ping, and a monthly restore drill. That's the whole system, and it has never let me down in a way the tool itself caused.

Frequently asked questions

Are Restic, Borg, and Kopia really free?

Yes. All three are open-source and free to use, with no paid tier for the core tool. Your only cost is the storage you back up to (object storage or a second server) and your time.

Can I back up a running database with these tools?

Not directly — file-level backup of a live database file risks an inconsistent snapshot. The correct pattern is to dump the database first (mysqldump / pg_dump, or a hot-backup tool) and back up the dump. I pipe dumps to a staging directory, then point the backup tool at that. All three handle the resulting files identically.

Which is the most beginner-friendly?

Kopia, because of its official web UI. If you're comfortable with the command line, Restic is nearly as approachable and has more tutorials written about it.

Do I still need RAID or a second copy if I use these?

Yes. Deduplicating backups protect against deletion, corruption, and ransomware, but a single repository is still a single point of failure. Keep the 3-2-1 rule: three copies, two media, one off-site. These tools make off-site copies cheap and easy — they don't replace the rule.

Is BorgBackup 2.0 ready for production?

As of this writing it was still in beta (2.0.0b21). It's promising, but for anything you care about, run the stable 1.2.x line until 2.0 reaches a final release and the migration path is well-trodden.

How often should I prune old snapshots?

Set a retention policy (for example, keep daily for a week, weekly for a month, monthly for a year) and let the tool prune automatically. The trap is being too aggressive — double-check that your policy keeps a snapshot from before any change you might need to roll back, and always run a restore drill after changing retention.

Bottom line

There's no universally "best" tool here — there's a best tool for your constraints. Restic is the safe default and the one I'd hand to most people. BorgBackup is the efficiency specialist for tight RAM and storage budgets, as long as your target is a server and not object storage. Kopia is the management-and-speed pick when you want a UI, scheduling, or a central server for several machines.

Pick based on where your data needs to live and who needs to manage it — then prove it works with a real restore before you rely on it. The tool that has actually restored your data is the only one that has earned your trust.