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 ein funktionierendes 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

https://restic.readthedocs.io/en/stable
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.

# 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

https://resticprofile.readthedocs.io/en/stable
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:

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:

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:

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ß!