Dora NodaOn April 27, 2026, the maintainer of pgBackRest — the backup tool behind a huge share of production PostgreSQL fleets — archived the repository and announced he could no longer keep going without sustainable funding. Three weeks later, coordinated sponsorship led by Percona brought it back. Your backups survived, but the scare asked an uncomfortable question every platform team should answer on purpose rather than by accident: which backup engine are you actually betting your tenants' data on, and why that one?
This post answers that question for one concrete, common setup: encrypted backups of tenant data landing on S3-compatible storage you own — MinIO, Garage, Ceph, or an S3-compatible bucket next to your machines. The two serious open-source contenders are Restic and Kopia. Here is the short version, with the evidence behind it below.
The short answer
| Dimension | Winner | Evidence |
|---|---|---|
| Backup throughput, local disk | Kopia (~1.6x in one 49 GiB shootout) | Vendor-published comparison, 367,000-file corpus |
| Backup/restore over remote backends | Restic (~1.4–3x backup, much faster restore in one test) | Independent backup-bench runs, older versions |
| Memory footprint | Restic, directionally | Red Hat docs: "Kopia is more resource intensive than Restic" |
| Repository size | No consistent winner (1.0x–3.5x spread across published points) | Corpus- and compression-dependent; measure yours |
| Encryption strength | Tie (both client-side AES-256) | Restic AES-256-CTR + Poly1305; Kopia AES-256-GCM + scrypt |
| Kubernetes ecosystem alignment | Kopia, decisively | Velero's docs now describe Kopia only; restic uploader deprecated |
| Operational simplicity | Restic | No maintenance daemon mindset, simpler repo to reason about |
The one-line recommendation for a self-hosted PaaS: if tenant volume backups already flow — or will flow — through Velero file-system backup, standardize on Kopia and stop debating. If you need a small, low-RAM sidecar pushing encrypted snapshots to a bucket with minimal moving parts, Restic remains excellent. Everything else is details, and the details matter, so keep reading.
The numbers: what a 49 GiB shootout proves, and what it doesn't
Published Restic-vs-Kopia numbers are scarce, and the two best public data points disagree with each other — which is itself the most important finding. The winner depends on the corpus, the backend, and the version era, so treat any single multiplier with suspicion, including the ones in this section.
Data point 1: a 49 GiB, 367,000-file local shootout. A comparison published on the website of Vykar, a newer backup tool, backed up the same 49 GiB corpus with five engines. Kopia finished the backup in 85 seconds against Restic's 138 — about a 1.6x advantage — while restores were a near-tie at roughly 130 seconds each.
Two caveats, both load-bearing: the numbers are vendor-published by a competitor, and they describe local-disk throughput, which exercises chunking, hashing, and compression far more than the S3 upload path your tenant backups actually depend on. Use this point for the ratio on local disk, not as an MB/s promise for your object storage.
Data point 2: backup-bench over remote backends. The independent, reproducible backup-bench suite tells the opposite story on older versions (Kopia 0.12.0, Restic 0.14.0) writing to remote repositories. Backing up git repositories over the network, Restic completed runs in 10–24 seconds against Kopia's 32–72 — roughly a 2.5–3x Restic advantage — and restored in 28 seconds against Kopia's 258. On a second 366 GB corpus of QEMU disk images, Restic's initial backup was about 1.37x faster (8,848 vs 12,125 seconds).
The benchmark author flagged a remote-path bottleneck on Kopia's side, since improved in later releases — which is exactly why version labels matter more than headline multipliers.
What about RAM? Here honesty requires admitting a gap: there are no rigorous published head-to-head memory measurements I can point you to, only directional evidence. Red Hat's OpenShift backup documentation states plainly that "Kopia is more resource intensive than Restic, and you might need to adjust the CPU and memory requirements accordingly." On Restic's side, the project's changelogs document steady memory work — v0.17.0 cut prune memory usage by up to 60% — while its forums still carry reports of large backups ballooning past several GB of RAM.
Directionally, Restic is the lighter engine; quantitatively, both deserve a memory limit and a load test against your corpus before you commit.
Encryption and tenant isolation first
Both engines encrypt client-side before a single byte reaches your S3-compatible storage, which is the property that makes "untrusted bucket on infrastructure I share" a workable design. The primitives differ but neither is exotic: Restic encrypts repository files with AES-256 in counter mode authenticated by a Poly1305-AES MAC, with a fresh random IV per file, as documented in its design reference. Kopia defaults to AES-256-GCM with an HMAC-SHA256 construction, scrypt key derivation, and BLAKE2/BLAKE3 content hashing, as its own repository-creation output shows.
For tenant backups, the cipher is table stakes; the isolation model is the real question. Both engines answer it the same way: one repository per tenant, each with its own password-derived keys, so a compromised key exposes one tenant, never the fleet. The multi-client plumbing differs. Restic leans on rest-server with private repositories and htpasswd authentication — deliberately dumb, easy to audit. Kopia ships a first-class server mode with per-user authentication and per-user snapshot policies (retention, compression) enforced server-side, which maps more naturally onto "each tenant gets a policy" without wrapping the CLI yourself.
One operational consequence: Kopia's server mode and policy engine are genuinely useful at fleet scale, but they are more concepts to learn, monitor, and upgrade. Restic's model — a repo is a directory of encrypted packs, and check verifies it — can be explained to a new hire in ten minutes. If your team is three people running a PaaS on owned machines, that simplicity has a dollar value.
Why the numbers differ, and the repo-size question
The throughput split follows directly from architecture. Kopia parallelizes aggressively — concurrent content uploads, tunable parallelism flags, policy-driven compression (zstd-family) applied by default — which is why it shines when the bottleneck is local CPU and disk. Restic's design optimizes for lock-free simplicity: repositories are append-only pack files addressed by SHA-256, safe for concurrent readers and writers, with prune as the only mutating operation. That restraint costs it on highly parallel uploads but pays back in repo-format comprehensibility and restore-path speed, especially over server-mediated backends where Kopia's chattier protocol historically lagged.
Repository size refuses to reduce to a single multiplier, so here are the published points with their labels instead of a headline number:
- backup-bench, git-repos corpus, Kopia 0.12 / Restic 0.14: final sizes within ~2% of each other (657 MB vs 668 MB) — effectively a tie.
- backup-bench, 366 GB QEMU-image corpus, same versions: Kopia's repo ~1.2x larger (140 GB vs 116 GB in repo units).
- An informal same-corpus test quoted in Kopia's issue tracker (old versions, author-labeled "not rigorous"): Kopia 631 MB vs Restic 2.2 GB, roughly 3.5x the other way.
A 1.0x–3.5x spread that flips sign is not noise to average away; it is the signal. Repo size is dominated by compression settings and dedup behavior on your data shape — VM images dedup differently than source trees — interacting with each engine's defaults. Anyone quoting you a single repo-size multiplier without naming the corpus is selling something. Budget a same-corpus trial run; it takes an afternoon and answers the question for the only dataset that matters.
The ecosystem tiebreaker: Velero already voted
If your tenant backups ride on Kubernetes persistent volumes, there is a tiebreaker that dwarfs benchmark ratios: Velero, the de facto Kubernetes backup tool, now speaks only Kopia. Its current file-system-backup documentation walks through Kopia integration — Kopia uploader, Kopia repository behind Velero's unified repository interface — and mentions Restic zero times. The --uploader-type flag defaults to kopia, and selecting restic prints an explicit deprecation warning telling you not to use it for new backups because restores won't be available once the functionality is removed.
This is not a fashion statement; it is a maintenance-lifetime signal. The project that operates file-level backup at the largest scale in the ecosystem picked Kopia's upload throughput and repository model, deprecated the alternative, and pointed its docs at one engine.
If you run Velero file-system backup — or plan to — adopting Kopia for the surrounding tenant-backup story means one engine to learn, one repository format to monitor, and restore tooling that matches the thing already protecting your volumes. Swimming against that current needs a justification stronger than "we already know Restic," though team familiarity is at least an honest reason.
The sustainability lesson from pgBackRest's April scare
April's pgBackRest episode deserves its three sentences because it changed the due-diligence checklist, not because it changed the verdict. On April 27, 2026, David Steele archived pgBackRest after more than a decade as its maintainer, stating plainly that the work had lost sustainable funding when Crunchy Data's sponsorship ended at acquisition. The obituaries were premature: by May 19, Percona had coordinated multi-company sponsorship and shared engineering effort to put the project on a funded footing, and work continues.
The lesson for picking any backup engine: your shortlist needs a sustainability column next to throughput and RAM. Before standardizing, check release cadence over the last year, breadth of the contributor base beyond one maintainer, and who funds the work. Both Restic and Kopia show active 2026 releases and real contributor communities — run the check yourself rather than trusting a blog post, this one included, because this column decays faster than any benchmark.
Decision guide: when each engine wins
- Velero anywhere in the picture → Kopia. One engine, matching restore tooling, aligned with upstream's direction. This single rule settles the question for most Kubernetes-based platforms.
- Tiny sidecar, minimal RAM, simplest thing that encrypts → Restic. A single static binary, a repo format you can explain in ten minutes, and the lighter resource profile. Ideal for per-machine agents pushing to a bucket.
- Per-tenant policies (retention, compression) enforced centrally → Kopia. Server mode with per-user policies beats wrapping Restic in your own policy layer.
- Huge file counts on constrained nodes → test both, lean Restic. Restic's memory story on giant repos is imperfect but heavily worked on; Kopia's higher baseline footprint hurts most exactly here.
- Mixed fleet → allow both, split by role. Kopia for Velero-integrated volume backup, Restic for lightweight host/edge agents. Two engines is a cost, but forcing one engine into both roles is a larger one.
Whichever you pick, the unglamorous practices dominate the outcome: per-tenant repositories with separate keys, scheduled check/verify runs, periodic test restores (a backup you have never restored is a hope, not a backup), and retention policies written down before the first incident. The engine choice is a multiplier on that discipline, not a substitute for it.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Tenant backup design like the above is exactly the kind of unglamorous platform work a self-hosted PaaS has to get right. Star the repo on GitHub or deploy your first app today.
