Learning Restic - History, Background & Why You Need It
This episode tells the origin story of restic: a community project born in 2016 as an answer to the limitations of tar and rsync. You will also understand why restic is called "backups done right" — global deduplication, built-in AES-256 encryption, immutable snapshots, and support for many backends from S3 to a REST server.
#Introduction
In episode 0 you prepared your environment: the restic 0.19.1 binary installed, the repository directory ready, and automation waiting. Before typing your first command, it is important to understand why this tool exists. Choosing a backup tool is not just about features — it is about trust: will your data really be saved when your server burns down or a disk fails?
This episode answers that question: where restic came from, what problems it solves, and why it was designed as "backups done right".
#History & Philosophy
#Born from the Community, Written in Go
Restic is developed by the open source community and was first released in 2016. Written in Go, restic was designed as a modern alternative to tar and rsync — two tools that are nearly half a century old and have fundamental weaknesses for modern backup workloads.
Its philosophy is simple and firm: backups must be automatic, encrypted, and verifiable. From that came three pillars that define restic's identity — snapshots, deduplication, and encryption — which you will break down one by one starting with episode 2.
#Problems It Solves
Think about traditional backup approaches with tar and rsync:
- No deduplication: backing up an almost identical directory every day means copying the entire data set again — wasting bandwidth and storage.
- No versioning (snapshots): rsync overwrites old files; if a file was corrupted yesterday, today's copy is corrupted too. You cannot "go back in time".
- No built-in encryption: sensitive data (configs, database dumps) is stored in plaintext; once the media is lost or stolen, so is the data.
- Not restore-first: the workflow is designed to push data out, not to prove that data can be brought back.
Restic was built on the opposite principle: restore comes first. Every feature is evaluated with the question "does this make restore more reliable?".
#Why Restic?
#Global Deduplication
Restic splits files into chunks (pieces of data) based on content — not byte position — so identical files, similar files, or files that have simply been moved are stored only once in the repository. The second backup onward only uploads the delta. This mechanism is covered thoroughly in episode 6.
#Built-in AES-256 Encryption
All data is encrypted before it leaves your machine with AES-256. Storage providers, server admins, even a rest-server, cannot read the contents of the repository without the password. The cryptographic details are in episode 13.
#Immutable Snapshots
Every restic backup produces a snapshot — the state of a directory at a certain point in time that cannot be silently altered. Ransomware or human error that changes files will not damage the backup history.
#Multi-Platform & Many Backends
Binaries are available for Linux, macOS, Windows, and BSD — while the backends range from a local directory, SFTP, S3-compatible storage, B2, Azure, GCS, to a REST server. One tool, many targets: from a personal laptop to production servers.
#Restic on the Release Timeline
The release history shows the project's maturity:
- 0.14 (2022): zstd compression with
--compression autobecomes the default. - 0.17 (2024): stabilization and performance fixes.
- 0.18 (2025): lock-free index and ongoing refinements.
- 0.19.0 (Jun 2026): performance & backend improvements.
- 0.19.1 (Jul 2026): fixes & stabilization — the version we use.
A more complete release history is covered in episode 17.
#Conclusion
- Restic was born in 2016 from the open source community, written in Go.
- It answers the weaknesses of tar/rsync: no dedup, no versioning, no encryption.
- Its core philosophy is restore-first: designed to prove data can come back.
- Global deduplication, built-in AES-256, immutable snapshots, multi-platform.
- Release 0.19.1 (July 2026) is the current stable version we use.
In the next episode, episode 2, we break down the core concepts & key architecture — repository, snapshot, and content-defined chunking, plus the repository directory structure and the data flow from source files to encrypted blobs. After this episode, you will not just "run commands" but understand what is happening behind the scenes.