Es darf nichts fehlen — warum Backup-Listen scheitern

Der Auftrag klang einfach. Ein Backup existierte, es lief täglich, es meldete Erfolg. Die Frage war nur noch, ob auch wirklich alles darin liegt. „Es darf nichts fehlen" — ein Satz, den man in einem Nachmittag abzuarbeiten glaubt.

Er beschäftigte uns einen ganzen Tag, und das Ergebnis war nicht die erwartete Liste, sondern die Einsicht, dass die Liste selbst das Problem war.

Das Grundproblem: Man kann nicht aufzählen, woran man nicht gedacht hat

Jede Backup-Konfiguration, die mit einer Aufzählung arbeitet, trifft eine stille Annahme: dass derjenige, der die Aufzählung schreibt, den Bestand vollständig kennt. Diese Annahme ist am Tag des Schreibens vielleicht richtig. Sie ist am Tag danach schon falsch.

Ein Beispiel aus derselben Woche: Zwei Tage zuvor war ein neuer Dienst dazugekommen. Seine Daten, seine Konfigurationsdatei und sein Nachrichtenarchiv lagen zunächst vollständig außerhalb des Backups. Das fiel am selben Abend auf und wurde nachgetragen — aber es fiel durch Zufall auf, nicht durch ein Verfahren. Eine Liste hätte es nicht verhindern können, denn beim Schreiben der Liste gab es den Dienst noch nicht.

Das ist keine Nachlässigkeit, sondern eine strukturelle Eigenschaft. Wer Vollständigkeit durch Erinnerung herstellen will, sichert exakt den Wissensstand des Zeitpunkts, an dem er zuletzt darüber nachgedacht hat.

Drei vernünftige Verfahren, ein blinder Fleck

Um herauszufinden, was fehlt, habe ich zunächst getan, was naheliegt: gesucht. Und zwar auf zwei Wegen, die beide sinnvoll sind.

Erstens über die Versionsverwaltung. Jedes ernsthafte Projekt liegt in einem Git-Repository. Ein Durchlauf über alle Verzeichnisse mit einem .git-Unterordner findet also zuverlässig alles, was Projektarbeit ist. Das Verfahren fand zwölf Ordner, die im Backup fehlten — fünf davon ohne jede Kopie auf einem Server, existierten also nur auf dieser einen Platte.

Zweitens über Namensmuster. Die Arbeitsverzeichnisse folgen einer Konvention: ein Präfix, ein Bindestrich, der Projektname. Ein Muster darauf findet den Rest.

Beide Verfahren sind richtig. Beide übersahen denselben Ordner.

Er enthielt echte Arbeit, aber er nutzte kein Git — also fiel er durch das erste Raster. Und sein Name trug keinen Bindestrich, sondern bestand aus vier Großbuchstaben — also fiel er durch das zweite. Ein Ordner, der weder das eine Kriterium erfüllte noch das andere, und der deshalb in keiner der beiden Ergebnismengen auftauchte.

Gefunden hat ihn erst das dritte Verfahren, das keinerlei Intelligenz besitzt: ein stumpfer Durchlauf über alle Verzeichnisse der obersten Ebene, ohne Filter, ohne Annahme darüber, wie ein Projekt auszusehen hat. Dieser Durchlauf fand ihn — und mit ihm elf weitere Ordner, die nach Arbeit aussahen und in keinem der klugen Muster vorkamen.

Die Lehre daraus ist unbequem für jeden, der gern eleganten Code schreibt: Ein Muster findet nur, was jemand vorher gedacht hat. Je klüger das Suchkriterium, desto präziser der blinde Fleck.

Include gegen Exclude: die Frage ist die Fehlerrichtung

An dieser Stelle wird aus einem Suchproblem eine Entwurfsentscheidung. Denn dass die Liste lückenhaft war, ließ sich beheben — die zwölf plus drei plus elf Ordner waren schnell nachgetragen. Die eigentliche Frage ist, ob man das Verfahren behalten will, das solche Lücken erzeugt.

Backup-Werkzeuge kennen zwei Grundhaltungen:

Prinzip	Standardverhalten	Ein Versehen kostet
Include	nichts sichern, jeder Pfad muss eingetragen werden	Daten
Exclude	alles sichern, Ausnahmen werden eingetragen	Speicherplatz

Das ist der ganze Unterschied, und er ist entscheidend. Beide Verfahren erzeugen Fehler — Menschen vergessen Einträge, egal in welcher Spalte sie stehen. Aber die Richtung, in die der Fehler wirkt, ist eine andere. Vergisst man einen Eintrag in einer Include-Liste, fehlt hinterher etwas, das man nicht wiederbekommt. Vergisst man einen Eintrag in einer Exclude-Liste, liegt hinterher etwas im Backup, das man nicht gebraucht hätte. Das eine ist ein Verlust, das andere eine Rechnung.

Für den Anspruch „es darf nichts fehlen" ist damit klar, welche Voreinstellung richtig ist. Sichere alles, und nimm gezielt heraus, was nachweislich wertlos ist.

Die Ausnahme, und warum sie keine Aufweichung ist

Wenige Stunden später kam der Fall, der die Regel scheinbar widerlegt — und sie tatsächlich schärft.

Ein einziger Systemordner machte mit über 100 Gigabyte den größten Posten der geplanten Sicherung aus. Beim Durchsehen zeigte sich: Davon waren rund elf Gigabyte echte Nutzdaten — Nachrichtenverläufe, Anwendungsdaten weniger Programme. Der gesamte Rest bestand aus Zwischenspeichern, Programmresten und Metadaten, die sich jederzeit neu erzeugen lassen und die schneller wachsen als alles andere.

Hier ist die Include-Liste das richtige Werkzeug. Nicht weil das Prinzip von vorhin falsch war, sondern weil sich das Verhältnis umgekehrt hat. Man kann hier benennen, was zählt, weil es eine überschaubare Zahl bekannter Programme ist. Der Ballast ist die Regel, der Wert die Ausnahme.

Daraus wird eine Faustregel, die beide Fälle abdeckt:

Include dort, wo man den Wert kennt. Exclude dort, wo man das Wertlose kennt.

Nicht das Prinzip entscheidet, sondern welche der beiden Mengen man vollständig aufzählen kann.

Der Gegenbeweis in Zahlen

Am selben Abend liefen zwei Sicherungen desselben Rechners nebeneinander: eine ältere gegen einen Cloud-Speicher, die nach dem Include-Prinzip arbeitete, und eine neue gegen ein lokales Netzwerklaufwerk, die nach dem Exclude-Prinzip arbeitete. Beide waren fertig. Ein Vergleich der obersten Ebene beider Snapshots ergab:

	Include-Sicherung	Exclude-Sicherung
Einträge auf oberster Ebene	102	209
Nur in dieser Sicherung enthalten	keiner	107

Die Exclude-Sicherung enthielt alles, was die Include-Sicherung enthielt, plus 107 weitere Einträge. Nicht ein einziger Eintrag existierte nur auf der gepflegten Seite. Die stundenlange Sorgfalt hatte keinen einzigen Posten hinzugefügt, den das simple „alles außer" nicht ohnehin erwischt hätte.

Die Pointe: Was in den 107 Einträgen steckte

Und jetzt die Stelle, an der der Tag von einer methodischen Übung zu einer unangenehmen Erkenntnis wurde. Unter den 107 Einträgen, die nur die Exclude-Sicherung kannte, waren nicht etwa Musikdateien und Urlaubsfotos. Es waren:

• die API-Schlüssel sämtlicher genutzter Dienstleister
• ein kryptografischer Schlüssel, ohne den ein weiteres Cloud-Backup dauerhaft unlesbar bleibt
• das Passwort eines der Backup-Repositorien selbst
• mehrere Sicherungsstände der Passwortdatenbank
• die Notfallkarte, also genau das Dokument, das im Ernstfall den Weg beschreibt

Zusammen unter 100 Kilobyte. Und keiner dieser Posten lag außer Haus — sie existierten ausschließlich auf dem lokalen Netzwerklaufwerk, also im selben Raum wie der Rechner, den sie im Schadensfall ersetzen sollten. Bei Feuer, Wasser oder Diebstahl wären beide Kopien gleichzeitig weg.

Das ist die eigentliche Pointe des Tages. Nach Stunden sorgfältiger Pflege einer Liste, die ausdrücklich dem Ziel „es darf nichts fehlen" diente, fehlten ausgerechnet die Dinge, ohne die der Rest des Backups wertlos ist. Nicht aus Schlamperei — sondern weil niemand daran gedacht hatte, und weil eine Liste nun einmal nicht enthalten kann, woran niemand gedacht hat.

Was daraus folgt

Drei Konsequenzen haben den Tag überlebt:

Erstens: Exclude als Standard, Include als begründete Ausnahme. Die Ausnahme muss man rechtfertigen können — mit dem Verhältnis von Wert zu Ballast, nicht mit Gewohnheit.

Zweitens: Vollständigkeit wird gemessen, nicht behauptet. Der Abgleich zweier maschinell erzeugter Listen — was liegt auf der Platte, was liegt im Snapshot — ist ein wiederholbares Verfahren. Das Nachdenken darüber, was wohl fehlen könnte, ist keines.

Drittens: Vom Wiederherstellungsweg her denken. Die belastbarste Prüfung ist nicht „habe ich alles eingetragen?", sondern „was brauche ich, wenn dieser Rechner morgen nicht mehr existiert — und liegt das im Backup?". Alles, was diese Prozedur anfasst, muss gesichert sein. Was sie nie anfasst, braucht nicht hinein. Vollständigkeit wird so funktional bewiesen statt behauptet.

Der Rest der Serie handelt davon, was schiefging, nachdem diese Fragen geklärt schienen. Teil 2 zeigt, warum die Zahlen, auf die wir unsere Planung stützten, etwas anderes zählten als wir dachten — und was ein einzelner Trockenlauf dabei anrichtete.

Quellenverzeichnis

Alle Quellen abgerufen am 20.08.2026.

• Restic-Dokumentation, „Backing up" — Verhalten von Include- und Exclude-Regeln, Erkennung geänderter Dateien, Metadaten im Snapshot.
• Restic-Dokumentation, „Working with repositories" — Umfang der Prüfung durch check (Angabe: strukturelle Konsistenz ohne --read-data).
• BSI IT-Grundschutz, Baustein CON.3 „Datensicherungskonzept", Edition 2023 — Anforderung CON.3.A2 (Sicherung auf separate Speichermedien) und CON.3.A12 (räumlich getrennte Aufbewahrung).