Veröffentlicht am 2. September 2026 · 4 Min. Lesezeit
Meine Sicherung wog 945 GB. Der Code meiner Anwendungen war überhaupt nicht darin
Die Sicherung lief seit Mai täglich. Grüner Status, 41 Kopien in der Historie, kein einziger Fehler. Sie sah gesund aus.
Ich habe nicht wegen eines Ausfalls hineingeschaut, sondern weil mir der Speicherplatz ausging. Dabei sah ich, dass die Sicherung 945 GB bei einem Limit von 1,15 TB wog. Die Platte, die sie kopierte, hatte zu diesem Zeitpunkt 537 GB belegt.
Die Kopie war dicker als das, was sie kopierte. Das war das erste Signal.
Was tatsächlich passiert war
Ich habe geprüft, was in meinem Benutzerverzeichnis den Platz belegt:
113 GB Ollama-Modelle
55 GB LM-Studio-Modelle
38 GB Modelle des Bildgenerators
18 GB ComfyUI-Modelle
19 GB iOS-Simulatoren
Mehr als 220 GB an Sprach- und Bildmodellen. Dateien, die man mit einem einzigen Befehl herunterlädt und die in einer Sicherung keinerlei Wert haben — nach einem Ausfall hätte ich sie aus dem Internet schneller geholt, als ich sie von einem Netzlaufwerk zurückgespielt hätte.
Dann habe ich geprüft, was von der Sicherung ausgeschlossen ist. Die Antwort: praktisch nur das System-Cache-Verzeichnis. Alles andere ging jeden Tag in die Kopie.
Die Ursache
Meine Projekte liegen auf einer separaten externen Platte. Ich habe ihren Status geprüft:
[Excluded] /Volumes/<projektplatte>
Ausgeschlossen. Nicht versehentlich — das System überspringt externe Platten standardmäßig, und ich hatte das nie geändert.
Ich habe geprüft, was das für die drei Anwendungen bedeutet, an denen ich arbeite:
| Projekt | Entferntes Repository | Nicht committet |
|---|---|---|
| A | ja | 0 Dateien |
| B | keins | 13 Dateien |
| C | keins | 20 Dateien |
Die Projekte B und C existierten in einer Kopie, auf einer Platte. In Projekt C lag der gesamte Anwendungskern außerhalb von Git — Modelle, Controller, Views, Tests. Der einzige Commit hieß „Initial Commit" und war anderthalb Monate alt.
Ich habe diese Sicherung nicht entworfen. Sie ist gewachsen. Ich habe das Backup eingeschaltet, ein Netzlaufwerk ausgewählt, auf „Weiter" geklickt — und dann vier Monate lang Werkzeuge installiert, von denen jedes Dutzende Gigabyte ablegte. Die Sicherung nahm brav alles mit, weil ihr niemand gesagt hatte, sie solle es lassen.
Was ich nicht getan habe
Der einfachste Ausweg wäre gewesen, das Limit anzuheben. Auf dem Netzlaufwerk blieben 2,4 TB frei, ein Feld in den Einstellungen hätte das Problem „die Sicherung passt nicht mehr" in fünfzehn Sekunden gelöst.
Ich habe es nicht getan, weil das nicht das Problem war. Die Sicherung war nicht zu groß — sie war mit den falschen Daten gefüllt. Ein höheres Limit hätte das Symptom verschwinden lassen und die Ursache stehen gelassen: der Code weiterhin außerhalb der Kopie, die Modelle weiterhin darin, und in einem halben Jahr dasselbe Gespräch bei größeren Zahlen.
Die Reparatur
Zuerst der Code, denn das war das einzige unumkehrbare Risiko. Ich habe die offenen Änderungen committet, private Repositories für B und C angelegt und gepusht. Danach habe ich die Projektplatte aus den Ausschlüssen entfernt — mit ihr kamen einundzwanzig weitere Projekte in die Sicherung, die keine Repositories haben.
Dann die Ausschlüsse. Siebzehn Pfade, rund 286 GB: Modelle, Caches von Paketmanagern, Simulatoren, Container-Images, Debug-Symbole.
Hier stieß ich auf etwas, womit ich nicht gerechnet hatte: ein Ausschluss wirkt nicht rückwirkend. Er sagt „kopiere das ab jetzt nicht mehr", nicht „lösche, was du bereits kopiert hast". Die Modelle saßen in den Kopien von Mai, Juni und Juli und wären dort noch monatelang geblieben.
Da ich in vier Monaten kein einziges Mal auf eine ältere Version einer Datei zurückgegriffen hatte und die Sicherung mich vor einem Hardwareausfall schützen sollte und nicht vor meinem eigenen Fehler von vor einem Quartal, habe ich die alte Historie als Archiv beiseitegelegt und die Kopie von Grund auf neu aufgebaut.
Die Zahlen
| Vorher | Nachher | |
|---|---|---|
| Größe der Sicherung | 945 GB | 157 GB |
| Ausnutzung des Limits | 82 % | 16 % |
| Code ohne Absicherung | 2 Projekte | 0 |
Eine sechsfache Reduktion bei denselben Daten. Die vollständige Kopie von Grund auf dauerte dreißig Minuten.
Danach habe ich die fertige Sicherung geöffnet und die Quelldateien darin gezählt: 127, 44 und 44. Das stimmte mit der Platte überein, nachdem ich die Dateien abgezogen hatte, die beim Kompilieren entstehen.
Was daraus über meine Platte hinaus folgt
„Läuft sie" und „schützt sie" sind zwei verschiedene Fragen. Meine Sicherung hat vier Monate lang keinen einzigen Fehler gemeldet und in dieser ganzen Zeit den Code nicht abgesichert. Ein grüner Status beantwortet, ob der Lauf ausgeführt wurde, nicht, ob das Richtige darin ist.
Standardeinstellungen haben eine Meinung über Ihre Daten. Externe Platten liegen standardmäßig außerhalb der Sicherung. Das ist eine vernünftige Annahme des Herstellers — und die falsche in jeder Konfiguration, in der die Arbeit auf einer externen Platte liegt.
Eine Sicherung, die man nicht entworfen hat, entwirft sich selbst. Ohne eine Entscheidung darüber, was hineingehört, landet in der Kopie alles, was man im letzten Quartal installiert hat. Fünfzehn Minuten für eine Ausschlussliste sind mehr wert als jede weitere Erhöhung des Limits.
Die Zahlen stammen aus einer Diagnose und einem Neuaufbau vom 16. August 2026. Die Größen der Sicherung wurden vor der Änderung und nach der ersten vollständigen Kopie unter der neuen Konfiguration aus der Konfiguration des Sicherungssystems abgelesen.

Patryk Piecyk
Warschau · Junior-Implementierungsberater · ab sofort verfügbar
Siebeneinhalb Jahre habe ich in einem deutschen Unternehmen gearbeitet, fünf davon habe ich sein Büro geführt: Aufträge, Rechnungen, Reklamationen, ERP. Seit Juni 2026 baue ich eigene Werkzeuge für genau diese Arbeit — ich bin kein gelernter Programmierer; der Code entsteht gemeinsam mit einem KI-Assistenten, Entwurf, Entscheidungen und Tests sind meine. Diese Notizen beschreiben, was in diesen Systemen kaputtging und was dabei herauskam.
Eine Frage zu diesem Text?
Schreiben Sie mir →