Was Messungen verschweigen — 621 Megabyte, die 31 Gigabyte waren

Am Vormittag stand die Frage, was gesichert werden muss. Am Nachmittag stand die Frage, wie groß das eigentlich ist. Die zweite Frage erwies sich als die gefährlichere.

Teil 1 endete mit dem Befund, dass eine gepflegte Liste ausgerechnet die Zugangsschlüssel nicht enthielt. Der nächste Schritt war naheliegend: Wenn das Include-Prinzip die falsche Fehlerrichtung hat, dann sichern wir eben alles. Bleibt nur die Frage, wie viel „alles" ist.

Die Messung, die 621 Megabyte meldete

Ein Blick auf die großen Verzeichnisse, ein Standardbefehl, eine Tabelle. Der Cloud-Ordner des Betriebssystems tauchte darin mit 621 Megabyte auf. Ich notierte ihn als unkritisch und ging weiter. Es gab an diesem Tag größere Posten.

Später startete ein Trockenlauf — ein Backup-Durchgang, der nichts schreibt, sondern nur ermittelt, wie viel Daten anfallen würden. Nach einer knappen Stunde lief er immer noch. Auffällig war die Prozessorlast: 0,3 Prozent. Ein Prozess, der Daten verarbeitet, sieht anders aus. Dieser wartete.

Ein Blick auf die geöffneten Dateien zeigte, worauf: auf Downloads. Der Trockenlauf las gerade Steuerunterlagen aus dem Cloud-Ordner — jenem, den ich als 621 Megabyte klein notiert hatte. Die Zahlen zu diesem Zeitpunkt:

Messung	Wert
Cloud-Ordner am Vormittag	621 MB
Cloud-Ordner jetzt	31 GB
Verstrichene Zeit	79 Minuten
Verbleibende Platzhalter	0
Freier Plattenplatz	20 GB

Der Trockenlauf hatte den gesamten Cloud-Bestand auf die Platte geholt. Auf einem Rechner, dessen Platte in den Monaten zuvor bereits zweimal vollgelaufen war. Und das Bitterste daran: Es war ein Trockenlauf. Kein einziges der 31 Gigabyte landete im Backup, denn geschrieben wurde nichts. Der Lauf war eine Messung — und die Messung selbst hat den Schaden verursacht.

Was die Zahl eigentlich zählte

Die 621 Megabyte waren nicht falsch. Sie beantworteten nur eine andere Frage als die, die ich gestellt hatte.

Moderne Betriebssysteme kennen Dateien, die im Verzeichnis sichtbar sind, deren Inhalt aber nicht auf der Platte liegt. Bei Apple heißt dieser Zustand offiziell „dataless" — es gibt dafür ein eigenes Dateisystem-Kennzeichen, das Programme abfragen, aber nicht selbst setzen können. Ist die Speicheroptimierung aktiv, ersetzt das System selten genutzte Dateien durch solche Platzhalter und hält den Inhalt nur noch beim Anbieter.

Das übliche Größenwerkzeug zählt in seiner Standardeinstellung die tatsächlich belegten Blöcke. Bei einem Platzhalter ist dieser Wert null. Die logische Größe der Datei steht daneben in den Metadaten und wird auf Anforderung ausgegeben — das Werkzeug unterscheidet beides selbst und dokumentiert die Unterscheidung. Nur hatte ich die Standardeinstellung benutzt und damit gemessen, wie viel Platz belegt ist, während ich wissen wollte, wie viel Daten es sind.

Zur Größenordnung, nachgemessen auf einem vergleichbaren System: belegter Platz 262 Megabyte, logische Größe 13 Gigabyte. Faktor 50. Bei Cloud-Ordnern liefert die Standardmessung nicht einen etwas zu kleinen Wert, sondern eine falsche Größenordnung.

Eine Entwarnung und eine Lösung

Zwei Dinge, die ich beim Nachrecherchieren gelernt habe und die der Intuition widersprechen.

Das Messen selbst ist harmlos. Ich hatte angenommen, schon die Abfrage der logischen Größe könnte das Nachladen auslösen — schließlich muss das System dafür etwas über den Inhalt wissen. Das ist nicht so. Größen- und Metadatenabfragen lesen ausschließlich den Verzeichniseintrag. Ein Kontrolldurchlauf über 13 Gigabyte Cloud-Daten ließ auf dem Testsystem alle 2.674 Platzhalter unberührt. Erst ein echter Lesezugriff auf den Dateiinhalt materialisiert. Wer also nur wissen will, wie groß ein Cloud-Ordner wirklich ist, darf das gefahrlos herausfinden.

Das Backup-Werkzeug hat die Lösung inzwischen eingebaut. Restic kennt seit Version 0.19.0 vom Juni 2026 einen Schalter, der genau diese Platzhalter erkennt und überspringt. Er prüft dasselbe Dateisystem-Kennzeichen, das oben beschrieben ist. Laut Projektdokumentation verhindert er das Nachladen ab macOS 14; auf älteren Systemen werden die Dateien während eines Laufs weiterhin heruntergeladen. Beim Konkurrenzprodukt für Cloud-Synchronisation gibt es kein Gegenstück — dort bleibt nur der Ausschluss über Pfadfilter.

Die Entscheidung fiel trotzdem gegen das Mitsichern. Nicht aus technischen Gründen, sondern aus einer Abwägung: Würde jeder Lauf sämtliche Platzhalter materialisieren, belegten die Dateien dauerhaft Platz — ein Dauerkonflikt mit genau der Speicheroptimierung, die sie ausgelagert hatte. Die Daten liegen ohnehin beim Anbieter. Der Preis ist der fehlende eigene Versionsverlauf, und den haben wir bewusst bezahlt.

„Direkt" heißt nicht „kurz"

Die zweite Messung des Tages betraf die Geschwindigkeit. Ziel der neuen Sicherung war ein Netzwerkspeicher, der im selben Raum steht, verbunden über eine 2,5-Gigabit-Leitung. Erreichbar war er auf zwei Wegen: über seinen Namen im VPN oder über seine lokale Adresse.

Das VPN meldete den Status direct. Keine Vermittlung über einen fremden Server, also scheinbar der bestmögliche Fall. Der Statusbericht enthielt allerdings noch eine Information, die leicht zu übersehen ist: Der verwendete Endpunkt war eine global gültige Adresse. Der Verkehr lief also über den Internetanschluss hinaus und wieder herein — zwischen zwei Geräten, die zwei Meter auseinanderstehen und am selben Switch hängen.

Weg	Durchsatz	Hochrechnung für 124 GB
Cloud-Speicher über Internet	4,5 MB/s	~7,5 Stunden
Netzwerkspeicher über VPN	16 MB/s	~2 Stunden
Netzwerkspeicher über lokale Adresse	199 MB/s	~10 Minuten

Faktor 12 zwischen der ersten und der zweiten Zeile, bei identischer Hardware und identischem Kabel. Hinzu kommt die doppelte Verschlüsselung — die des VPN und die des Übertragungsprotokolls darüber.

Was das Wort „direkt" hier bedeutet, ist „ohne Vermittlungsserver" — nicht „auf dem kürzesten Weg". Eine Statusmeldung, die man als Qualitätsurteil liest, obwohl sie eine technische Aussage über die Verbindungsart trifft. Konsequenz für das Skript: im Heimnetz die lokale Adresse, das VPN nur als Rückfallweg für unterwegs.

Brutto gegen Netto

Die dritte Verzerrung betrifft die Planung. Wer entscheidet, welche Projekte in ein Backup gehören, schaut auf ihre Größe. Nur ist die angezeigte Größe eines Projektverzeichnisses überwiegend eine Aussage über heruntergeladene Abhängigkeiten, nicht über Arbeit.

Dieselben Verzeichnisse, einmal wie angezeigt und einmal nach Abzug dessen, was sich aus je einer Textdatei wiederherstellen lässt:

Projekt	Brutto	Netto
Kartenanwendung	614 MB	42 MB
Videowerkzeug	536 MB	4 MB
Suchdienst	245 MB	32 MB
Bildarchiv	83,7 GB	81,5 GB

Die drei oberen Zeilen bestehen fast vollständig aus Paketverzeichnissen und virtuellen Umgebungen. Die untere nicht — dort liegen echte Bilddaten, die sich nirgends neu erzeugen lassen.

Wer nach angezeigten Größen plant, sichert bevorzugt das Reproduzierbare und hält den eigentlichen Wert für klein. Die drei kleinen Projekte hätte man nach Bauchgefühl als „zu groß, später" beiseitegelegt — dabei sind sie zusammen 78 Megabyte.

Zwei Zahlen, die verschiedene Dinge steuern

Die letzte Verzerrung ist die feinste. Nach dem großen Lauf ergab die Auswertung des Snapshots:

• Das Bildarchiv stellte 1,04 von 1,09 Millionen Dateien — rund 95 Prozent aller Dateien, aber nur 48 Prozent des Volumens.
• Ein anderes Verzeichnis brachte 4,8 Gigabyte in gerade 119 Dateien.

Das sind keine Kuriositäten, sondern Planungsgrößen, und sie steuern Verschiedenes. Die Dateianzahl bestimmt die Laufzeit: Für jede einzelne Datei muss das Werkzeug Metadaten lesen und mit dem Vorgängerstand vergleichen. Die Datenmenge bestimmt die Übertragung. Ein Verzeichnis mit einer Million kleiner Dateien kann einen Lauf dominieren, ohne nennenswert Bandbreite zu verbrauchen; ein Verzeichnis mit acht großen Dateien ist umgekehrt.

Praktisch heißt das: Ein Lauf über 170 Gigabyte kann in wenigen Minuten durch sein, solange sich am Bestand mit den vielen Dateien nichts ändert — das Werkzeug vergleicht dann nur Prüfsummen. Wird dort aber einmal etwas grundlegend neu erzeugt, kippt das Verhältnis, und derselbe Lauf dauert ein Vielfaches.

Die gefährlichste Fehlerrichtung: das Prüfwerkzeug

Bleibt die vierte Messung, und sie ist die unangenehmste, weil sie mich selbst betraf.

Nach einem Testlauf wollte ich belegen, dass die Versionsgeschichte eines großen Projekts wirklich im Snapshot liegt. Der Befehl listete den Inhalt des Snapshots unter dem entsprechenden Pfad auf. Ergebnis: 12 Dateien, 0,01 Gigabyte. Die großen Paketdateien mit rund elf Gigabyte fehlten.

Ein echter Befund, dachte ich, und meldete ihn als solchen: Die Historie fehlt im Backup.

Bevor ich das Backup beschuldigte, prüfte ich noch die andere Möglichkeit — dass mein Prüfbefehl das Problem ist. Er war es.

Der Auflistungsbefehl steigt bei einem Pfadfilter nicht in Unterverzeichnisse ab. Er zeigt nur die oberste Ebene. Die zwölf Einträge waren die Konfigurationsdateien direkt im Verzeichnis; alles darunter blieb unsichtbar. Ein Durchlauf über den vollständigen Snapshot statt über den gefilterten Auszug ergab:

Snapshot gesamt	49.648 Dateien, 23,88 GB
davon im fraglichen Verzeichnis	852 Dateien, 10,93 GB

Das Backup war vollständig. Meine Prüfung war es nicht.

Diese Fehlerrichtung ist die gefährlichere von beiden. Ein Backup, das zu wenig sichert, fällt spätestens beim Wiederherstellen auf. Ein Prüfverfahren, das zu wenig anzeigt, führt zu Aktionismus und Fehlentscheidungen — und im umgekehrten Fall, wenn es zu viel anzeigt, zu falscher Sicherheit. Der Merksatz, der davon geblieben ist:

Erst dem Prüfwerkzeug misstrauen, dann dem Backup. Verlässlich ist, was man über den gesamten Bestand zählt — nicht, was ein gefilterter Auszug zeigt.

Die gemeinsame Regel

Vier Messungen, vier verschiedene Täuschungen, eine Ursache. In allen vier Fällen war die Zahl korrekt; falsch war die Frage, die ich ihr unterstellt hatte.

• Belegter Platz ist nicht Datenmenge.
• Direkt ist nicht kurz.
• Verzeichnisgröße ist nicht Wert.
• Ein gefilterter Auszug ist nicht der Bestand.

Jede Zahl braucht die Frage, was sie eigentlich zählt. Und wo eine Zahl einer Beobachtung widerspricht — ein Ordner ist kleiner, als er sein dürfte, ein Lauf dauert länger, als er sollte — gehört zuerst die Messung angezweifelt, nicht die Beobachtung.

Teil 3 handelt von einem System, das genau diese Prüfungen automatisieren sollte — und das an diesem Nachmittag ausfiel, ohne es zu melden.

Quellenverzeichnis

Alle Quellen abgerufen am 20.08.2026.

• Apple SDK, sys/stat.h — Definition des Kennzeichens für Platzhalter-Dateien (Angabe: „file is dataless object"; als synthetisches Flag ausdrücklich nicht durch Anwendungen setzbar).
• Apple, FileProvider-Framework, NSFileProviderManager — Beschreibung der Auslagerung („the file will be made dataless").
• Apple Support, „Free up storage space on Mac" — Funktionsweise der Speicheroptimierung mit bedarfsweisem Nachladen.
• Manpages du(1) und stat(1) — Unterscheidung zwischen belegten Blöcken und scheinbarer Größe (Angabe: „Display the apparent size instead of the disk usage").
• Restic-Dokumentation, „Backing up" — Schalter zum Ausschluss reiner Cloud-Dateien; Erkennung geänderter Dateien über Metadaten.
• Restic, Pull Request 5370 — Umsetzung für macOS (Angabe: Prüfung des Dataless-Flags; Wirksamkeit gegen unerwünschte Downloads ab macOS 14).
• Restic 0.19.0, Veröffentlichungshinweis vom 09.06.2026 — Verfügbarkeit des Schalters.
• Rclone-Dokumentation, „Local Filesystem" — Negativbefund: kein dokumentiertes Gegenstück zum Ausschluss von Platzhalter-Dateien.