Why backups are more than routine
In a time when almost everything is stored digitally, data backup is no longer an afterthought - it is digital self-defense. Whether family photos, tax documents or your own development projects: The availability of this data determines memories, obligations and sometimes even existence.
Most people rely – consciously or unconsciously – on central cloud providers. But this entails several risks: technological, legal and psychological.
Clouds are convenient. But they shift responsibility. They suggest security, while at their core they only guarantee availability. This is not a backup.
Shared Responsibility: Responsibility with footnotes
The terms and conditions of almost all cloud platforms contain a similar passage:
“The customer is responsible for backing up and restoring their data.”
This is called the Shared Responsibility Model. The provider provides electricity, hardware and accessibility - everything else remains your responsibility.
This is understandable from the provider’s perspective: They have no way of knowing whether a file was deleted because you intentionally removed it or because an account was compromised. Therefore, backup remains your duty.
The physical boundary of the cloud
Even if you rely on cloud backup: How realistic is a full recovery over a normal internet connection?
Downloading a terabyte over a 50 Mbit line ideally takes over 2 days. Without failures, without throttling. This is not a backup strategy – this is a test of patience.
A physical backup, on the other hand, is tangible, quick and verifiable. You can pick up the hard drive, connect it, and restore it immediately.
Restic: Tool for tangible security
Restic is an open source backup tool that started in 2015 with a simple idea: Backups should be simple, secure and verifiable – and work on any system.
Today Restic is a reference project for robust, decentralized data backup. It runs on Linux, macOS and Windows, requires no database, no cloud connection, no license keys.
- Written in Go – compiled for all platforms with no dependencies.
- Fully encrypted and deduplicated.
- Stores backups as object-based repositories (similar to Git).
- Works reliably on local media, via SSH, S3 or Rclone.
Official Sources:
- 🌐 restic.net – Project page and documentation
- 💻 github.com/restic/restic – Source code and releases
- 📖 forum.restic.net – Community and discussion
- 📚 restic.readthedocs.io – detailed technical documentation
How Restic works
Restic does not simply save the backup as a copy. It divides all data into small blocks (blobs), hashes them with SHA-256 and stores them encrypted. This means Restic detects duplicate data immediately and only saves it once.
This saves storage space and significantly speeds up incremental backups. Each backup is a complete “snapshot” of the data state, but without redundant copies of identical files.
Cryptographic Architecture: Why Restic is Hard to Crack
Restic encrypts all content – including metadata – using state-of-the-art cryptography:
- AES-256 in Counter Mode (CTR) for data encryption
- Poly1305 for message authentication
- PBKDF2 (Password-Based Key Derivation Function 2) with high work factor for password derivation
- Salted Key Derivation: each repository has its own randomly generated salt
- HMAC-SHA256 for integrity checking of each saved object
This means: even if someone steals your data carrier, it only has random bytes - without a password there is no chance of decryption.
The cost of a brute force attack is exponential: Each attempt costs energy and time - and the PBKDF2 iteration artificially slows down each candidate. Even if the hardware was accessed, a successful attack would be virtually impossible.
Restic in practice
A typical backup workflow on a Linux home server:
export RESTIC_REPOSITORY=/mnt/backup/restic_repo
export RESTIC_PASSWORD_FILE=/etc/restic_password.txt
restic init
restic backup /srv/data --tag homeserver
restic snapshots
Each run automatically creates a new snapshot. These snapshots can be compared, deleted or restored at any time:
restic restore latest --target /wiederhergestellt
/etc/restic_password.txt) should only exist on the server.
It is not saved on the backup media itself. When restoring it is entered manually.
Media rotation and physical resilience
A backup is only as resilient as its carrier material. That’s why a rotating backup strategy is recommended - at least three disks, preferably more.
| Duration | Medium | Location |
|---|---|---|
| Week 1 | A | Home (active) |
| Week 2 | B | with family/friends |
| Week 3 | C | outsourced (e.g. office, bank locker) |
If there are four or five media items, a “long-term archive” can be added annually.
Media choice, bitrot and durability
Data ages – even without use. Magnetic hard drives can develop bad sectors after years, SSDs lose charge in flash cells.
That’s why: Backups are a process, not a state.
A regular check run (restic check) detects damaged blobs at an early stage.
This allows you to react before data is irretrievably lost.
- Use different manufacturers and series.
- Perform regular integrity checks with
restic check. - Replace media as scheduled after 3-5 years.
exFAT: Easy interoperability
If different systems are involved - Linux, Windows, macOS - exFAT is a suitable file system. It is universally readable and writable, supports large files, and is natively supported by modern systems.
For data carriers that are regularly exchanged or transported, exFAT 2025 is the most practical option.
umount) to avoid data loss.
Automation on the home server
A cron job or systemd timer is often enough to run the backup automatically:
#!/bin/sh
DEVICE=$(/sbin/blkid -t PARTLABEL="backup" -o device)
MOUNTPOINT="/mnt/backup"
mount -t exfat $DEVICE $MOUNTPOINT
restic backup /srv/data --repo $MOUNTPOINT/restic_repo --password-file /etc/restic_password.txt --tag auto
umount $MOUNTPOINT
The human factor: understandability in an emergency
A backup is only as valuable as the ability to restore it. That’s why a small README file belongs on every data carrier:
NOTFALLPLAN
1. Backup-Festplatte anschließen.
2. Restic starten:
./restic restore latest --target /wiederhergestellt
3. Passwort eingeben.
4. Daten finden sich anschließend im Ordner /wiederhergestellt.
This step turns a technical backup into a family-compatible backup. In an emergency, no one has to improvise.
Conclusion: Tangible backups as an expression of digital maturity
Clouds are convenient, but they are no substitute for responsibility. If you really want to own your data, you have to be able to physically secure it, encrypt it and verify it.
Restic symbolizes an attitude: Transparency, traceability and independence. A backup is not a hassle - it is proof of true digital sovereignty.