der Uninformat

Backups sind lästig. Aber leider notwendig, denn auch ohne plötzlich auftauchende Finsterlinge, die eine Festplatte mit einem Axthieb sauber in zwei Teile aufteilen (siehe Bild), ist das Risiko eines Datenverlustes durch einen defekten Datenträger immer gegeben. Und wenn es passiert, sind all‘ die schönen digitalen Sachen weg…

Heutzutage möchte man Backups auch irgendwo auf einem Server oder gar »in der Cloud« haben. Dafür habe ich kürzlich zufällig das perfekte Werkzeug gefunden: Restic.

(Photo by Markus Spiske on Unsplash, thanx!)

Backup-Strategie

Meine »Backup-Strategie« ist im Großen und Ganzen noch stets so, wie ich das vor 13 Jahren schon einmal in einem durchaus meinungsstarken Text ausgeführt habe. Heutzutage wird alles was »Arbeit« in Form von Code und Texten ist natürlich nicht mehr mit Subversion, sondern mit git versioniert und nach getaner Arbeit auf einen externen Server gepusht. Eine lokale Sicherung mit rsync auf eine externe Platte halte ich auch noch vor. Im Laufe der Jahre kamen noch die OSX/MacOS-Time Machine und ein regelmäßig aktualisiertes bootfähiges Backup mit »SuperDuper!« hinzu.

Das reicht aus an lokalen Sicherungen. Wenn allerdings ein flammender Meteorit aus den Weiten des Alls auf das Arbeitszimmer mit den externen Festplatten fällt, nützt das nicht viel. Man braucht noch ein aktuelles Backup irgendwo anders.

Da bietet sich die Cloud oder ein mit viel Platz ausgestatteter Server irgendwo im Internetz an. Das Problem dabei: Die Daten leben auf diesen Orten in der latenten Gefahr, dass irgendwer mal draufguckt, der das nicht soll. Also muss alles verschlüsselt abgelegt werden…

Deshalb hatte ich mit verschiedenen Sachen experimentiert wie »Mounten eines verschlüsselten Laufwerks auf dem Server und dann mit rsync alles reinkopieren«, was aber unzuverlässig lief oder zu kompliziert im Handling war und deshalb zu selten benutzt wurde.

Letztens fand ich beim Rumsuchen im Internetz (natürlich nach etwas völlig anderem…) das ultimative Werkzeug für Remote-Backups: Restic.

Backups mit Restic

Restic ist ein in Go geschriebenes Kommandozeilen-Programm, das für alle gängigen Systeme erhältlich ist.

Die Terminologie bei Restic ähnelt ein wenig Versionskontrollsystemen wie git. Man muss zunächst ein »Repo« anlegen und initialisieren, in das man dann seine Backups kopieren kann. Diese werden in »Snapshots« abgelegt, ähnlich den Commits in git.

Restic kann seine Repos auf einem lokalen Datenträger oder allerlei (Cloud-)Diensten im Internet anlegen. Bei mir ist das ein sftp-Zugang zu einem Server. Wenn das Repo für den Benutzer »baku« (für den man einen SSH-Key anlegt, um nicht jedes mal das SSH-Passwort eingeben zu müssen) auf dem Server »server.mit.platz« in einem Verzeichnis »backup« in des Users Homeverzeichnis angelegt werden soll, so würde man das Repo so initialisieren:

  restic -r sftp:baku@server.mit.platz:/home/baku/backup init

Dabei muss man ein Passwort vergeben, das man sich gut merken sollte, denn ohne dieses kann man die Backups nicht mehr entschlüsseln…

Damit sind die Vorbereitungen schon abgeschlossen und man kann nun Verzeichnisse in dieses Repo sichern. Den Ordner "wichtiges" im Homeverzeichnis sichert man z.B. mit:

  restic -r sftp:baku@server.mit.platz:/home/baku/backup backup \
   /Users/ralf/wichtiges

Um nicht immer mit dem etwas unhandlichen Repo-Ort und dem Passwort hantieren zu müssen, kann man den Ort des Repos und das Passwort in Umgebungsvariablen speichern. Ich habe das in ein kleines Shell-Skript namens machdasbackup.sh gepackt, das so aussieht:

 export RESTIC_REPOSITORY="sftp:baku@server.mit.platz:/home/baku/backup"
 export RESTIC_PASSWORD="DASPASSWORT"

 restic backup \
  /Users/ralf/wichtiges \
  /Users/ralf/auch_wichtig \
  /Users/ralf/noch_mehr_wichtiges \

Dieses Skript führt man nun regelmäßig aus, oder automatisiert es gar mit Cron o.ä. Damit steht dem regelmäßigen Remote-Backup nichts mehr im Wege.

Wiederherstellung der Daten

Das schönste Backup nützt natürlich nix, wenn man im Falle eines Falles nicht an die gesicherten Daten herankommt. Dafür bietet Restic zwei Wege an:

Mounten des Backups

Sehr praktisch wenn man mal eben aus dem Backup nur bestimmte Dateien zurückholen muss: Man legt sich einen Mountpoint an (so wie /Users/ralf/bakmount) und mountet das Restic-Repo wie ein externes Laufwerk, in dem man dann mit den normalen Werkzeugen des Dateisystems arbeiten kann:

  restic -r sftp:baku@server.mit.platz:/baku/backup mount /Users/ralf/bakmount

Wiederherstellen eines kompletten Verzeichnisses

Dazu muss man sich zunächst die im Repo verfügbaren Backups (die »Snapshots«) ausgeben lassen:

  restic -r sftp:baku@server.mit.platz:/baku/backup snapshots

Jeder Snapshot hat eine ID wie »562bfc5e«, mit der kann man sich dieses Backup zurückholen:

  restic -r sftp:baku@server.mit.platz:/baku/backup \
   restore 562bfc5e --target /das_zielverzeichnis

Ich habe beides mal ausprobiert, scheint zu funktionieren…

Fazit

Nach dem Erst-Backup, das je nach Datenvolumen eine zeitlang dauern kann, gehen die nächsten Backups schneller, da Restic Deduplizierung beherrscht.

Wenn man Restic einsetzen möchte, ist eine Lektüre der hervorragenden Dokumentation zu empfehlen. Und das mit dem Wiederherstellen sollte man selbstverständlich einmal ausprobieren und im Zweifelsfall die Schritte notieren, damit man sich nicht im erst im Notfall mit dem Konzept der Snapshots und ihrer Wiederherstellung vertraut machen muss…