Aus der Werkstatt
Backups, die im Ernstfall funktionieren: restic und Storj für einen Docker-Stack
Die meisten Sicherungskonzepte, die uns bei Übernahmen begegnen, haben denselben Fehler: Sie sichern etwas, aber niemand weiß, ob sich daraus je wieder ein laufendes System machen ließe. Der Unterschied zwischen einer Kopie und einem Backup liegt genau dort.
Die vier Eigenschaften, die zählen
Bevor es um Werkzeuge geht, die Anforderungen. Ein Backup ist erst dann eines, wenn es alle vier erfüllt:
- Außer Haus. Eine Sicherung auf derselben Maschine schützt vor gelöschten Dateien, nicht vor Brand, Diebstahl oder einem kompromittierten Server.
- Verschlüsselt vor dem Verlassen des Servers. Wenn der Speicheranbieter die Daten lesen kann, haben Sie Ihr Datenschutzproblem nur verlagert.
- Versioniert. Ransomware verschlüsselt Ihre Daten und wartet. Wer nur den letzten Stand hat, sichert irgendwann die Verschlüsselung mit. Sie brauchen mehrere Zeitpunkte über mehrere Wochen.
- Überwacht. Ein Sicherungslauf, der seit sechs Wochen scheitert und niemandem auffällt, ist schlimmer als keiner — er erzeugt Sicherheit, die nicht existiert.
Warum restic
restic erfüllt die ersten drei Punkte von Haus aus: Es verschlüsselt clientseitig, arbeitet mit Deduplizierung über Snapshots hinweg und spricht direkt mit S3-kompatiblem Objektspeicher. Es ist ein einzelnes Programm ohne Serverkomponente, was für einen kleinen Betrieb genau die richtige Menge an beweglichen Teilen ist.
Als Ziel nutzen wir Storj, weil der Speicher verteilt liegt, S3-kompatibel ansprechbar ist und die Preise für Datenmengen dieser Größenordnung berechenbar bleiben. Austauschbar ist das ohne Weiteres — die S3-Kompatibilität ist der Punkt, nicht der konkrete Anbieter.
Der Teil, den fast alle falsch machen: Datenbanken
Eine laufende Datenbank einfach mitzukopieren, erzeugt eine Datei, die es so nie gegeben hat. Zwischen dem Beginn und dem Ende des Kopiervorgangs schreibt die Datenbank weiter, und was Sie sichern, ist ein Zustand, den kein Zeitpunkt jemals hatte. Beim Zurückspielen merkt man das im schlechtesten Moment.
Richtig ist ein logischer Abzug über das Werkzeug der Datenbank selbst, der einen in sich konsistenten Stand liefert. Bei Anwendungen, deren Dateien und Datenbank zusammengehören, kommt eine zweite Anforderung dazu: Beides muss denselben Zeitpunkt abbilden.
Wir lösen das über ein Wartungsfenster — die Anwendung wird kurz in den Wartungsmodus versetzt, der Datenbankabzug läuft innerhalb dieses Fensters, dann werden Dateien und Abzug gemeinsam gesichert. Entscheidend ist dabei die Absicherung: Der Wartungsmodus muss auch dann zuverlässig wieder abgeschaltet werden, wenn der Sicherungslauf mittendrin abbricht. Sonst tauschen Sie ein Datenproblem gegen einen stillen Ausfall.
Automatisierung und Alarm
Der Lauf gehört in einen Timer des Betriebssystems, nicht in ein Skript, an das sich jemand erinnern muss. Wichtiger als der Zeitplan ist die Fehlerbehandlung: Schlägt der Lauf fehl, muss eine Nachricht bei einem Menschen ankommen — bei uns in einem Chatraum, den ohnehin jeder liest.
Eine Stolperstelle aus der Praxis: Bei systemd gehört die Verknüpfung mit dem Alarmdienst in den Unit-Abschnitt der Konfiguration. Steht sie im Service-Abschnitt, wird sie stillschweigend ignoriert — die Sicherung scheitert dann genauso lautlos wie vorher, nur mit dem guten Gefühl, eine Benachrichtigung eingerichtet zu haben.
Ebenso wichtig ist die Aufbewahrungsregel. Wir halten tägliche Stände für zwei Wochen, wöchentliche für zwei Monate und monatliche für ein Jahr. Alte Stände werden automatisch entfernt, sonst wächst der Speicherbedarf unbegrenzt und irgendwann schaltet jemand die Sicherung wegen der Kosten ab.
Der Wiederherstellungstest
Hier trennt sich Konzept von Wunschdenken. Planen Sie zweimal im Jahr einen Termin, an dem eine Sicherung auf einem frischen Server tatsächlich zurückgespielt wird — vollständig, bis die Anwendung läuft und jemand sich einloggen kann.
Was dieser Test regelmäßig zutage fördert, ist selten das Backup selbst. Es sind die Dinge daneben: eine Konfigurationsdatei, die nur auf dem alten Server lag, ein Zertifikat, das niemand gesichert hat, ein Zugangsschlüssel, der im Kopf einer einzelnen Person existierte. Genau deshalb ist der Test wertvoll.
Halten Sie zusätzlich zwei Zahlen schriftlich fest: wie viele Daten Sie im schlimmsten Fall verlieren dürfen und wie lange die Wiederherstellung dauern darf. Ohne diese beiden Zahlen lässt sich nicht beurteilen, ob ein Sicherungskonzept ausreicht — mit ihnen wird die Frage in zehn Minuten entschieden.
Häufige Fragen
Reicht das Backup unseres Hosters nicht aus?
Meist nicht allein. Hoster-Snapshots liegen in derselben Infrastruktur, sind selten verschlüsselt in Ihrer Hoheit und haben oft kurze Aufbewahrungsfristen. Als zusätzliche Ebene sind sie nützlich, als einzige Sicherung sind sie riskant.
Wie viel kostet so eine Lösung im Betrieb?
Der Speicher ist bei den Datenmengen kleiner Unternehmen der geringste Posten — meist einstellige Beträge pro Monat. Der eigentliche Aufwand steckt in der einmaligen Einrichtung und in den halbjährlichen Wiederherstellungstests.
Können Sie unser bestehendes Backup prüfen?
Ja. Eine Bestandsaufnahme mit anschließendem Wiederherstellungstest ist überschaubar im Aufwand und liefert eine belastbare Aussage darüber, ob Ihre Sicherung im Ernstfall trägt.