Open-source backup, honestly reviewed. No marketing fluff, just what you get when you stop paying for something that should be a solved problem.

TL;DR

What it is: A command-line backup program — fast, encrypted, deduplicated, cross-platform. One binary, no daemon, no server required [README].
Who it’s for: Developers, sysadmins, and technically-capable founders who want serious backup infrastructure without trusting their data to a SaaS vendor or paying per-seat backup licensing fees [1][2].
Cost savings: Veeam, Acronis, and CrashPlan charge $50–$300+/year per machine for backup software. restic is $0, forever. You only pay for the storage backend, which can be as cheap as $6/TB/month on Backblaze B2 [2][README].
Key strength: Encryption is non-negotiable by default — every repository is AES-256 encrypted before a single byte touches remote storage. The author’s security model explicitly assumes the storage backend is untrusted [README][1].
Key weakness: No built-in web UI. Pure CLI. Non-technical users will find it opaque without a wrapper like Backrest or Zerobyte, and those are still early-stage projects [3][4].

What is restic

restic is a backup program written in Go. It takes a directory, encrypts it with a password you control, chunks it into content-addressed blocks, deduplicates against everything already in the repository, and ships the result to whatever backend you point it at — a local disk, an SSH server, S3, Backblaze B2, Azure Blob Storage, Google Cloud Storage, or anything else rclone can reach [README].

The pitch from the GitHub README is three words: “Fast, secure, efficient.” That’s actually accurate and not underselling it. What separates restic from most backup tools is its threat model: the repository format is designed with the assumption that the storage provider is not trusted. Your backups are encrypted client-side before upload, using a key that never leaves your machine [README][1]. A compromised Backblaze account doesn’t mean compromised data. A rogue storage admin can’t read your files.

The project has been running since around 2014, sits at 32,727 GitHub stars, and released version 0.18.1 in September 2025 [website]. It’s licensed under BSD-2-Clause, which is about as permissive as open-source licenses get — no CLA drama, no “fair-code” gotchas, no commercial use restrictions [README].

What restic is not: a backup service, a GUI application, or a replacement for a full backup strategy. It is a backup engine. You build the strategy around it (scheduling via cron or systemd timers, retention policies via restic forget --prune, verification via restic check). The tool gives you the primitives; you wire them together.

Why people choose it

Neil Brown’s July 2024 write-up [1] is the most honest practitioner account available, and it lands on a specific point worth quoting directly: he switched to restic after rsync proved insufficient because rsync doesn’t version, doesn’t encrypt, and doesn’t deduplicate. His two real-world tests are the kind that actually matter. First, a server migration using restic backups exposed gaps in his own backup coverage — missing PHP configs and crontabs he hadn’t realized weren’t backed up. The tool works precisely enough that you find out what you missed. Second, after accidentally deleting his home directory during migration, he restored everything within 15 minutes [1]. That’s the proof point for any backup tool: how long does it actually take to recover?

The DigitalOcean tutorial [2] focuses on the object storage angle — restic’s ability to push encrypted incremental backups to Spaces or any S3-compatible service. This matters for the server operator crowd: rather than paying for managed backup software, you run restic on a cron job, push to B2 at $6/TB/month, and you have encrypted, versioned, deduplicated backups with retention policies. The tutorial dates from 2017, which is itself a signal — the tool’s interface hasn’t radically changed since then.

The pattern across all sources is the same: restic earns trust through correctness and transparency. The repository format is fully documented. The cryptography is standard (AES-256-CTR, Poly1305-AES for authentication, SHA-256 for content addressing). One review notes that detailed repository format documentation exists so “the project could be maintained by others if abandoned” [1] — that’s the kind of thing an engineer notices when they’re betting data on a tool.

The community also acknowledges the CLI barrier honestly. The linuxlinks.com roundup [4] lists at least six different GUI frontends that exist specifically because enough people wanted restic’s engine without living in the terminal: Backrest, Zerobyte, Restic Browser, resticterm, kubackup, Resticity, and Restic Backup GX. The number of GUIs is a proxy metric for how much the underlying tool is trusted — nobody builds a GUI wrapper for something they don’t believe in.

Features

Core backup operations:

Full, incremental, and snapshot-based backups via content-defined chunking [README]
Deduplication across all snapshots in a repository — store the same file once regardless of how many snapshots reference it [README]
AES-256-CTR encryption with password or key file; encryption happens before any data touches the backend [README][1]
Cross-platform single binary: Linux, macOS, Windows, FreeBSD, OpenBSD [README]
restic mount — mount any snapshot as a FUSE filesystem to browse and restore individual files [README]
restic restore — selective file restoration without downloading the entire snapshot [README]
restic check — verify repository integrity and that all data can be read back [README][1]

Retention and pruning:

restic forget --prune with flexible policies: keep last N snapshots, keep daily/weekly/monthly/yearly snapshots, keep everything within a time window [2]
Policies can be applied per host or per tag if you’re backing up multiple machines to one repository

Storage backends (native):

Local directory
SFTP (via SSH)
HTTP REST server (the companion rest-server project)
Amazon S3 and S3-compatible (Minio, Wasabi, DigitalOcean Spaces, Backblaze B2 via S3 API)
Backblaze B2 (native)
Microsoft Azure Blob Storage
Google Cloud Storage
OpenStack Swift
Everything else via rclone [README]

Security model specifics:

Content-addressed storage: each chunk is identified by its SHA-256 hash, making tampering detectable [README]
Reproducible builds starting at version 0.6.1 — you can verify the released binary matches the source [README]
Append-only repository mode exists for limiting what a compromised client can do to existing backups (the gap Neil Brown [1] flags — without append-only, a compromised backup client machine could delete the remote repository)

What’s missing from the core tool:

No scheduler — you use cron, systemd timers, or a wrapper like Backrest
No web UI — pure CLI (see GUI frontends in the article above)
No centralized multi-machine dashboard without third-party tooling

Pricing: SaaS vs self-hosted math

restic the software costs $0. The cost question is entirely about storage backend and optionally backup software if you were previously paying for that.

If you were paying for backup software:

Product	Price	What you get
Veeam Agent	$80–$200/year per machine	GUI, scheduling, Windows-first
Acronis Cyber Protect	$49.99/year for 1 device (500GB cloud)	GUI, cloud bundled
CrashPlan for Small Business	~$10/month per machine	Cloud backup, no local control
restic	$0	CLI, bring your own storage

Storage costs if you were paying a managed backup service:

Storage backend	Price
Backblaze B2	$6/TB/month
Wasabi	$6.99/TB/month
AWS S3 Standard	~$23/TB/month
DigitalOcean Spaces	$5/month for 250GB

Concrete example [2]: A developer backing up 50GB of application data and databases to Backblaze B2 with restic: $0 software + ~$0.30/month storage + your cron job. That’s essentially free. With CrashPlan for Small Business, that’s $10/month, $120/year, for similar functionality but with the vendor controlling your data and pricing.

For someone running three servers with 500GB of total backup data: restic + B2 = $3/month. CrashPlan at $10/machine = $30/month, $360/year. The savings are $324/year and you own the encryption keys.

The catch: these numbers assume you already know how to write a cron job and set up a B2 bucket with appropriate IAM permissions [5]. That’s real work. The AWS IAM setup alone — creating the bucket, creating the user, writing the policy JSON — is covered in multi-step tutorial form [5] for a reason.

Deployment reality check

What you actually need to run restic:

A machine with any OS (Linux/macOS/Windows all work)
The restic binary (single file, no dependencies)
A password you won’t forget — losing it means the data is gone permanently [README]
A storage backend (local disk counts; remote adds the bucket/credentials setup)

The install path is genuinely simple: download the binary, make it executable, run restic init --repo /your/repo. First backup is restic backup /path/to/data. That’s the entire onboarding flow for local or SFTP [README]. Cloud storage backends require setting environment variables for credentials before init.

Where things get non-trivial:

The IAM permission setup for S3 is the most common stumbling block. The DigitalOcean tutorial [5] walks through creating a bucket, a dedicated IAM user, and a custom policy with exactly the right permissions (DeleteObject, GetObject, PutObject for objects, ListBucket, GetBucketLocation for the bucket itself). It takes 20–30 minutes the first time. If you get the policy wrong, restic gives you a somewhat opaque access-denied error.

The security gap Neil Brown [1] flagged is worth understanding: by default, the restic client that has access to the repository also has permission to delete snapshots. If an attacker gets onto the machine you’re backing up, they can potentially destroy the remote backups as well. The mitigation is Backblaze B2’s Object Lock feature or running a REST server in append-only mode — both are real solutions, but neither is the default, and neither is mentioned in the basic docs.

Scheduling is a non-feature of restic itself. On Linux, you write a systemd timer or cron job. On macOS, a launchd plist. On Windows, Task Scheduler. None of this is hard for a technical user, but it’s also not something you get out of the box.

Time estimates: A technical user who has deployed server software before: 15–30 minutes to first encrypted backup on a remote backend. A non-technical founder who is learning S3 and cron simultaneously: budget half a day, and accept that you’ll need to test restore before trusting it.

The GUI layer: If the CLI is a blocker, Zerobyte [3] is the most complete current option — it wraps restic in a web UI with job scheduling, repository management, and snapshot browsing. The caveat from bitdoze.com [3] is direct: Zerobyte is still in the 0.x series, expect breaking changes between versions. Backrest (listed in the LinuxLinks roundup [4]) is another option and is further along. Neither is production-stable in the way restic itself is.

Pros and cons

Pros

Encryption is non-negotiable and client-side. The storage backend is treated as untrusted by design. Your data is encrypted before any of it leaves your machine [README][1]. This matters most when using shared or third-party storage.
Genuinely cross-platform. One tool, one repository format, on Linux, macOS, Windows, FreeBSD, and OpenBSD [README]. A developer who switches between machines doesn’t need multiple backup tools.
Wide backend support. Local, SSH, S3, B2, Azure, GCS, rclone’s entire universe — you can point restic at essentially any storage service [README][2].
Deduplication actually works. Content-defined chunking means restic doesn’t re-upload unchanged data. Incremental backups are fast and storage-efficient [README].
Verifiable. restic check verifies the repository’s integrity. The cryptographic design makes tampering detectable [README][1].
Documented repository format. If the project dies, the format is documented well enough that recovery tools could be built independently [1]. That’s a real argument for long-term data safety.
BSD-2-Clause license. No commercial restrictions, no CLA, no ambiguity [README].
32,727 GitHub stars. Long-running project, stable interface, not going anywhere [merged profile].
Reproducible builds since v0.6.1 — you can verify the binary you downloaded matches the source [README].

Cons

No web UI in the base tool. Pure CLI. Non-technical users need a wrapper, and the available wrappers (Zerobyte, Backrest) are younger and less stable than restic itself [3][4].
Password loss = permanent data loss. There is no account recovery, no support ticket to file. The encryption is real [README]. You need to store the password somewhere safe and separately from the backup.
The ransomware/append-only gap is real. The default setup gives the backup client full delete rights to the repository. A compromised machine can destroy its own backups [1]. Mitigating this requires intentional configuration.
No built-in scheduler. You wire up cron/systemd/launchd yourself [README]. For a developer this is trivial; for a non-technical founder this is a barrier.
S3/cloud backend setup has friction. IAM policies, credential management, environment variables — it’s not hard, but it’s a real setup step that the “single binary” framing somewhat undersells [5].
No centralized multi-machine dashboard. If you’re backing up 10 servers, you have no single view of whether all backups ran successfully without third-party tooling.
Restic doesn’t alert on backup failure by itself. Silently missed backups are a real risk unless you add notification logic to your scripts. The Zerobyte wrapper [3] includes notification support precisely because this matters.

Who should use this / who shouldn’t

Use restic if:

You’re a developer or sysadmin who is comfortable with the command line and wants reliable, encrypted, deduplicated backups for servers or workstations.
You’re running a homelab or VPS and your current backup strategy is “sometimes I copy files around.”
You want to stop paying for per-seat backup software or managed backup services and you’re willing to manage storage separately.
Data sovereignty matters to you — you want encryption keys that never leave your control.
You’re building backup infrastructure for multiple machines and want a single consistent tool across Linux, macOS, and Windows.

Try it with a GUI wrapper (Backrest or Zerobyte) if:

You trust the underlying restic engine but don’t want to manage cron jobs and script notifications from scratch.
You want a web interface to verify snapshots ran without SSH-ing into each server.
Be aware both wrappers are younger than restic itself and carry more operational risk [3][4].

Skip it for now if:

You’re a non-technical founder with no command-line experience and no one on your team who can set up and maintain cron jobs and cloud storage IAM.
You need a polished point-and-click GUI on day one — the backup SaaS options (Backblaze Personal Backup, iCloud, Acronis) will be more reliable for you at the cost of the monthly fee.
You need centralized backup monitoring across a large number of machines — look at Bacula or Amanda for enterprise-scale scenarios.

Alternatives worth considering

Borg Backup — the closest technical comparison. Also deduplicating, encrypted, and CLI-first. BorgBase offers managed hosting. Slightly different design decisions (Borg uses a more sophisticated chunking algorithm; restic’s content-addressed storage is simpler and arguably more auditable). Both are serious tools.
Duplicati — GUI-first, cross-platform, free. Less performant than restic for large repositories. Good option for non-technical users who want a backup GUI without a subscription.
rclone — covers the sync/copy layer and pairs well with restic (restic can use rclone as a backend). rclone alone is not a backup tool — it doesn’t version, deduplicate, or encrypt by default.
Veeam / Acronis — commercial backup software. Better GUIs, dedicated support, per-seat cost. Justified if your compliance requirements or team size warrant it.
Backblaze Personal Backup — $99/year for unlimited personal backup from one machine. Genuinely good for individual workstation backup. Not available for Linux servers. No encryption key control.
Backrest — not an alternative to restic, but the most feature-complete open-source GUI wrapper for restic (mentioned in [4]). Worth evaluating before building your own scheduling scripts.

For a technical founder or developer evaluating open-source options, the realistic shortlist is restic vs Borg. Both are serious, both are actively maintained, both have been around for years. Pick restic if you value simpler repository tooling and broader language ecosystem (Go, single binary). Pick Borg if you want slightly better large-file deduplication or are already in a community that uses it.

Bottom line

restic has 32,727 GitHub stars and a user who restored their accidentally-deleted home directory in 15 minutes [1]. That’s the review. The tool does what it says: fast encrypted deduplicated backups to wherever you point it, with a repository format that’s been stable and documented for years. The CLI is not a bug — it’s the reason the tool composes cleanly into whatever automation you’re building. The gaps are real: no built-in scheduler, no alerting, no GUI, and a security model that requires intentional append-only configuration to prevent a compromised backup client from destroying its own backups [1]. None of these are blockers for a technical user who reads the docs before deploying. For everyone else, the combination of restic plus Zerobyte or Backrest gets you most of the way there, with the caveat that both GUI layers are younger and less stable than the engine underneath them [3][4]. If you’re currently paying $10–$30/month per machine for managed backup software, the math to switch is obvious. The setup time is an afternoon; the savings are indefinite.