From 15102e4f6c0995d4fbce4af6cfe0eef40d3330a6 Mon Sep 17 00:00:00 2001 From: marius Date: Sat, 7 Feb 2026 19:10:03 +0100 Subject: [PATCH] article about restic backup system --- .../posts/backups-mit-restic-aber-richtig.md | 90 +++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 content/posts/backups-mit-restic-aber-richtig.md diff --git a/content/posts/backups-mit-restic-aber-richtig.md b/content/posts/backups-mit-restic-aber-richtig.md new file mode 100644 index 0000000..a6589b3 --- /dev/null +++ b/content/posts/backups-mit-restic-aber-richtig.md @@ -0,0 +1,90 @@ +--- +date: '2026-02-07T18:30:00+01:00' +title: 'Backups mit restic – aber richtig!' +--- + +## Einleitung + +Hast du schon einmal so _richtig viele wichtige_ Daten verloren? +Und hätte dir in diesem Moment ein Backup den A\*\*\*\* gerettet? +Hast du ein funktionierendes Backup **und** eine funktionierende Restore?\ + +Wenn du auf die ersten beiden Fragen mit ja oder auf die letzte Frage mit "nein" geantwortet hast, dann möchte ich dir heute eine moderne Variante vorstellen (powered by Rust), die man ganz leicht auf jeder Linux-Maschine installieren kann: restic und resticprofile. + +## Das Prinzip + +Sicher hat man schonmal von der 3-2-1-Regel bei Backups gehört: 3 physisch unabhängige Sicherungen (3 verschiedene Festplatten) auf **2** verschiedenen Medien (SSD + HDD) und **1** davon an einem anderen Standort ("Offsite"). Das klingt nach ziemlichem Aufwand, lässt sich aber mit der hier gezeigten Lösung sehr einfach erreichen. + +Außerdem gibt es noch das Prinzip "Push" vs. "Pull". Beim "pushen" von Backups lädt der zu sichernde Server selbstständig die Daten auf den Backupserver bzw. Storage, beim "pullen" holt der Backupserver sich die Daten vom zu sichernden Server. Beides hat Vor- und Nachteile. Während beim Pushen der Backupserver nicht zwingend ein Server sein muss, sondern auch ein SFTP Fileshare oder S3-Bucket sein kann, verbleiben auf dem zu sichernden Server immer Credentials. Ist der Server also kompromittiert, kann das Backup gleich mit kompromittiert werden vom Angreifer. Beim Pullen muss zwingend immer ein Backupserver installiert werden, dafür bleiben alle Credentials auf diesem Server, der zusätzlich auch noch hinter einer Firewall gesichert werden kann. + +## restic + +\ +Im Grunde ist restic ein CLI-Tool, das verschiedene Ordner auf eurem System in einem Repository sichern kann. Dabei werden die Daten verschlüsselt, versioniert und blockweise dedupliziert. + +```bash +# Repository unter /var/backup erstellen +restic init --repo /var/backup + +# Backup von /home in das repository starten +restic -r /var/backup --verbose backup /home + +``` + +## resticprofile + +\ +Resticprofile ist ein Konfigurationswrapper, der auf restic aufbaut. Mit resticprofile kann man repositories und Backup-Routinen in YAML definieren, anstatt die mühsamen restic-commands immer manuell ausführen zu müssen. Das sieht dann z. B. so aus: + +```yaml +version: "1" +default: + # Hier den Zielordner angeben (S/FTP, s3, rclone, ...). + # Unterstützt ssh-config und passkeys + repository: "sftp:restic@backup-server.test:/route/to/repository" + # Passwort für das Repository. Diese Datei sollte chmod 640 sein + password-file: "password.txt" + backup: + source: # Welche Quellordner sollen gesichert werden? + - "/home" + - "/var/mail" + schedule: "02:30" # Backup täglich 02:30 Uhr nachts ausführen + schedule-permission: user +``` + +Das ist jetzt ein klassisches Push-Setup. Natürlich ist das jetzt bloß die Oberfläche des Eisbergs. Man kann auch Retention einrichten, Logging, Dateien ausschließen, Before- und After-Hooks einrichten, ... + +Zum Pull-Backup gibt es aber auch noch eine weitere Möglichkeit, um das Backup vor unerlaubtem Verschlüsseln oder Löschenvon unserem Host aus zu schützen: Wir können `append-only` einrichten: + + +```yaml +version: "1" +default: + repository: "rclone:" + password-file: "password.txt" + option: + - "rclone.program='ssh restic@backup-server.test'" + backup: + source: + - "/home" + - "/var/mail" + schedule: "02:30" + schedule-permission: user +``` + +Auf dem `backup-server.test` müssen wir jetzt unter dem Nutzer `restic` (bzw. dem backup-user) folgendes in `~/.ssh/authorized_keys` schreiben: + +``` +restrict,command="rclone serve restic --stdio --append-only /path/to/repository" ssh-ed25519 ... +``` +Damit Verbindet sich jetzt unser Server mit unserem Backup-Server und kann nur diesen Command ausführen. Der Command besagt, dass das Backup und jegliche restic-Operationen "append-only" ausgeführt werden. Backups löschen oder verändern von hier aus wird also nix. + +Dabei muss auf keinem Server rclone tatsächlich installiert sein! + +Ein sicheres repository-Passwort generiert man übrigens mit: +```bash +resticprofile generate --random-key +``` +Um das Backup jetzt zu administrieren, kann man sich jetzt (mit einem eigenen Key) auf dem backup-server einloggen und mit den gleichen Rechten und Passwort auf das Repository voll zugreifen. + +Viel Spaß!