Hallo allerseits,

ich stehe vor dem Problem, dass Time Machine sagt, es könne keine Backups mehr machen, weil das Time-Machine-Volume voll sei, daher würden beim nächsten Durchgang die ältesten Backups gelöscht. Das passiert aber nicht, sondern die Fehlermeldung kommt stündlich wieder. Zudem ist mir nicht plausibel, warum das Time-Machine-Volume derart schnell gefüllt wurde.

Hintergrund: Vor 6 Monaten habe ich meinen Mac Pro 5,1 von Mavericks auf Mojave aktualisiert und ihm dabei auch eine 4-TB-SSD für Time Machine gegönnt; zuvor war es eine 3-TB-Festplatte. Das zu sichernde Boot-Volume enthält ca. 2 TB Daten (wobei ich ebenfalls von am Ende randvoller 2-TB-Festplatte auf 4-TB-SSD migriert bin, aber die Daten auf dem Boot-Volume wurden dadurch ja zunächst mal nicht mehr und sind seitdem auch nur unwesentlich gewachsen, also immer noch ca. 2 GB).

In diesem halben Jahr nun ist die 4-TB-Time-Machine-SSD komplett vollgelaufen, während die 3-TB-Festplatte zuvor viele Jahre lang ausreichte. Das fand ich sehr seltsam, denn meine Nutzung hat sich nicht groß verändert in letzter Zeit.

Ich habe mir daher mal die Größe aller einzelnen Schnappschüsse auflisten lassen (die tatsächliche Größe unter Ausschluss der Hardlinks, also der Speicherplatz, den der jeweilige Schnappschuss auf der SSD tatsächlich verbraucht).

Für die, die das nicht wissen, das geht im Terminal mit folgendem Befehl:

Auffällig war, dass jede einzelne Stunde mehr als 1,6 GB gesichert wurden, selbst wenn ich so gut wie nichts am Computer getan hatte. Den Schuldigen dafür habe ich durch einen Vergleich zweier stündlicher, direkt aufeinander folgender Schnappschüsse in Time Machine gefunden:
Es stellte sich heraus, dass die Launch-Services-Datenbank aufgrund eines Bugs viel zu groß ist. Das habe ich in Explodierende Launch-Services-Datenbank? beschrieben. Alle Versionen von dieser Datei habe in Time Machine nun gelöscht und die Datei für die Zukunft vom Backup ausgenommen (mit
).
[Das Leerzeichen zwischen com und .apple gehört natürlich raus und wurde wieder von der $&§$%&§-Forensoftware eingefügt – was soll der Mist?]

Ich habe seit dem Update auf Mojave 140 Schnappschüsse in Time Machine; also müssten somit zumindest 140 × 1,6 GB = 224 GB frei geworden sein, was locker für viele neue Schnappschüsse reichen müsste. Tut es aber nicht; die Platte ist auch wie vor 100% voll (auch laut df).

Hinzu kommt: Laut Auflistung der Größe aller Schnappschüsse (wie oben beschrieben) zeigt sich, dass seit der Mojave-Installation (während der ja auch das Time-Machine-Volume von 3 TB auf 4 TB vergrößert, also 1 TB hinzugefügt wurde) selbst inklusive der Launch-Services-Datenbank-Monster insgesamt lediglich 327 GB neu verbraucht wurden. Es müssten eigentlich also sowieso noch 670 GB frei sein.

Ich habe also eigentlich 3 Probleme:

• Die Launch-Services-Datenbank frisst riesige Speichermengen. Mutmaßlich gelöst (was Backups betrifft) durch Ausschluss aus dem Backup.
• Time Machine verbrauchte in den letzten 6 Monaten 1 TB, obwohl nur 327 GB Schnappschüsse hinzukamen.
• Time Machine sagt (korrekt) es sei kein Platz mehr, das angekündigte Löschen findet aber nicht statt.

Die beiden letzten Punkte sind ungelöst.

Ich könnte ja versuchen, die ältesten Schnappschüsse mit tmutil im Terminal selbst zu löschen, aber eigentlich möchte ich nicht unnötig alte Backups löschen, wenn doch noch 670 GB frei sein müssten – und das Löschen von 224 GB an Launch-Services-Datenbank-Backups zudem ja auch nichts geholfen hat.

Ideen?

Die SSD für die TM-Backups ist extern oder intern und nicht zufälligerweise mit APFS aufgesetzt ?

Interne SSD, in HFS+ formatiert.

Ich lasse gerade ein du über das Time-Machine-Volume laufen. Sieht aber so aus, als könne das bis morgen dauern …

So schlimm war es gar nicht, 70 Minuten hat es gedauert.

Aber das Ergebnis ist höchst seltsam, insofern es mit dem Ergebnis von tmutil listbackups | xargs tmutil uniquesize so gut wie gar nichts zu tun hat. Für manche Schnappschüsse sind die Werte weit höher, für andere niedriger.

Da die Ausgabe von tmutil aber insgesamt nur auf 560 GB kommt, was bei einem zu sichernden Volume mit etwas mehr als 2 TB Daten keinen Sinn ergibt, vertraue ich eher du, das laut manpage explizit auch die Ordner-Hardlinks von Time Machine korrekt behandelt.

du kommt auf 3,4 TB; das ergibt mehr Sinn. Darin enthalten ist ein Schnappschuss .inProgress, der mit satten 228 GB angezeigt wird. Leider habe ich dessen Größe noch nie zuvor berechnen lassen und weiß daher nicht, ob eine solche immense Größe während der Erstellung eines Schnappschusses normal ist oder ob hier schon ein Problem vorliegt.

Aber selbst mit diesem riesigen Schnappschuss dürfte es eigentlich kein Problem geben. Zwar habe ich auf dem Time-Machine-Volume auch noch 230 GB manuell erstellter Updates von virtuellen Maschinen, aber 4 TB – 3,4 TB – 0,23 TB ergibt immer noch 370 GB freien Speicherplatz (ansonsten gibt es keine größeren Dateien auf dem Volume, habe ich auch mit du überprüft). Warum zum Teufel behauptet df dann, das Volume sei zu 100% voll und warum löscht Time Machine keine alten Schnappschüsse? Fragen über Fragen …

Versuch es mal mit Time Tracker. Damit lässt sich Time Machine recht gut überwachen. Vielleicht zeigt sich dann, wohin der Platz verschwindet:

Mir fehlen hier die kompletten Informationen was und wie gesichert wird. Der MacPro hat was intern verbaut ? Nur SSDs, davon eine mit HFS+ als TM Datengrab ? Was sind sonst noch für Laufwerke eingebaut und wie formatiert, was wird gesichert etc. Wie wurde auf Mojave aktualisiert. Alles neu gemacht oder per Update eingespielt ? Alle Patches installiert ? Warum ist das TM Backup intern? Das macht doch gar keinen Sinn. Ein Backup Volume sollte nie permanent angeschlossen sein. Sollte es ein Problem mit dem System geben (Ransomware, Diebstahl....) ist gleichzeitig auch das Backup weg.

Ich vermute ja, dass das nur eine GUI für tmutil ist, aber ich guck’s mir auf jeden Fall an – Danke!

Davon gehe ich aus. Aber es bietet einige praktische Funktionen, die eine gute Übersicht ermöglichen.

TRIM- oder Garbage-Collection-Problem?

Ich sehe nicht recht, welche Infos über die schon gegebenen hinaus relevant sein könnten, aber volià:4 4-TB-SSDs, davon 2 (APFS) über SuperDuper! auf externe Festplatten geklont, von Time Machine ausgeschlossen und damit für den hiesigen Zusammenhang völlig irrelevant, und 1 SSD (das Bootvolume in APFS mit ca. 2 TB Daten) auf die 4. SSD (HFS+) mit Time Machine gesichert (und zusätzlich mit SuperDuper! alternierend auf 2 externe Festplatten).
Update. Auch wenn es seitdem die Probleme mit der wildlaufenden Launch-Services-Datenbank gibt, funktionierte Time Machine ansonsten bis zu dem letzten Sicherheitsupdate ohne sichtbare Probleme. Ob das mit dem Sicherheitsupdate reine zeitliche Koinzidenz ist oder der Auslöser des Problems, kann ich nicht sagen. Dieses Sicherheitsupdate hat andere massive Probleme behoben, die ich aufgrund eines vorangegangenen Sicherheitsupdates hatte () – insofern traue ich Sicherheitsupdates im Moment jegliche Schweinereien zu.
Ja. Genau das ist ja möglicherweise das Problem.
Weil ich es so will.
Da bin ich eben anderer Auffassung. Das hat jetzt aber wirklich nichts mit dem hier vorliegenden Problem zu tun.

Auf SSD-Ebene? Glaube ich eher nicht, denn df behauptet ja auch, das Volume sei voll. Ich gehe daher jetzt erstmal den Hinweisen aus du sagt Platz auf Platte, df sagt kein Platz!?! nach.

TIRM ist jedenfalls eingeschaltet.

Stimmt, das ist wirklich nett gemacht. Hat aber den großen Haken, dass es ohne root-Rechte läuft, so dass diverse Ordner als nicht lesbar ausgeklammert werden. Das wäre also ein typisches Beispiel, wofür sehr wohl ein root-Konto auf GUI-Ebene nützlich sein kann (was ich immer wieder mal gefragt werde …)

Insofern war der Testlauf in meinem Nutzerkonto, der immerhin satte 9 Stunden gedauert hat, bis das Time-Machine-Volume eingelesen war, wohl leider vergeblich.

Demnach verbrauchte mein Time-Machine-Backup nur 2,4 TB, es wäre also noch rätselhafter, warum angeblich Platz auf der 4-TB-SSD fehlt.

Vielleicht lasse ich das Programm heute Nacht nochmals im root-Konto laufen.

Cooles Programm, danke für den Tip!

Habe ich jetzt gemacht, und dort hat das Programm seltsamerweise nur 1 statt 9 Stunden gebraucht.

Jedenfalls zeigt es als root, der Zugang zu allen Dateien hat, einen Speicherverbrauch von 2,6 TB an (statt 2,4 TB von meinem Nutzerkonto aus). Das ist nicht viel plausibler als 2,4 TB.

Allerdings zeigt das Programm für den frühesten Eintrag 0 Byte an mit dem Hinweis, dass kein früheres Backup vorliege. Das ist natürlich Unsinn; der früheste Eintrag hat genau die Größe, die das Quellvolume seinerzeit hatte. Das waren bei mir laut du 0,8 TB und dann sind wir wieder bei den 3,4 TB Gesamtspeicherplatzverbrauch, die auch du anzeigt und demgemäß noch reichlich Platz auf der SSD sein müsste.

In der Tat sind vom ersten Eintrag abgesehen die Speicherplatzangaben von Time Tracker identisch mit denen von du und bemerkenswerterweise mit keiner Ausgabevariante von tmutil, die ich gefunden habe.

Ich gehe nach den bisherigen Ergebnissen jedenfalls mal davon aus, dass das Resultat von du stimmt. Womit wieder die Frage bleibt: Wo sind die fehlenden 370 GB hin?

Ich hatte für mich leider auch schon die Erfahrung machen müssen, dass es manchmal sinnvoller ist, TM komplett neu aufzusetzen. So erst nach dem Update auf Catalina. Plötzlich wollte TM mehr Daten sichern, als sich geändert haben (Systemdateien vom Backup ausgeschlossen) und dafür war kein Platz mehr auf meiner NAS. Bevor ich mich da rumärgere, habe ich TM gelöscht und neu angelegt. Es geht mir eher um Backup als um Versionierung und das Risiko für die 8 Stunden musste ich halt eingehen - wobei als Software-Entwickler die wirklich wichtigen Daten auf einem Git-Server liegen - ärgerlich wäre es trotzdem.
Du kannst auf jeden Fall auch das erste Backup löschen, tmutil sollte dabei die Links auflösen, also Links des 2. Backups auf Dateien des ersten Backups mit den Dateien ersetzen und alle nachfolgenden Links korrigieren. Vielleicht passt dann wieder alles...

Weia

Vielleicht sehe ich Dein Rätsel etwas zu einfach:

du zeigt den benutzten Speicherplatz an und df (indirekt) den belegten. Wenn beide nicht übereinstimmen, ist entweder das Dateisystem oder das Volume defekt. Für letzteres lohnt es sich, den Smartstatus auszulesen. Ist der okay, dann muß das Dateisystem mit diskutil repariert werden. Auf jeden Fall lohnt es sich nicht, herumzurätseln wie es zu dem Fehler kam.

Und nun möchte ich noch einige Eulen nach Athen tragen:

Einige SSDs reagieren sehr sauer, wenn während des Schreibens der Strom ausfällt: Hast Du eine unterbrechungsfreie Stromversorgung und einen gut kontrollierten Zeigefinger, der nicht zur Unzeit einen Knopf drückt?
Immerhin hast Du einen abgebrochenen Snapshot auf dem Volume. Bei der Reparatur des Dateisystems gehen in der Regel Daten verloren.

Ja, das ist bei mir halt leider umgekehrt, deshalb ist das keine Option.
Schon klar, da es mir aber um die Versionierung geht, möchte ich das halt so weit wie möglich vermeiden.

Außerdem bleibt unklar, warum Time Machine ja selbst ankündigt, das zu tun, dann aber nicht tut.

In diesem Zusammenhang die Frage:

Weiß jemand, ob es normal ist, dass ein Schnappschuss, der gerade erstellt wird (also mit .inProgress als Suffix), etliche 100 GB groß ist (laut du, wie bei mir jetzt), auch wenn im Endresultat weniger als 1 GB gesichert werden wird?

Könnte man meinen. Ist aber beides nicht der Fall: SMART ist 100% OK (überprüft mit dem wie ich finde exzellenten und sehr detaillierten DriveDX) und diskutil findet keine Fehler.

Ich habe mir jetzt mal eine andere meiner SSDs angesehen. Da sind nur Musikdateien drauf, d.h. relativ wenige (weil die ja alle viel größer sind als Textdateien etc.).

Da sieht das so aus:
du sagt 752 GB belegt
df sagt 808 GB belegt.

Also auch hier schon über 50 GB Differenz. Ich frage mich, ob das ein systematischer Overhead des Dateisystems ist. Wäre aber ganz schön heftig …
Das war hier definitiv nicht der Fall. Strom ist nicht ausgefallen und mein Zeigefinger klickt ausschließlich auf Ruhezustand.
Ja, weil Time Machine eben mitten im Backup auffiel, dass Platz fehlt, und das Backup abgebrochen hat. Genau das ist ja mein Problem.

Weia
Konntest Du den unvollständigen Snapshot löschen, und war das der letzte?

Den letzten kannst Du eigentlich ohne Datenverlust löschen.

Zyklische Vernetzungen können z.B. entstehen, wenn jemand in der Library von Fotos direkt über den Finder herumpfuscht. (Brauchst Du nicht selbst machen, kann auch eine App sein oder ein Bug in Fotos selbst)

Ja, war der letzte, und ich habe ihn bereits gelöscht. Dadurch habe ich jetzt zumindest 200 GB gewonnen und ich werde auch bald probieren, was passiert, wenn ich Time Machine wieder anwerfe.

Ich will dem Problem nur gerne gründlicher auf die Spur kommen, sonst ist mein Time-Machine-Volume in einer Woche wieder voll …

M.W. sichert TM die Daten in einem "mitwachsenden sparse bundle", welches die ganze Partition ausfüllen kann. TM benutzt davon zunächst so viele Blöcke wie nötig. Werden weitere Blöcke (brutto) vorgesehen, so werden weitere Blöcke reserviert, selbst wenn sie später nicht benutzt werden. Auf den letzten (reservierten) Block zeigt ein Schleppzeiger, der schließlich das Ende der Partition erreicht. Damit ist Feierabend, selbst wenn nicht alle Blöcke gefüllt sind. du zählt offenbar die ungefüllten Blöcke nicht mit. Das Bundle ist eben nur sparse gefüllt und nicht schrumpfend.

Nein, das gilt nur bei Verwendung von Time Machine übers Netz hinweg. Weia verwendet aber ein direkt angeschlossenes Sicherungsmedium.

Ist es denn nicht generell bei SSDs der Fall, dass du und df unterschiedliche Werte anzeigen?

Nein, die beiden Programme arbeiten auf der Ebene des Dateisystems. Das physische Medium spielt keine Rolle und bleibt für diese Befehle komplett unsichtbar.

Wie oben schon angedeutet, kann es Widersprüche geben, wenn sich Dateien während des du-Laufs ändern oder noch offen sind. Eine andere Erklärung wären "DataVaults", also Ordner, die der Systemintegritätsschutz unzugreifbar macht.

Ja, aber meine zweite, beispielhaft gezeigte SSD ist ja gar kein Time-Machine-Volume, sondern ein stinknormales Volume (auf dem die iTunes-Mediendateien liegen).

Es scheint jedenfalls auf all meinen 4 SSDs gleichermaßen der Fall zu sein.
All das gilt aber sicher nicht für mein zweites Beispiel. Da sind einfach die ganzen Musik- und Videodateien für iTunes drauf, sonst gar nichts. Das ist seit Wochen ein völlig statischer Datenbestand und ich wüsste auch nicht, warum da ein DataVault drauf sein sollte. SIP habe ich im übrigen ausgeschaltet, dann müssten die doch sichtbar sein, oder?

Neben offenen Dateien und DataVaults sind mir inzwischen noch weitere Dinge eingefallen, die zu Abweichungen zwischen "du" und "df" führen könnten. Es wäre zu untersuchen, wie "du" sich verhält bezüglich

- Erweiterten Attributen,
- transparenter Dateikompression auf Dateisystemebene,
- APFS-Klonkopien,
- APFS-Firmlinks (die gab es allerdings unter Mojave noch nicht) und
- APFS-Sparse-Dateien.

Apple hängt an vielen Stellen weit damit hinterher, die eigenen Programme wirklich kompatibel mit den neuen Betriebssystemversionen zu machen. Es würde mich nicht wundern, wenn "du" einige neue Systemfunktionen noch gar nicht korrekt beherrscht.

Klingt aufbauend …

Aber das würde ja wohl heißen, im Zweifel df mehr zu glauben, oder?

Ja, df wertet direkt die Statistik des Dateisystems aus. Solange das Dateisystem OK ist, stimmen die Daten auf jeden Fall. Im Prinzip ist df nur ein Aufruf von getfsstat() für alle gemounteten Dateisysteme. Die Daten müssten mit dem Festplattendienstprogramm übereinstimmen, jedenfalls wenn man die gleichen Anzeigeeinheiten wählt.

Obwohl eigentlich Thema dieses Threads, kamen wir der Auflösung des Platzfresser-Problems im verwandten Thread Explodierende Launch-Services-Datenbank? am Schluss näher. Ich habe daher dort in einem Beitrag vom 01.04.2020 um 05:43 Uhr die „Auflösung“ des Rätsels beschrieben.