Auf einem externen Laufwerk habe ich ein mitwachsendes Bundle-Image mit einer maximalen Größe von 1TB angelegt, das ich für TimeMachine-Backups nutze. Diese habe ich eher unregelmäßig angelegt und etwa ein Backup pro Monat aufbewahrt seit etwa dem Jahreswechsel 24/25. Das hat bislang alles prima funktioniert.

Nun habe ich kurz nach dem Release von macOS Tahoe mein System darauf aktualisiert und heute ein neues Backup anfertigen wollen. Ergo das Image vom externen Laufwerk gemountet und mich spontan gewundert, dass im erschienenen Fenster nur noch drei Backups angezeigt wurden: das von Ende Juni, das Mitte August und das Mitte September. Die restlichen seit Jahresanfang gab's offenbar nicht mehr. Mein erster Gedanke war, nachdem das Backup fertig war, dass TimeMachine wegen Platzbedarf zu alte Backups entfernt hat.

Was aber merkwürdig ist und eigentlich nicht sein kann:
Das Festplattendienstprogramm zeigt mir an, dass auf dem Volume (999,79GB groß) nur 439,06GB belegt und 36,02GB frei seien:

Etwas gut 500GB, die eigentlich noch vorhanden sein müssten, scheinen irgendwie verschwunden. Nur: Wohin? Ein Volumecheck jedenfalls lief ohne Probleme durch.

Das "mitwachsend" bzw. "sparse" heißt, dass nur der benötigte Speicherplatz auf dem Laufwerk belegt wird. Die Maximalgröße ist dennoch begrenzt. Bei Dir vermutlich um 500 GB. Du kannst nachträglich die Maximalgröße des Sparsebundle mit dem Tool "Spundle" von Howard Oakley ändern.

Dass der Platz mitwächst weiß ich. Das Image hatte ich damals direkt aus dem Festplattendienstprogramm angelegt mit 1TB maximaler Größe, genau das was oben im Screenshot auch zu sehen ist.
Es waren wie erwähnt auch einige Backups vorher vorhanden und AFAIR mehr Platz im Image belegt.

Was mich wie gesagt wundert ist, dass das Dienstprogramm mir ja 1TB Größe anzeigt, weit weniger als die Hälfte belegt ist und der Rest irgendwie.... verschwunden zu sein scheint.

Ein ähnliches Phänomen hatte ich auch an anderer Stelle schon einmal:

Die SSD im Mac ist mit case-sensitivem APFS formatiert. Ein paar Spiele, die ich über GOG gekauft habe, laufen aber nur, wenn sie von einem case-insensitiven Volume gestartet werden. Daher hab ich mir (ebenfalls über das Festplattendienstprogramm) ein mitwachsendes Image von 200GB Größe mit case-insensitivem APFS angelegt und die Spiele dort abgelegt. Das alles lief soweit auch prima. Als für zwei davon über GOG Galaxy Updates angezeigt wurden, ließen sich die nicht aktualisieren; es sei kein Platz mehr frei.
Ok, eins davon gelöscht, über GOG Galaxy das andere versucht zu aktualisieren => gleicher Fehler. Das Festplattendienstprogramm hat mir trotz Löschens zweier dieser Programmmonster (~40GB) (Papierkorb war geleert) diesen Platz nicht mehr ans frei angezeigt. Selbst als ich alles, was in dem gemounteten Image drin war, auf mein normales System-Volume verschoben, also im Image gelöscht habe, wurde mir der eigentlich frei gewordene Platz nicht mehr als solcher angezeigt

Mein Fazit bis hierher:

Bei einem mitwachsenden Bundle-Image werden gelöschte Files nur als gelöscht markiert, der so frei gewordene Platz aber nicht tatsächlich frei gegeben, so dass es zu oben beschriebenen Phänomen kommt.

Hat vielleicht irgendjemand eine Idee, woran das liegt?

Interessantes Phänomen:
Im Festplattendienstprogramm habe ich über Images => Größe ändern... mal versucht die Größe des Backup-Images auf 500GB zu ändern. Nach kurzer Zeit gab's diese Fehlermeldung:

Vorgang mit Status 1 fehlgeschlagen: Der Vorgang konnte nicht abgeschlossen werden. Der Vorgang ist nicht zugelassen

Aktion fehlgeschlagen …

Ein erneutes Mounten des Images jedoch zeigt mir eine geänderte Größe an:
Auch hier passt die Anzeige nicht: belegter + verfügbarer Speicher ist um 25GB von der Kapazität entfernt...

Ändere ich die Größe erneut auf 1TB, dann gibt es zwar die gleiche Fehlermeldung; es scheint aber dennoch etwas passiert zu sein, denn beim erneuten Mounten des Images wird mir wieder eine Kapazität von 1TB angezeigt; beim belegten und verfügbaren Speicher hat sich im Vergleich zum Schritt davor aber exakt *nichts* getan...

Ich mutmaße, dass durch das Update ein Vollbackup erforderlich war. Dadurch hat macOS Platz geschaffen, um alle Daten zu sichern. Dabei wurden dann die älteren Backups entfernt.
Habe so was schon häufiger erlebt, dass nach einem Update alle Daten als neu bzw. geändert angesehen wurden, obwohl sich daran nichts geändert hat.
Ich hoffe, Du brauchst nicht dringend Zugriff auf die älteren Generationen. Bis zum nächsten Major Release solltest Du jetzt aber wieder neue Backup-Versionen aufbauen können...

Achtung es folgt Halbwissen und soll nur als Anregung zum Suchen an der richtigen Stelle dienen.

Weshalb deine älteren bäckup Dateien gelöscht wurden obwohl die Platte, soweit ich verstehe, nicht dauerhaft verbunden ist, ist unklar.

Zur Herausforderung mit den sparse bundles … da würde ich tatsächlich auf der website von Howard Oakley suchen. Obwohl ich keinerlei praktische Erfahrung damit habe, erinnere ich mich daran einiges zu sparse bundles gelesen zu haben. Insbesondere, dass gelöschte Daten nicht als freier Platz gezeigt wird. Das scheint alles nicht so einfach und klar mit dem freien Platz.
Ein Ansatz war wohl, die Daten von einem sparce bundle in ein NEU angelegtes zu kopieren.

Suche einfach mal auf seiner Seite.

Das scheint nicht der Fall gewesen zu sein, dafür war er viel zu schnell fertig. Jedenfalls wurden keine hunderte GB gesichert. Das Platz schaffen bei nicht genügend freiem Platz kenne ich bereits, das ist auch durchaus ok.
Das zum Glück nicht
Was mich generell wundert ist, dass nach explizitem Verkleinern auf die Hälfte der maximal erlaubten Größe der als frei markierte Platz exakt identisch ist zu vorher, ebenso wenn ich anschließend dem verkleinerten Image erlaube, wieder auf die doppelte (sprich ursprüngliche) Größe anwachsen zu können. Da scheint mir freier Platz zu verschwinden, und das sollte nicht sein...

Vielleicht ist einfach die Anzeige der 999 GB im FPDP falsch? Das ist ja die maximale Größe, die das Bundle erreichen kann - aber offensichtlich noch nicht erreicht hat, sonst könnte man es ja nicht auf 500 GB (max) verkleinern.

Über das FPDP kann ich das Image sehr wohl verkleinern auf 500GB. Es gibt zwar eine Fehlermeldung, siehe weiter oben, aber beim erneuten Mounten wird mir 500GB als Größe angezeigt. Auch wenn wie oben beschrieben die Angabe belegter + verfügbarer Platz nach wie vor nicht mit der Kapazität von 500GB übereinstimmt.

Dieser Ansatz ist etwas ungewöhnlich. Es hätte gereicht, einfach ein neues Volume mit Kontigentierung für Time Machine anzulegen.

Bei einem Time Machine-Ziel-Volume in APFS befindet sich nur die letzte Datensicherung auf dem Volume selbst. Alle anderen Sicherungen (für die Zeitpunkte davor) befinden sich in APFS-Schnappschüssen dieses Volumes, d.h. auf anderen virtuellen Volumes, die gar nicht gemountet sind, wenn Time Machine nicht gerade aktiv ist. Normalerweise wird der Speicherbedarf für die Schnappschüsse zum Speicher des sichtbaren Volumes dazugerechnet, aber es sieht so aus, als würde das Festplattendienstprogramm das bei einem Bundle-Image nicht machen, vielleicht weil dessen Größe auch nur virtuell ist.

Nicht ungewöhnlich, sondern überholt. Es gab eine Phase, in der Quotas von Time Machine nicht zuverlässig erkannt wurden und Backups unkontrolliert wuchsen. Der manuelle Sparsebundle-Workaround war ein Workaround für dieses Problem.

Auf Synology DiskStations mit Btrfs-Dateisystem lässt sich seit DSM 7 eine Quota direkt auf Shared Folder-Ebene setzen. Das war früher nicht möglich. Alternativ zur Folder-Quota funktionieren heute auch User-Quotas zuverlässig. Die Quotas begrenzen den Speicherplatz für Time Machine-Backups, ohne dass man manuell Sparsebundles erstellen muss. Bei mir sichert die Time Machine mittlerweile zwei Macs direkt in zwei freigegebene Ordner.

Das konnte nur passieren, wenn ein fremdes Dateisystem im Spiel war, also man z.B. per Netzwerk auf einen File Server gesichert hat. In dem Fall muss aber sowieso ein Bundle-Image eingesetzt werden.

Das ist eigentlich überflüssig, da Time Machine bei Netzwerksicherungen eine per Client konfigurierbare Kontigentierung ("Quotas") bereits selbst unterstützt, egal ob der Ziel-Server das kann oder nicht.
Und wie gesagt kann man bei lokalen Sicherungen, um die es ja hier geht, einfach APFS-Kontingentierung für das Ziel-Volume einschalten.

Ungewöhnlich, mag sein. Hintergrund ist, dass ich drei externe Platten zu einem 3-Wege-ZFS-Pool zusammengeschlossen habe (Redundanz), und darauf liegt das Image. Mein Gedanke war, dass in einem mitwachsenden Image für TimeMachine bei Bedarf ältere Snapshots entfernt werden können, so dass der Platz nach Kompaktierung idealerweise wieder frei wird und für den Rest des ZFS-Pools bereitsteht.
Ok, danke für diese Erklärung.

Vielleicht sollte ich das Backup-Image komplett neu anlegen und statt eines mitwachsenden Images eines mit einer fixen Größe nehmen. Darauf sollte das beschriebene Problem hoffentlich nicht (mehr) auftreten.

Oben hieß es noch, die Daten würden auf einem externen Laufwerk liegen. Was sollen solche falschen Angaben? Und ZFS wurde von Apple nur in Mac OS X 10.5 Leopard Beta unterstützt. Wird Drittanbieter-Software für das Dateisystem genutzt? Oder liegen die Daten auf einem File Server, was dann wieder ein ganz anderes Dateisystem wäre?

Wenn das Zieldateisystem nicht "APFS (Groß-/Kleinschreibung)" ist, muss natürlich zwingend ein Image zum Einsatz kommen. Die Situation wird dadurch komplett verändert.

Der ZFS-Pool ist für mich ein externes Laufwerk. Entschuldige bitte, wenn das zur Verwirrung geführt hat; ich dachte nicht, dass das eine große Rolle spielt. Dass hierfür natürlich zwingend ein Image zum Einsatz kommen muss, ist klar. Ich glaube mich aber daran zu erinnern, dass das früher durchaus funktioniert hat, wenn man innerhalb TimeMachine ältere Backups gelöscht hat, dass der davon (real) belegte Teil innerhalb des Images auch korrekt freigegeben wurde. IMHO scheint das aktuell nicht so richtig (mehr?) der Fall zu sein.

Für ZFS nutze ich seit einer gefühlten Ewigkeit den macOS-Port von Jorgen Lundman, siehe