Backup Data vs restic: managed service or self-run tool?

Let's start with respect where it's due: restic is one of the best backup tools ever written. Content-defined chunking, global deduplication, encryption on by default, immutable snapshots, sane retention. restic proved a decade ago what good backups look like, for free, in a single binary.

Backup Data agrees with restic about almost everything. Content-addressed chunks (FastCDC), dedupe, Zstd compression, point-in-time snapshots, prune-style retention, client-side AES-256-GCM: if you know restic, the BaaS design will feel familiar rather than novel.

So this comparison isn't about backup philosophy. It's about a single operational question:

Do you want to run the backup system, or just call it?

• restic is a tool. You bring the storage backend, the scheduling, the monitoring, the repository maintenance, and the key management. In exchange: total control, any backend, zero software cost.
• BaaS is those same primitives as a service: storage included, a portal for humans, workspaces and scoped API keys for teams, and an SDK (Go/JS) instead of shelling out to a CLI.

The decision rule: the more the backup is a personal/homelab concern or you have real ops capacity to spend, the better restic fits. The more it's a team responsibility that nobody wants to babysit, the better BaaS fits.

Head to head

The differences that actually matter

1. Who operates the system

A production restic setup is more than restic backup. Done properly, it's: a storage backend with credentials management, cron or systemd timers per machine, forget/prune on a schedule, periodic check (and occasional check --read-data, which reads the whole repo), alerting when any of those don't run, handling stale repository locks after crashed runs, and a documented answer to "where is the repo password stored and who can reach it?"

None of that is hard. All of it is work, it's yours forever, and it fails silently when the person who built it leaves. That operational layer is exactly what BaaS absorbs: storage, integrity, and lifecycle live service-side; your job is a dump plus one SDK call, and the portal shows every source and snapshot without SSH-ing anywhere.

2. Teams: one password vs workspaces and scopes

restic's security model is a repository password. It's strong cryptography, but organizationally it's one shared secret: every machine and person that backs up holds the key to the whole repo, and revoking one machine means re-keying.

BaaS was built team-first: workspaces per project, members with roles, API keys scoped to what a job actually needs (backup:write for the cron job, snapshots:read for the dashboard), and key rotation when someone offboards. For a solo homelab this is irrelevant. For a company, it's the difference between a tool one person uses and infrastructure a team shares.

3. SDK vs CLI

restic from automation means shelling out and parsing output. Fine in a bash script, awkward inside an application. BaaS is a library:

const snapshot = await client.backup(["./db-dumps"], {
  description: "nightly database backup",
  tags: { env: "prod", db: "app_db" },
  onProgress: (e) => console.log(`[${e.phase}] ${e.current}/${e.total}`),
});

Progress events, typed options, restore and prune as function calls: backup logic that lives in your codebase, testable in CI like everything else. (Notably, for databases both tools want the same thing from you: a consistent dump first. pg_dump feeds restic and BaaS identically; see the Postgres tutorial.)

4. The economics, honestly

Raw storage for restic can be cheaper. Backblaze B2 runs about $6/TB-month as of this writing, so restic + B2 for a terabyte is roughly $6/month versus BaaS Pro at $20/month.

If that $14 gap is decisive, restic is your answer and we mean that. What the BaaS tier buys is everything around the bytes: no backend account to manage, no maintenance jobs to schedule and monitor, team access control, a portal, support, and dedupe you never have to prune-tune. The real comparison is $14/month against the engineering hours spent building and babysitting the restic pipeline. For most teams past the homelab stage, an hour a month of ops time already costs more.

When restic is the right call

Genuinely, pick restic if:

• It's personal: laptops, homelab, family photos. restic + B2 or a local drive is unbeatable, and the FUSE mount for browsing old snapshots is a killer feature.
• You need a specific backend: SFTP to a box you own, MinIO on-prem, an air-gapped drive, anything rclone can reach. BYO-storage is the point.
• Zero vendor dependency is a hard requirement: open-source tool, open repo format, community audit trail, no company in the loop at all.
• You have platform-team capacity and backup ops is just another well-monitored pipeline in your fleet.
• Budget is the binding constraint and your time is genuinely free.

When Backup Data is the right call

• Nobody owns backup ops. You want dump + one SDK call, with storage, verification, and retention handled, and no check/prune/lock-handling rota.
• It's a team system: workspaces, roles, scoped keys, and rotation instead of a shared repo password.
• Backups belong in application code: the SDK slots into your app, CI, or scheduler with progress events and typed options.
• You want a portal: browsing sources and snapshots without SSH, for the teammates who will never learn restic's CLI.
• You're backing up from ephemeral environments (CI runners, containers) where a scoped API key beats distributing a repo password.

Or: use both

The 3-2-1 rule wants copies in more than one system anyway. A pattern that works well:

1. restic for machine-level backups you already run: laptops, homelab, /etc on pet servers.
2. BaaS for the team-owned, application-critical data: production database dumps and model checkpoints, where scoped keys, the portal, and zero maintenance matter.

Different systems, different failure modes, both encrypted client-side. That's diversity, not redundancy waste.

FAQ

Is BaaS built on restic? No. It's an independent implementation of the same well-proven ideas (content-defined chunking with FastCDC, dedupe, compression, client-side encryption), exposed as a service with a Go/JS SDK rather than a repo format.

Is restic's encryption weaker or stronger? Neither in practice. Both encrypt client-side with modern authenticated encryption. The difference is operational: restic's protection is always on under one repo password; BaaS encryption is optional per backup with a passphrase-protected keyfile. In both, lose the secret and the data is gone. That's what client-side means.

Can I migrate from restic to BaaS? There's no repo-format import: restore from restic to disk, then back the files up with the SDK. For database workflows, migration is usually just repointing the "after the dump" step: the pg_dump half of your pipeline doesn't change.

Don't wrappers like resticprofile or backrest close the gap? They meaningfully improve scheduling and config, and backrest adds a UI. You still bring the storage backend, the monitoring, the maintenance jobs, and the shared-password model. The wrapper polishes the tool; it doesn't run the system for you.

What's the fastest way to compare for real? Both are free to try: restic init against a local folder, and a 5 GB free BaaS workspace at backupdata.io. Back up the same dump with each and see which workflow your team actually keeps.

Try the free tier: backupdata.io offers 5 GB, no card, first verified snapshot in ~10 minutes via the quickstart.