Hallo allerseits,

ich kämpfe gerade damit, dass die Größe meiner Time Machine-Backups seit meinem Umstieg von Mavericks auf Mojave enorm zugenommen hat.

Einen Schuldigen (wohl nicht den einzigen) habe ich nun ausmachen können, die Launch-Services-Datenbank, in der gespeichert wird, welche Programme zum Öffnen welcher Dateitypen voreingestellt sind und welche Icons die Dokumente daher bekommen sollen.

Diese Datei ist in einem reichlich kryptischen Ordner versteckt; ihr Pfad ist:

[Das Leerzeichen zwischen com und .apple gehört natürlich raus und wurde wieder von der $&§$%&§-Forensoftware eingefügt – was soll der Mist?]

(Die frühere Version, die unter Mavericks verwendet wurde, hieß com.apple.LaunchServices-221-v2.csstore.)

Unter Mavericks war diese Datei bei mir um die 4 MB groß; das ist eine ganze Menge, aber wenn man hunderte von Programmen installiert hat so wie ich, noch plausibel.

Aber unter Mojave ist diese Datei bei mir sage und schreibe 1,6 GB groß. Und sie ändert sich – ohne zunächst erkennbaren Grund – von Stunde zu Stunde, wird also jede Stunde komplett neu in Time Machine gesichert.

Wie zum Teufel kann solch eine Datei so groß werden, und warum ändert sie sich stündlich?

Um der Frage nachzugehen, habe ich die Datei mal analysiert (ist de facto eine plist im Binärformat) und fand, was ich schon befürchtet hatte: Alle Programme sind x-mal eingetragen.

Besonders krass ist es bei Programmen, die nicht in dem systemweiten Ordner /Applications/ (im Finder: /Programme/) liegen, sondern im entsprechenden Order im Heimordner eines Nutzers, also ~/Applications/:

Da speichert die Launch-Services-Datenbank doch allen Ernstes nicht nur das Programm selbst mit seinem Pfad, sondern jeden einzelnen stündlichen Schnappschuss davon in Time Machine ebenso. Und wenn Time Machine die stündlichen Einträge nach einem Tag in einen täglichen zusammenfasst und später die täglichen in wöchentliche, ändert das in der Launch-Services-Datenbank nichts; jeder einzelne stündliche Eintrag bleibt erhalten, auch wenn der Schnappschuss und der entsprechende Pfad längst nicht mehr existieren.

Auf diese Art und Weise hat jedes einzelne Programm in ~/Applications/ bei mir seit der Woche endend 29.09.2019 (in der hatte ich Mojave installiert) sage und schreibe 2616 Einträge! So kommen bei hunderten von Programmen in ~/Applications/ natürlich leicht 1,6 GB zusammen.

Bei Programmen im systemweiten Ordner /Applications/ ist es nicht ganz so schlimm; TextEdit z.B. hat bei mir „nur“ 53 Einträge, manche andere Programme noch weniger, warum auch immer.

Jedenfalls ist somit auch klar, warum sich diese Datei stündlich ändert und somit stündlich neu in Time Machine abgespeichert wird: Denn pro neuer Time-Machine-Sicherung entsteht ein neuer Eintrag pro Programm in der Launch-Services-Datenbank, folglich muss sie in der nächsten Stunde erneut gesichert werden.

Da ich direkt von Mavericks auf Mojave gesprungen bin, kann ich leider nicht sagen, wann der Fehler das erste Mal auftrat; irgendwann nach Mavericks und spätestens bei Mojave muss es gewesen sein.

Das ist ein schier unglaublicher Bug, und dennoch habe ich so gut wie nichts beim Googlen gefunden. Daher frage ich mich, ob nur wenige dieses Problem haben.

Frage daher an alle hier, insbesondere die mit einem ~/Applications/-Ordner in ihrem Nutzerordner und vielen Programmen darin: Habt Ihr auch solch gigantisch große com.apple.LaunchServices-231-v2.csstore-Dateien?

Und weiß irgendjemand was von dem Problem oder gar einer Lösung?

Hallo Weia,

bei mir existiert unter Mojave im besagten Ordner (/private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/0/) sowohl die alte com.apple.LaunchServices-221-v2.csstore von High Sierra (wurde das letzte mal allerdings am 16.03.2019 angerührt), als auch die aktuell in Benutzung befindliche com.apple.LaunchServices-231-v2.csstore.

Die alte ist 27,4 MB groß, die neue 19,6 MB.

Im ~/Applications habe ich allerdings auch nur 13 Apps aktuell.

Hatte ja erst kürzlich im Zuge meines Problems mit den iconservicesagent per OnyX die LaunchServices Datenbank komplett neu erstellen lassen, von daher ist das jetzt auch kein wirklich hilfreicher Vergleich.

Oder gleich direkt per Terminal:


lsregister soll natürlich zusammengeschrieben sein eigentlich …
Und hier /Versions/A /Frameworks/ soll es kein Leerzeichen geben …

Ansonsten fände ich es auch sehr schön, wenn Apple diese ominösen Inhalte der /private/var/folders/ Strukturen mal dokumentieren und erläutern würde, aber das passiert (aus welchen Gründen auch immer) leider nicht.

Eventuell weiß ja Marcel Bresink oder auch sierkb mehr?

PS: Härtestes Mittel wäre ansonsten, einfach mal den gesamten Inhalt von /private/var/folders/ wegzuputzen und danach das System noch einmal sauber drüber zu bügeln – ist aber irgendwie die Holzhammer-Methode und sicher alles andere als elegant. Hat mir aber schon manches mal bei extrem nervigen und verzwickten Fehlern helfen können, wenn gar nichts mehr ging …

Yep, bei mir auch.

Das ist aber ein guter Hinweis darauf, dass sich Format und damit auch Verfahren offenbar von High Sierra auf Mojave geändert haben.
Bei mir leider nicht.
OK, das würde das natürlich für den Moment erklären.
Yep, das werde ich wohl mal versuchen. Danke für den exakten Befehl!
Ja, die ehemalige, noch aus NeXT-Zeiten stammende Idee, dass das System auch für den (erfahrenen) Nutzer transparent sein sollte, ist leider völlig unter die Räder gekommen. Security by obscurity war da leider ein willkommener Vorwand, scheint mir.

Bei mir ist die Datei 12,9MB gross, mehr als 100 Apps, ich benutze aber kein Time Maschine Backup sondern CCC, kein Programmeordner im User. Time Maschine ist so gut als möglich abgeschaltet, local Time Maschine Backups disable, System 10.12.6 auf MacMini 2011. Gleiches System auf Macbook Pro 2011, aber nur für mobiles Recording genutzt, ist die Datei 7,2 MB gross. Es scheint als wäre dies einer der vielen Time Maschine Bugs.

... und so sieht der Ordner bei mir aus
ich habe gestern mal mit dem Tool Mainmenu. meine Lauch Datenbank erneuern lassen. Allerdings habe ich gleich 2 "231er"

Weia
Bei meinem Mojave ist die besagte Datei 387,2 MB groß und trägt das Änderungsdatum des letzten LogIn. Der zugehörige Ordner hat das gleiche Datum. Der Ordner darüber wurde am 13 März 2019 kreiert. Im Ordner "zz" gibt es es noch diverse Unterordner mit kryptischen Namen. Aber die sind alle aus dem Jahre 2019 und leer.

Ich habe keine APPs im Nutzer-Ordner und immer nur wenige Fenster offen.

Dann sind 387,2 MB aber auch schon sehr stattlich; ich würde daher vermuten, dass Du auch von dem Problem betroffen bist, nur weniger stark, da keine Apps im Nutzer-Ordner.

Benutzt Du Time Machine?

Ja, regelmäßig. CC bei bestimmten Anlässen, insbesondere vor dem Updaten.

Ich meine, daß die TM in ihrem Fenster eine Brutto-Angabe für die zu sichernde Datenmenge macht, und vorzeitig meckert, wenn diese nicht mehr in die Partition passt. Netto werden im allg. deutlich weniger Daten gespeichert, da nur die veränderten Blöcke gesichert werden. Beim löschen eines Snapshots ist es umgekehrt: Entfernt werden nur die Blöcke, für die es neuere Inhalte gibt.

Eine Bilanzierung des freien Platzes an Hand der Anzeige im Fenster und/oder der Logdatei (Backup.log) ist nicht möglich.

Ah, OK. Dann würde ich angesichts der Größe Deiner Launch-Services-Datenbank vermuten, dass Du auch von dem Problem betroffen bist. Normalerweise sollte die höchstens 20 MB oder so sein, in der Regel eher 3 MB oder 4 MB.
Tut sie ja auch und sagt dann, beim nächsten mal deshalb alte Backups zu löschen. Und das tut sie dann eben nicht (im Gegensatz zu früher), so dass sie keine Backups mehr macht.
Nö, aber dafür gibt es wie währenddessen in Time-Machine-Platzfresser beschrieben andere Möglichkeiten.

Ist du Disk Utility? Was ist dann df?

Ich würde mit den "anderen Möglichkeiten" erstmal den unvollständigen Snapshot löschen.

Manche Snapshots sind bei mir (brutto) nur 20 bis 30 MB groß. (Auch wenn ich mich zwischendurch abmelde.) Die besagte Datei wird also nicht immer (in voller Länge) gesichert. Wenn das Übel ein Bug ist, muß und kann ich damit leben.

Ach so, nein, sorry, das sind zwei Unix-Programme für die Kommandozeile in Terminal.

Weia
Danke, habe beides in Dash gefunden.

Die angesprochene Datei ist überhaupt nicht "die" Launch-Services-Datenbank. Es handelt sich um die private Datenbank des Benutzers "root". Normalerweise wird dieses spezielle Exemplar überhaupt nicht genutzt und bestenfalls während eines System-Updates angefasst.

Wenn diese Datei aktualisiert wird, würde das entweder darauf hinweisen, dass root fälschlicherweise zur Anmeldung freigeschaltet ist und sich als Benutzer in einer grafischen Bildschirmsitzung anmeldet, oder dass irgendeine Software, die mit System-Privilegien läuft, andauernd meint, irgendwelche Programme für den Benutzer root neu registrieren zu müssen.

Ach so. Woran kann man das denn erkennen (einfach daran, dass der Eigentümer root ist?) und wo befinden sich dann die anderen Launch-Services-Datenbanken?

(Es leuchtet natürlich bei näherem Nachdenken ein, dass jeder Nutzer seine eigene Datenbak hat, denn es kann ja jeder Nutzer auswählen, welches Programm welches Dateiformat öffnet. Aber da die Datei für alle lesbar ist, hätte ich von daher jetzt nicht zwingend auf root geschlossen.)
Meinst Du damit, dass der root-Nutzer aktiviert wurde? Das ist bei mir in der Tat der Fall. Aber wieso „fälschlicherweise“? Das ist doch eine ganz offiziell vorgesehene und gestattete Funktion. Ich würde darauf jedenfalls nicht verzichten wollen.

Das allein erklärt doch aber jedenfalls nicht, wieso die Launch-Services-Datenbank von root sämtliche Time-Machine-Schnappschüsse mit einbezieht. Dieses Problem tritt ja auch erst seit Mojave auf und ist insofern aus meiner Sicht klar ein Bug.
Ab und an tue ich das, weil es GUI-Programme gibt, die das erfordern (das im parallelen Thread Time-Machine-Platzfresser diskutierte Programm Time Tracker ist just so ein Fall).

Im übrigen, wenn da ein ursächlicher Zusammenhang besteht, dannn dürfte das Problem ja nur bei Nutzern auftreten, die root aktiviert haben.

Nach seinen Angaben zu schließen hat Wiesi auch mein Problem, da bei ihm die root-Launch-Services-Datenbank mit knapp 300 MB auch viel zu groß ist. Wiesi, hast Du den root-Nutzer aktiviert?
Wie würde eine solche Software das denn anstoßen?

Schon lange nicht mehr. Jedenfalls nicht unter Mojave. Nutze nur noch normale Admin-Rechte. Die von mir beobachtete Datei bekommt jedenfalls mit jeden Login (auch ohne Admin-Rechte) einen neuen Zeitstempel. Meine Datei muß jedoch nicht unbedingt die von @Marcel genannte sein.

Inwiefern? Ist das gar nicht /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/0/com .apple.LaunchServices-231-v2.csstore?

Weia




Scheint, die gleiche zu sein, wie bei Dir. Beachte das Änderungsdatum. Ich bin z.Zt ohne Root- und ohne Admin-Rechte eingelogt.

Die "echten" Arbeitsdaten der Launch-Services befinden sich in modernen Systemversionen für jeden Benutzer unter

`getconf DARWIN_USER_DIR`/com.apple.LaunchServices.dv

Das ist allerdings ein DataVault, d.h. dieser Ordner ist für jeden anderen Prozess unsichtbar und unzugreifbar solange der Systemintegritätsschutz eingeschaltet ist.

Der hier angesprochene, für den Benutzer einsichtbare Teil der Daten lag bei Mojave jeweils in einer Datei unter

`getconf DARWIN_USER_DIR`/com.apple.LaunchServices-231-v2.csstore .

Ich würde das eher für ein Überbleibsel aus alten Systemversionen halten, das nur zur Vermeidung von Kompatibilitätsproblemen noch nicht entfernt wurde.

Vermutlich dürfte unter anderem ein Aufruf nach dem Motto "sudo … lsregister …" diese Datei aktualisieren. Es wäre aber zu prüfen, was passiert, wenn man sich tatsächlich als root in einer Bildschirmsitzung von Mojave anmeldet.

Nachtrag: Mojave verhält sich diesbezüglich komplett anders als Catalina. Bei Mojave scheint es tatsächlich Prozesse zu geben, die die Datei von root regelmäßig aktualisieren.

Weia
Nachtrag: Laut @Marcel müßte bei mir irgend eine App, wie auch immer, Root-Rechte ergattert haben. Wie prüfe ich daß?

Nein, wie gesagt war das ein Missverständnis. In älteren Versionen von macOS wird diese root-Datei offenbar vom Betriebssystem selbst zu bestimmten Zeitpunkten aktualisiert, ohne dass eine App das anstößt oder sich root anmeldet.

Habt ihr vielleicht Konstruktionen wie zyklische symbolische Links, was ein Aufblähen der Datei erklären könnte? Oder verwendet ihr fremde Backup-Software (also etwas anderes als Time Machine), die regelmäßig Kopien aller Programme anlegt?

Ah, OK, d.h. ich kann mit
jeweils den Ordner mit kryptischem Namen, in dem die Daten des aufrufenden Nutzers liegen, herausfinden, muss dazu aber eben zunächst mal als dieser Nutzer angemeldet sein.

Leuchtet aus Sicherheitsperspektive ein (wobei es dann allerdings inkonsequent scheint, dass der kryptische Dateiname offenkundig stets gleich mit dem Nutzernamen verkoppelt ist, so dass die Daten für root auf allen Macs im selben Ordner liegen).

Gut zu wissen. Ich bin jemand, der von Sicherheitsvorkehrungen ganz schnell genervt ist und sie übertrieben findet, weswegen ich irgendwann den Überblick über all die entsprechenden Mechanismen in macOS verloren habe.

Jedenfalls scheint Wiesis Fall zu zeigen, dass das Problem mit der explodierenden Größe der Launch-Services-Datenbank nicht 1:1 mit der Frage zusammenhängt, ob root nun aktiviert ist oder nicht. Ist auf jeden Fall ein Bug, würde ich sagen.

Ich habe mir jetzt dank Deiner Erläuterung mit DARWIN_USER_DIR mal „meine“ Launch-Services-Datenbank angesehen, und die ist 70 MB groß. Auch noch ganz schön groß (allerdings habe ich auch viele 100 Programme installiert), aber doch eine ganz andere Hausnummer als 1,6 GB …

Ah, OK. Das stimmt dann soweit mit meinen Überlegungen überein. (Sorry, ich sehe Deinen Beitrag erst jetzt, wo ich meinen letzten abgeschickt habe.)
Weder noch.

Und wie gesagt, ich habe mir den Inhalt der Datei ja angesehen, die riesige Größe resultiert ausschließlich aus der Tatsache, dass für jeden stündlichen Time-Machine-Schnappschuss alle Programme (zumindest die, die innerhalb von Nutzerverzeichnissen liegen) erneut aufgelistet werden und auch nicht mehr gelöscht werden, wenn die Schnappschüsse in Time Machine auf wöchentliche konsolidiert werden.

Bei mir ist SIP aktiv:

Eine Idee zur näheren Eingrenzung wäre, sich die betroffene Datenbank im Klartext anzeigen zu lassen. Möglicherweise kann man daraus etwas sehen, was auf die Ursache hinweisen könnte. Das Problem ist, dass die Klartextfassung wahrscheinlich noch viel größer als die csstore-Fassung sein wird.

In Mojave und aus Sicht von root ginge das mit


(Durch die Forensoftware eingefügte Leerzeichen sinngemäß entfernen.)

Naja, das hatte ich ja schon gesagt: Es wird einfach jedes Program für jeden Time-Machine-Schnappschuss erneut aufgelistet.
Stimmt, 2,45 GB. Und ich würde die aus Datenschutzgründen auch ungern öffentlich machen.

Aber hier einfach ein simples Beispiel:

Und dieser Eintrag findet sich nun satte 2700 mal in der Datenbank, immer nur mit einem anderen Datum im Schnappschuss-Pfad.

Und so ist das mit all meinen hunderten anderen Programmen auch … Auf diese Weise kommen problemlos 2,45 GB zusammen …

Bei mir (auch Mojave):
221-v2 16 MB
231-v2 33,2 MB
Root nicht aktiviert, Admin nur als Passworteingabe bei Installationen etc. 150 Apps, 15 davon in meinem Profil.

Letztere Datei trägt das heutige Datum. Allerdings weigert sich Time Machine seit einiger Zeit ein Backup zu machen und möchte, um die "Reliability" zu verbessern, ein neues Backup machen.

So einfach ist das nicht. Man sieht hier schon einen interessanten Effekt: Es sind nämlich nicht die kopierten Programme in den Time Machine-Schnappschüssen. Es sind die Programme in den APFS-Schnappschüssen, die als Quelle zur Erstellung der Time Machine-Schnappschüsse dienen.

Dass sich davon ein paar Exemplare in der LS-Datenbank niederschlagen, ist normal. Aber das sollte sich normalerweise auf die letzte Datensicherung und ein paar davor, die bereinigt wurden, beschränken. Die bereinigten erhalten irgendwann den Vermerk "Bundle node not found on disk: Error Domain=NSCocoaErrorDomain Code=4 'The file doesn’t exist.'" und fliegen dann beim nächsten Mal raus.

Könnte es sein, dass aus irgendeinem Grund mehrere Generationen von APFS-Quellen für die Datensicherung immer noch als unsichtbare Volumes gemountet sind? Zeigt "mount" die immer noch als aktiv unter "/Volumes/com.apple.TimeMachine.localsnapshots" an?

Stimmt! Das ist mir überhaupt nicht aufgefallen in dem ganzen Fehlersuchstress. Es gilt aber in der Tat ausnahmslos für alle Einträge.
Ja, und das ist nicht der Fall. Es sind (höchstwahrscheinlich lückenlos) alle stündlichen Schnappschüsse seit Ende September 2019 vorhanden, als ich Mojave installiert habe.
mount zeigt nicht mal einen einzigen solchen Eintrag an. Oder müsste ich irgendwelche Argumente eingeben?

Nein, nur "mount". Aber wie ich im anderen Thread sehe, hast Du den Rechner inzwischen neu gestartet. Dann sind die Einträge natürlich auf jeden Fall weg, bis Time Machine wieder läuft.

Es wäre dann interessant zu sehen, ob Time Machine nur den letzten und vielleicht noch die zu bereinigenden APFS-Schnappschüsse mountet. Wenn ja, müsste die LS-Datenbank danach eigentlich wieder schrumpfen.

Ich versuche mal, Time Machine anzuwerfen, und gucke, falls es überhaupt geht, was mount dann sagt. Ich werde dann berichten.
Nachdem sie das jetzt ein halbes Jahr lang nicht getan hat, ist meine Hoffnung da ja eher gering …

Ich sehe gerade in Systemeinstellungen → Time Machine den schönen Satz:

Time Machine behält * lokale Schnappschüsse, solange Speicherplatz vorhanden ist

Wo speichert Time Machine denn lokale Schnappschüsse bzw. um welchen Speicherplatz geht es da? Von dem Quellvolume oder dem Time-Machine-Volume?

Wenn APFS-Volumes gesichert werden, geht es dabei um APFS-Schnappschüsse als Quellen, die bei einem eventuellen Zurückladen aber genauso wie Time Machine-Schnappschüsse verwendet werden können. (Eine Time Machine-Gesamtwiederherstellung kann dadurch in wenigen Sekunden durchgeführt werden, da hierbei in Wirklichkeit nur ein Zurückrollen eines APFS-Schnappschusses erfolgt.)

Die Schnappschüsse sind im gleichen APFS-Container gespeichert wie die jeweilige Quell-Volumes. In den Quell-Volumes selbst sind sie unsichtbar und schlagen sich auch nirgendwo als Datei oder Ordner nieder.

Gut, also geht es bei dem zitierten Satz aus der Time-Machine-GUI um den Speicherplatz auf den Quell-Volumes.
Schlagen sie sich denn in der Speicherplatz-Anzeige irgendwie nieder oder gelten sie als freier Speicherplatz, da sie ja bei Bedarf gelöscht werden können?

Ich bin mal gespannt – seit fast 2 Stunden läuft jetzt Time Machine mit dem wenig hilfreichen Hinweis Verbleibende Zeit berechnen …, von den 250 GB freiem Speicherplatz auf dem Time-Machine-Volume sind gerade mal noch 50 GB übrig, obwohl sich in den Tagen seit dem letzten Update schwerlich mehr als 2 GB an Daten verändert hat (ich habe leider vergessen, ein tmutil compare vor dem Anwerfen von Time Machine zu machen), und im Finder ist noch nichts von einem neuen Schnappschuss zu sehen, auch nicht .inProgress.

Ich gehe mal davon aus, dass mir Time Machine bald mitteilt, es sei nicht genügend Speicherplatz vorhanden, und alles ist wieder so wie schon gehabt.

In Apples Terminologie ist dieser Speicher "verfügbar", aber nicht "frei". Der Verbrauch wird normalerweise nur auf der Dateisystemebene sichtbar, z.B. im Festplattendienstprogramm.

Während das läuft, müsstest Du die Schnappschüsse als virtuelle Volumes mit "mount" oder "df" sehen können.

Äääääh – was zum Teufel ist denn da los?

ich habe jetzt noch rasch tmutil compare laufen lassen (der Befehle vergleicht, wie viel sich seit dem letzten Backup verändert hat), und das Ergebnis ist:

Es hat sich demnach nichts verändert, aber 1,5 TB müssten entfernt werden und 2,1 TB müssten neu gesichert werden – das ist die Gesamtgröße des Quell-Volumes …

Das kann natürlich nicht funktionieren und ist auch völliger Unsinn.

Ich stoppe das Backup jetzt erstmal. So hat das ja keinen Sinn.

Ah, sehr guter Tipp, danke, das hätte ich in dem Tohuwabohu doch jetzt glatt vergessen!

Nein, es gibt genau zwei Schnappschüsse, den vom letzten erfolgreichen Backup und den vom Start des heutigen Backups.

@Weia: Ich will mal kurz meine nicht-technische Sicht (für was anderes reicht's nicht) dazu beitragen: Nimm einen guten Hunderter in die Hand und kaufe Dir eine weitere Platte, auf der Du ein weiteres aktuelles back-up mittels TimeMachine durchziehst, wenn Du das nicht alles längst schon hast:-)
(Bei mir ist es so, dass ich einer solchen Situation mal durchaus etwas mache, was ich nachher als falsch bezeichne )

Noch eine Idee: Es gibt inzwischen Programme, die tatsächlich die APFS-Funktion "sparse files" nutzen.

Wenn Du so eine dünn besetzte Datei hättest, würde deren Sicherungskopie von ihrer physischen Größe auf die deklarierte Größe anwachsen, da sie im HFS+-System von Time Machine nicht mehr als solche dargestellt werden kann.

Das kann auch die Ursache für unerwarteten Speicherbedarf einer Time Machine-Sicherung sein.

Ich habe ja weitere Backups, nur keine Versionierung, die bis 2013 zurückreicht. Nur um die geht es mir, da hilft mir auch kein weiteres frisches Time-Machine-Backup.

Außerdem will ich verstehen, was da los ist, sonst bin ich demselben Mist in Zukunft ja vielleicht weder ausgeliefert.

Außerdem gibt’s im Augenblick keine ≥4 TB SSDs für einen guten Hunderter, und Time-Machine-Backup auf Festplatte würde ich mir nicht mehr antun.

[Obwohl sich dieser Thread ursprünglich nur mit einem Teilaspekt meines Time-Machine-Problems beschäftigte, kamen wir hier am nächsten an die Problemursache heran, weswegen ich hier die Auflösung poste und in den anderen Threads dann darauf verweisen werde.]

Auflösung Time-Machine-Problem

Wie erwartet, hat Time Machine auch bei meinem erneuten Anlauf zu einem Backup nach mehreren Stunden berichtet, dass der Platz zu einem Backup nicht ausreiche (ich hatte sie dann doch nicht manuell gestoppt, um zu verifizieren, dass dies erneut passieren würde).

Wieder war zu diesem Zeitpunkt der freie Platz auf dem Time-Machine-Volume von zunächst 245 GB laut df auf 0 geschrumpft. Wiederum komplett aufgebraucht von eine Schnappschuss .inProgress, der offenkundig noch hätte weiter wachsen wollen.

Also habe ich (als root) zunächst mal wieder diesen Ordner gelöscht, um erstmal freien Platz zu schaffen:
Danach waren laut df die fehlenden 245 GB wieder da.

Den entscheidenden Hinweis auf das Problem gab dann das oben erwähnte tmutil compare, das wie gesagt vergleicht, wie viel sich seit dem letzten Backup verändert hat und folglich wie groß das nächste Backup werden würde. Der bei mir zurückgegebene Wert war mit 2,1 TB nicht nur absurd groß, es war vor allem schlicht die exakte Größe meines gesamten Datenbestandes auf dem zu sichernden Volume. Mit anderen Worten: Time Machine hat nicht mehr begriffen, dass die bereits vorhandenen Backups irgendwas mit dem zu sichernden Volume gemein haben, weswegen das komplette Quell-Volume neu gesichert werden müsse. Und dafür reicht selbstverständlich der Platz nicht.

Durch das macOS-Sicherheitsupdate war also offenbar die Kopplung zwischen Quell-Volume und Backup-Volume verloren gegangen. Normalerweise passiert das, wenn man entweder die Daten von Quell-Volume oder Backup-Volume auf ein neues physisches Speichermedium migriert (neuer Mac, neue SSD oder HD im Mac, neue Backup-SSD oder -HD, auf die die Daten der alten geklont wurden). Dass ein Sicherheitsupdate das bewirken kann, obwohl es das definitiv nicht sollte, wirft einmal mehr ein schlimmes Licht auf den Verfall der Software-Qualität bei Apple.

Da ich ja nicht wusste, welches Volume durch das Sicherheitsupdate fälschlich als geändert angesehen wurde, habe ich zunächst das Backup-Volume wieder korrekt registriert:

Danach zeigte tmutil compare aber leider noch immer 2,1 TB Platzbedarf für das Backup an.

Also habe ich als nächsten Schritt auch das zu sichernde Quell-Volume wieder korrekt registriert:

Und siehe da, danach zeigte tmutil compare nur noch 2 GB Platzbedarf für das Backup an. Das war – nach fast einer Woche und einem zwischenzeitlich durchgeführten Sicherheitsupdate – als Größe natürlich völlig plausibel, und so startete ich Time Machine von der GUI erneut und das Backup funktionierte problemlos.

Leider liegt es in der Natur der Sache, dass ich nun nicht sagen kann, ob zum Erfolg inheritbackup auch erforderlich war oder associatedisk allein gereicht hätte. inheritbackup allein reichte jedenfalls nicht. Ich neige zu der Annahme, dass associatedisk allein gereicht hätte.

Ja, während des jetzt wieder funktionierenden Backups waren lediglich der aktuelle und der letzte Schnappschuss gemountet.
Sieht nicht so aus. Die root-Launch-Services-Datenbank wurde unmittelbar nach Abschluss des Backups vom System aktualisiert und ist jetzt 1,7 GB statt 1,6 GB groß. Das ist wohl ein weiterer der vielen üblen Bugs in Mojave. Von meinem Time-Machine-Backup habe ich die Datei ja nun ausgeschlossen, diesbezüglich soll mir das jetzt also egal sein.

Weia
Hier ein paar statistiche Daten eines Kleinverbrauchers:

Initialer Backup am 16. März 2019
Größe brutto: 151 GB; Dito netto: 120 GB
Besagte Datei: 46,7 MB
Aktueller inkrementaler Backup:
Größe brutto: 3,63 GB; Dito netto: 1,3 GB
Besagte Datei: 389,8 MB
Die gesamte Backup.db beträgt zur Zeit 458 GB!!! Die fsUUIDs von Quelle und Senke haben sich über alle Updates hinweg nicht geändert.



Die obigen Daten stammen direkt von der TM und stimmen in etwa mit den Angaben des Festplattendienstprogramms überein, wenn man annimmt, das die TM ein etwa 40 GB großes Dienstgeheimnis, für den Finder unsichtbar, im Keller verbirgt.

Besonders verwirrlich ist, daß TM den freien Platz auf dem Volume als "verfügbar" bezeichnet. Hingegen weißt das Dienstprogramm den verfügbaren Platz als "frei" + "löschbar" aus. (Löschbar sind bei mir zur Zeit 8 GB.)

Ich habe früher mal ein geniales Programm namens "Timetracker" verwendet. Das konnte für mich immer klären, warum ein bestimmter Datensicherungsvorgang besonders lange dauerte. Leider läuft es nicht mehr, weil es irgend ausgelaufen ist... Vielleicht weiß ja jemand etwas über den Verbleib. Dafür brauchte man keine Kommandozeile.

Ich sehe gerade, es gibt eine neuere Version, die ist vom Sommer 2019, die tut noch.

Ja, das wurde oben ja erwähnt.
Bei dem hier ursächlichen Problem hätte es Dir aber leider Null helfen können, weil es Dir weder sagen kann, wie groß das nächste Update sein wird (tmutil compare), was ja das entscheidende Indiz für die Fehlerdiagnose lieferte, noch die Werkzeuge anbietet, Quell- und Backup-Volume wieder einander korrekt zuzuordnen.

Für Ersteres kenne ich überhaupt keine GUI-Lösung, für Letzteres bietet z.B. TinkerTool System von Marcel Bresink eine GUI. Aber da muss man das Problem eben schon erkannt haben.

Aber es ist jetzt auch nicht soooo schwer, tmutil compare in ein Terminal-Fenster einzugeben und zu drücken.