#Backup

Eine Archivplatte hängt man nicht einfach ein, wenn sie garantiert unverändert bleiben soll. Ich wollte eine alte Linux-Platte am Mac auslesen, und schon das reine Einhängen schreibt ins Journal des Dateisystems. Stattdessen habe ich mit debugfs nur lesend auf das Rohgerät zugegriffen und die Daten mit konstant rund siebzehn Megabyte je Sekunde herausgezogen, ohne ein einziges Byte auf der Platte zu ändern. Wer nur lesen will, sollte sich auch kein Schreibrecht in die Hand geben lassen.

Der Restzeit-Anzeige eines Kopiervorgangs kann man am Anfang nicht trauen, jedenfalls nicht bei gemischten Dateigrößen. Beim Auslesen einer Archivplatte lag der Durchsatz die ganze Zeit konstant bei rund siebzehn Megabyte je Sekunde, aber sobald die großen Rohbilder durch waren, stieg die Zahl der fertigen Dateien pro Minute auf das Siebenfache. Jede frühe Hochrechnung war damit wertlos. Ein Mittelwert aus dem ersten Zehntel sagt nichts über den Rest, wenn die Brocken ungleich groß sind.

Vier Kopien einer Datei sind keine Sicherung, wenn die Datei schon beim ersten Kopieren kaputt war. Beim Sichten der alten Platten fand ich 61 Dateien mit null Byte Inhalt, und sie waren auf allen vier Platten gleich leer, darunter ein komplettes Fotoshooting von 2007. Kopiert wurde jahrelang brav weiter, geprüft hatte nie jemand. Eine Prüfsumme ist mehr wert als die dritte Kopie, denn Kopien vervielfältigen auch den Schaden.

Ein neuer Dienst ist nicht automatisch mit gesichert, nur weil der Server gesichert wird. Unser Bildarchiv Immich erzwingt eine eigene PostgreSQL-Instanz mit Vektor-Erweiterung und läuft deshalb neben dem zentralen Cluster, den pgBackRest jede Nacht wegschreibt. Diese eine Datenbank sah die Sicherung schlicht nicht. Die Bilddateien lagen längst doppelt, aber die Zuordnung von 35.986 Aufnahmen zu Alben und Personen hing an einer ungesicherten Datenbank. Jeder neue Dienst bringt seine eigene Datenhaltung mit, und was die Sicherung nicht kennt, sichert sie nicht.

Gesichert ist ein Fotoarchiv erst, wenn auch die Ordnung mitgesichert wird, nicht nur die Bilddateien. Bei der Planung unseres Bildarchivs mit Immich liegen die knapp sechsunddreißigtausend Aufnahmen auf dem gesicherten Speicher, die Datenbank mit Alben, Orten und Gesichtern aber lokal auf der SSD und fiel damit aus der Sicherung heraus. Ohne sie hätte ich nach einem Ausfall dreihundert Gigabyte namenlose Dateien. Der Wert eines Archivs steckt nicht in den Dateien, sondern darin, dass man wiederfindet, was man sucht.

Eine Sicherung, die jemand erst anstecken muss, taugt nur so weit wie die Gewohnheit dahinter. Unser Borg-Lauf schreibt auf eine externe Platte, und weil die monatelang nicht am Rechner hing, kam einhundertsiebzehn Tage lang keine einzige Sicherung durch, 404 Fehlversuche im Protokoll, die niemand gelesen hat. Time Machine stand ohne Ziel daneben. Erst als ich die Platte wieder ansteckte, lief alles durch. Eine Sicherung, die an einem Handgriff hängt, ist ein Vorsatz und keine Sicherung.

Im Ordner zu stehen heißt nicht, dass eine Datei wirklich auf dem Rechner liegt. Moderne Cloud-Ordner zeigen Platzhalter, die den vollen Namen und die volle Größe melden, obwohl lokal kein einziges Byte liegt. Bei unserem Nextcloud-Umzug habe ich das erst bemerkt, als ich statt der angezeigten Größe die tatsächlich belegten Blöcke abgefragt habe: ein großer Teil des Ordners war Fassade. Wer so einen Ordner sichert, sichert Namen, keine Daten.

Null kopierte Dateien heißt nicht, dass die Sicherung steht, es kann schlicht der Betriebsrhythmus sein. Unser Abgleich in den externen, unveränderlichen Speicher meldete über Tage null neue Dokumente, und ich war schon dabei, den Fehler zu suchen: es war Wochenende, und samstags wie sonntags scannt in der Werkstatt niemand. Die Gegenprobe war nicht das Protokoll des Absenders, sondern die Dateiliste am Ziel. Eine Sicherung beweist man dort, wo sie ankommt, nicht dort, wo sie losgeschickt wird.

Wenn eine Übertragung mittendrin abbricht, bleibt eine unbrauchbare Datei liegen, die von außen aussieht wie eine fertige Sicherung. Bei uns scheiterte der nächtliche Offsite-Lauf beim Schreiben eines 3,4 Gigabyte großen Archivs auf die Storage Box am Arbeitsspeicher, und danach lag die Datei dort mit falscher Prüfsumme und einem Änderungsdatum aus dem Jahr 1970. Seitdem vergleicht das Skript nach jedem Lauf die Prüfsummen auf dem Ziel und meldet sich, wenn eine nicht passt. Eine halbe Kopie ist gefährlicher als keine, weil sie den Platz der ganzen einnimmt.

Unser Offsite-Lauf kopierte die Sicherung vom Vortag, weil er startete, bevor die Sicherung des laufenden Tages fertig war. Der Container-Server schreibt seine Archive bis kurz nach fünf Uhr morgens, der Abholer lief um vier, beide Seiten grün, und die Kopie außer Haus hinkte strukturell vierundzwanzig Stunden hinterher. Dazu rechnete die eine Maschine in Weltzeit und die andere in Sommerzeit. Wer zwei Automatiken hintereinander hängt, muss wissen, wann die erste fertig ist, nicht nur dass sie läuft.

Wenn alle Überwachungs-Meldungen gleichzeitig verstummen, ist selten jeder Job kaputt, sondern der gemeinsame Weg. Bei uns war die automatische Zertifikats-Erneuerung stillgelegt, das Zertifikat lief ab, und danach kam acht Tage lang keine einzige Erfolgsmeldung mehr bei Uptime Kuma an: 783 Warnungen aus einer einzigen Ursache. Die Sicherungen liefen die ganze Zeit sauber, nur sagen konnte es niemand mehr. Wer viele Alarme auf einmal sieht, sucht zuerst das, was sie alle gemeinsam haben.

Ein grünes Backup beweist nicht, dass die Kopie außer Haus liegt, sondern nur, dass die Sicherung geschrieben wurde. Bei uns lief der Job monatelang sauber, während die Übertragung auf den externen Speicher stillstand, weil der Schlüssel dort nicht mehr akzeptiert wurde. Aufgefallen ist es erst beim Nachziehen: 107 Gigabyte auf einen Schlag. Seitdem meldet nicht nur jeder Job, sondern auch jeder Transfer, dass er angekommen ist. Erst die Kopie am zweiten Ort ist die Sicherung.

Zwei Umbauten gehören in ein Wartungsfenster, wenn für beide derselbe Rückweg gilt. Geplant hatte ich den Umzug unseres Dokumentenarchivs auf eigene Hardware und den Versionssprung getrennt, gemacht habe ich beides an einem Freitagabend in sechs Minuten Ausfall, mit einem vollständigen Abzug der PostgreSQL-Datenbank als Rückfallpunkt davor. Zwei Fenster hätten doppelt gestört und nicht mehr Sicherheit gebracht. Über das Risiko entscheidet nicht die Zahl der Änderungen, sondern ob man zurückkann.

Eine lizenzierte Fachsoftware zieht man am besten über ihr eigenes Sicherungswerkzeug um, nicht über die alte Festplatte. Bei unserer AU-Software wollte ich schon die ganze Windows-Platte in den Ersatzrechner hängen, bis ich merkte: die eingebaute Datensicherung nimmt die Lizenzdatei mit. Also alten Rechner sichern, neuen sauber aufsetzen, die achtzig Megabyte große Demoversion installieren, rücksichern, fertig. Bevor man den schweren Weg geht, lohnt der Blick, ob der Hersteller den leichten schon eingebaut hat.

Die alte Windows-Platte muss man beim PC-Wechsel meistens gar nicht mitnehmen. Ich wollte unsere AU-Software auf einen neuen Rechner klonen und habe vorher ins Handbuch geschaut: Das Programm hat eine eigene Datensicherung, die die Lizenzdatei mitnimmt. Also altes System sichern, neuen PC sauber aufsetzen, die 82 Megabyte große Demoversion installieren, zurücksichern, fertig. Bevor man ein System mit Gewalt umzieht, lohnt die Frage, ob es dafür längst einen vorgesehenen Weg gibt.

Das alte System lösche ich nicht, sobald das neue läuft, ich halte es nur an. Beim Umstieg unseres Doku-Chatbots für die Loco-Soft-Hilfe auf eine neue Software habe ich den Eigenbau samt Datenbank mit über viertausend Textbausteinen gestoppt, aber liegen lassen. Geprüft habe ich das neue System bisher an zwei echten Fragen aus der Werkstatt, und zwei Stichproben sind noch kein Dauerbetrieb. Ein angehaltenes System ist ein Rückweg, ein gelöschtes ist keiner.

Ein neuer Alarm kann einen alten Ausfall erklären, manchmal besser als jede Suche damals. Wir hatten unserem nächtlichen Sicherungsskript gerade erst einen Wächter in Uptime Kuma gegeben, und schon in der ersten Nacht schlug er an. Die Suche zeigte: Das Skript war seit rund elf Wochen still kaputt, seine Aufräum-Routine lief nie, der Backup-Ordner wuchs auf 208 GB, und genau diese volle Platte hatte Anfang Juli unsere ganze Cloud lahmgelegt. Ein Fehler ohne Alarm verschwindet nicht, er sammelt sich nur an.

Ein Archiv legt seine Dateien besser nach einer festen Nummer ab als nach dem sprechenden Titel. Unser Langzeit-Archiv sortierte die Belege nach dem Titel, den die KI vergibt, doch dieselbe Bezeichnung entsteht dutzendfach, und so lagen am Ende 14.138 Objekte gegenüber rund 6.800 echten Dateien, sechs davon unter einem fremden Namen. Jetzt bekommt jedes Dokument seine unveränderliche Kennung, der Titel bleibt nur zum Lesen. Ein Name darf sprechen, tragen muss ihn eine Nummer, die sich nie verschiebt.

Ein Erpressungstrojaner kann unsere Datensicherung nicht verschlüsseln, weil sich die Kopie selbst gegen jeden Zugriff sperrt, auch gegen meinen. Unsere Belege liegen zusätzlich im Hetzner Object Storage mit echtem Object-Lock: 14.138 Dokumente, zehn Jahre unveränderbar, unlöschbar selbst mit gestohlenen Administrator-Rechten. Als sich ein lokales Original änderte, verweigerte der Speicher die Überschreibung, genau wie er soll. Ein Backup, das ich selbst noch löschen kann, kann auch ein Angreifer löschen.

Meine eigenen Belege nicht löschen zu können, ist kein Mangel, sondern der ganze Sinn eines revisionssicheren Archivs. Unsere Dokumente wandern jede Nacht in einen Hetzner Object Storage mit echtem Object-Lock, Modus Compliance und zehn Jahren Aufbewahrung, aktuell 14.138 Objekte, die auch ich als Administrator oder ein Angreifer mit gestohlenen Zugängen nicht mehr überschreiben kann. Als der Lauf Fehler meldete, weil sich lokale Originale geändert hatten, war das kein Defekt, sondern die Sperre, die ihre Arbeit tat. Ein Archiv, das der Besitzer selbst überschreiben kann, kann auch ein Angreifer überschreiben.

Ein Datenbank-Backup, dessen Schlüssel fehlt, nützt im Ernstfall gar nichts. Beim Härten unserer Sicherungen fiel auf, dass unser Skript zwar jede Datenbank zog, die Service-Schlüssel aber nicht mitsicherte, den Vaultwarden-Schlüssel, die n8n-Verschlüsselung, die Matrix-Signaturen. Ohne die wären die Daten nur unlesbarer Zeichensalat gewesen. Jetzt wandern rund neun Megabyte Schlüssel bei jedem Lauf mit ins Archiv. Ein Backup, das man nicht wieder aufschließen kann, ist ein Schrank ohne Schlüssel.

Eine Sicherung, die auf demselben Rechner wie die Originaldaten liegt, ist noch keine echte Sicherung. Bei uns war das nächtliche Auslagern der Archive an einen zweiten Ort seit Mai still ausgefallen, ohne dass es jemand bemerkte, und so lagen die Kopien nur dort, wo auch das Original lag. Jetzt geht jede Nacht eine Kopie an einen Rechner an einem anderen Standort mit über achthundert Gigabyte Platz, und jeder Job meldet sich danach bei Uptime Kuma. Eine Kopie neben dem Original teilt im Ernstfall dessen Schicksal.

Dass ein Backup-Job seit Wochen nichts mehr sichert, merkt man nur, wenn er sich auch dann meldet, wenn er läuft, nicht bloß wenn er scheitert. Unser Forgejo-Backup-Skript war spurlos verschwunden, der nächtliche Auftrag lief ins Leere, und rund 2,9 GB Repositorien lagen wochenlang ungesichert, ohne dass es jemand bemerkte. Jetzt pusht jeder Job nach getaner Arbeit ein Signal an Uptime Kuma, bleibt es aus, klingelt es. Ein stiller Job sieht aus wie ein erledigter, bis man ihn braucht.

Ja, die eigene Datensicherung kann den ganzen Betrieb lahmlegen, wenn niemand prüft, ob sie sich auch selbst aufräumt. Bei uns lief die Aufräum-Automatik still aus: statt sieben Tage sammelten sich vierundfünfzig, 208 GB alte Sicherungen, bis die Platte zu hundert Prozent voll war und Docker keinen einzigen Container mehr starten konnte. Alles, was in der Hetzner-Cloud lief, war mit einem Schlag offline. Eine Sicherung, die niemand kontrolliert, wird irgendwann selbst die Gefahr, vor der sie schützen sollte.

Eine kaputt synchronisierte Datei loescht man nicht, um sie neu zu laden, denn das Loeschen wandert bidirektional zum Server. Mein Nextcloud-Client auf dem Mac hatte einen Anmeldefehler als XML in eine meiner Notizen geschrieben, statt ihn zu melden; als ich die eine Datei lokal entfernte, um einen frischen Download zu erzwingen, war sie auch auf dem Server weg. Gerettet hat mich allein die Versionierung, die noch den Stand von Minuten vorher kannte. Sync ist kein Backup, und Loeschen ist ueberall Loeschen.

Vor jeder Änderung eine Sicherung, ausnahmslos. Am produktiven System arbeitet man wie am offenen Herzen: erst sichern, dann schneiden, und nur das anfassen, was man wirklich anfassen muss. Mut ohne Netz ist kein Mut, sondern Leichtsinn, und hier hängen echte Menschen dran.

Erst wenn man den Moment davor zurückholen konnte. Eine Sicherung, die man nie zurückgespielt hat, ist nur eine Hoffnung. Wir haben deshalb mit pgBackRest eine punktgenaue Wiederherstellung eingerichtet und geprobt. Erst die geglückte Rückspielung macht aus Daten ein Netz.