Kopia meldete drei Monate lang Erfolg — und sammelte 1,6 TB Müll

Auf meinem Unraid-Server sichert ein Kopia-Container die Nutzdaten per SFTP auf eine Hetzner Storage Box. Aufgesetzt im Mai, seitdem unauffällig: jeder Snapshot erfolgreich, jede Nacht, drei Monate lang. Aufgefallen ist es erst Ende August — und auch nur nebenbei: ich hängte einen neuen Ordner in die Backup-Kette und prüfte bei der Gelegenheit, ob das Repository gesund ist.

Die Storage Box meldete über zwei Terabyte belegt. Für Nutzdaten, die keine 500 GB ausmachen. Und nichts davon war ein Fehler im Sinne von Kopia — jede einzelne Sicherung war tatsächlich erfolgreich.

Was im Log stand: nichts

Das war der verwirrende Teil. In den Container-Logs startet der Maintenance-Manager brav jeden Tag, meldet sich, und beendet sich wieder. Ohne Fehler. Ohne Warnung. Er hat in drei Monaten kein einziges Mal ausgelöst.

Es gibt in Kopia zwei Dinge, die man leicht für dasselbe hält:

• Die Sicherung schreibt neue Daten ins Repository. Die lief.
• Die Wartung räumt auf, was keine Sicherung mehr braucht — Datenblöcke löschen, auf die kein Snapshot mehr zeigt, und die Indizes verdichten. Die lief nicht. Kein einziges Mal, seit Mai.

Ein Backup-System, das nur die erste Hälfte macht, wirkt nach außen vollkommen gesund. Es sichert schließlich. Es wächst nur unbegrenzt.

Die Ursache: Wartung hat einen Eigentümer — und der war leer

Kopia führt die aufwendige Wartung nicht auf jedem Client aus, der sich verbindet — sonst würden sich mehrere Rechner am selben Repository in die Quere kommen. Stattdessen kennt das Repository einen Eigentümer (benutzer@hostname), und nur wer sich als dieser Eigentümer erkennt, räumt auf. Alle anderen überspringen die Wartung. Wortlos — das ist aus Kopias Sicht kein Fehler, sondern Zuständigkeit.

Bei mir zeigte kopia maintenance info in der ersten Zeile:

Owner:

Nichts dahinter. Das Feld war leer — warum es bei der Anlage im Mai leer blieb, ließ sich im Nachhinein nicht mehr klären. Die Folge war aber eindeutig: wenn niemand Eigentümer ist, erkennt sich auch niemand als Eigentümer. Der Wartungs-Manager startete jeden Tag, stellte fest, dass er nicht zuständig ist, und beendete sich. Drei Monate lang.

Ein leeres Feld, das man nirgends sieht — und schon fühlt sich drei Monate lang niemand zuständig.

Die Reparatur ist dann ein einziger Befehl:

docker exec Kopia kopia maintenance set --owner=me

Der anschließende erste volle Wartungslauf lieferte die genaue Bilanz des Versäumten:

GC found 751419 unused contents (1.6 TB)
GC found 177298 in-use contents (440.3 GB)

Gut anderthalb Terabyte Datenblöcke, auf die kein einziger Snapshot mehr zeigte — neben 440 GB, die tatsächlich gebraucht wurden. Über die folgenden Läufe wurde das abgetragen; heute belegt das Repository wieder gut 600 GB, und statt der 5-TB-Storage-Box reicht die kleinste mit 1 TB. Das ist der Teil, der sich direkt in Euro auszahlt.

Die zwei Befehle, mit denen man es sieht

Prüfen lässt sich das von außen nicht — weder die Snapshot-Liste noch die Weboberfläche verraten es. Man muss das Repository selbst fragen:

docker exec Kopia kopia maintenance info
docker exec Kopia kopia repository status

Zwei Dinge müssen zusammenpassen:

1. Die Zeile Owner: aus maintenance info muss dem Benutzer und Hostname: aus repository status entsprechen. Ist sie leer oder steht dort eine Identität, die der Client nicht mehr trägt, wird nicht aufgeräumt.
2. Unter Recent Maintenance Runs muss snapshot-gc einen Lauf aus den letzten 24 Stunden zeigen. Fehlt full-delete-blobs über mehrere Tage, läuft schon Müll auf.

Der zweite Punkt ist der bessere Wächter, weil er unabhängig von der Ursache anschlägt. Der Eigentümer-Name ist nur einer der Wege, auf denen die Wartung aussetzen kann.

Der Haken an der Reparatur

--owner=me hat eine Feinheit, die man kennen muss: der neue Eigentümer heißt jetzt root@c57df42cd416 — der Hostname des ursprünglichen Containers aus dem Mai. Den Container gibt es längst nicht mehr; er wurde im Juni einmal neu erstellt und heißt seitdem anders. Dass die Identität trotzdem stimmt, liegt allein daran, dass Kopia den Hostnamen bei der Repo-Anlage in seine Konfigurationsdatei geschrieben hat und seither von dort liest, nicht vom Container.

Genau da wohnt das Risiko: diese Datei schreiben verschiedene Werkzeuge ohne Rückfrage neu. Der Reconnect-Assistent tut es. Eine Neuanlage des Containers ohne Übernahme der alten Konfiguration tut es auch. Danach meldet sich der Client mit dem neuen Container-Namen, der Eigentümer trägt den alten — und die Wartung kippt wieder lautlos aus. Kein Fehler, kein Log, keine Mail. Nur eine Storage Box, die wieder anfängt zu wachsen.

Deshalb steht die Prüfung von oben bei mir jetzt in der Checkliste für jeden Eingriff am Backup-Container, nicht in einem Monitoring-Dashboard. Ein Dashboard hätte hier nichts gezeigt: es hat auf „Sicherung erfolgreich“ geschaut, und das war ja die ganze Zeit wahr.