flokrus Blog

(This article is also available in English.)

Dieser Artikel bezieht sich auf einen Vorgängerartikel zum Thema Time-Machine-Backups auf Netzwerkfreigaben unter Leopard.

Aus den Kommentaren in der englischen Version des ersten Artikels kam ein Hinweis auf einen Thread in Apples Supportforen, der auf ein Problem mit Time Machine und Netzwerkfreigaben hinweist (Danke an John M dafür).

Um das Problem zu erklären muss man sich jedoch erst klar machen, wie Bundle-Images (die Time Machine für Netzwerk-Backups verwendet) funktionieren. Sparse-Bundle-Images („mitwachsendes Bundle-Image“) und Sparse-Images („mitwachsendes Image“) sind spezielle Formen eines Disk-Images mit bestimmten Vorteilen. Ein Disk-Image ist vereinfacht gesagt nur eine Datei, die wie ein Laufwerk (z. B. eine Festplatte) behandelt wird. Die Image-Datei liegt auf einem echten Laufwerk (lokal oder im Netz), dass ich als Container bezeichnen werde.

Das Image kann man ins System einbinden („mounten“) und dann wie ein Laufwerk verwenden. Mac OS X kümmert sich darum, die Daten in die Image-Datei zu schreiben. Prinzipiell ist ein Image also im einfachsten Fall eine Datei, die genauso groß ist, wie die Maximalgröße des virtuellen Laufwerks. Erstellt man also ein Disk Image mit 100 GB Kapazität, hat man eine 100 GB große Datei, selbst wenn im Image nur wenige MB belegt sind.

Und hier kommen die Sparse-Images ins Spiel. Diese belegen nur den Platz, den auch die Daten im Image belegen. Man kann also ein Image mit 100 GB Kapazität erstellen, das als Datei nur wenige MB groß ist. Erst wenn das Image mit Daten gefüllt wird, wächst auch die Image-Datei.

Allerdings hat die Sache einen Haken. Das Löschen von Daten im Image sorgt nicht dafür, dass die Image-Datei kleiner wird. Anschaulich: Erstelle ich im Image eine 10 GB große Datei, wird die Image-Datei 10 GB groß, der freie Speicher im Image beträgt 90 GB. Lösche ich die Datei anschließend, sind im Image wieder die kompletten 100 GB frei. Die Image-Datei selber behält aber ohne Weiteres ihre Größe von 10 GB*. Innerhalb des Images ist also alles in Ordnung. Durch Benutzung des Images wird die dazugehörige Datei selbst höchstens gleich groß bleiben, meistens wachsen (indem weitere Dateien im Image erstellt werden), aber von alleine nie kleiner werden. Dies ist ein Teil des Problems.

Der andere Teil liegt in einem Verhalten vom Mac OS X, das sonst eigentlich sehr nützlich ist. Mac OS X hindert den Nutzer nicht, ein Sparse-Image zu erstellen, dessen Maximalkapazität den freien Platz oder gar die Maximalkapazität des Containers überschreitet. Prinzipiell ist das natürlich ein Problem. Nehmen wir unser frisches Image mit 100 GB Kapazität. Dieses liege in einem Container mit 20 GB freiem Speicher. Im Image könnte der Benutzer nun eine 30 GB große Datei erstellen wollen, was natürlich nicht funktionieren kann.

Hier verhält sich Mac OS X vergleichsweise schlau. Wird ein Image gemountet, prüft Mac OS X wie viel Platz im Container frei ist (hier 20 GB). Ist dieser Wert kleiner als der formal freie Platz im Image (hier ca. 100 GB), so wird Mac OS X den freien Speicher im Image auf den freien Speicher im Container begrenzen. In unserem Beispiel: Das Image hätte eine Maximalkapazität von 100 GB und 20 GB freien Speicher. Und das, obwohl auf dem Image noch gar keine Daten liegen!

An sich ist dieses Verhalten sinnvoll, im Zusammenspiel mit Time Machine jedoch kann es fatale Folgen haben. Angenommen wir erstellen im obigen Image eine 18 GB große Datei. Die Image-Datei wird auf 18 GB anwachsen, im Container wie auch im Image sind anschließend nur noch 2 GB frei. Jetzt löschen wir die 18 GB große Datei wieder. Im Image werden dadurch formal 18 GB frei.

Aber nun kommen die beiden obigen Effekte ins Spiel. Die Image-Datei wird ihre Größe von ca. 18 GB behalten. Im Container sind daher nur 2 GB frei. Also sind auch im Image nur 2 GB frei. Das Löschen der Datei im Image hat also keinen zusätzlichen Platz geschaffen. Möchten wir nun erneut eine 18 GB große Datei erstellen, wird Mac OS X dies nicht erlauben. Umgehen lässt sich das Problem, wenn im Container immer genug freier Speicher verfügbar ist. In unserem Fall müssten wir also dort mindestens 16 GB frei machen*.

Haben wir in der obigen Ausgangssituation im Container nicht 20 GB sondern 120 GB frei, wird sich Mac OS X beim freien Speicher immer am Image orientieren. Das Löschen der 18 GB großen Datei wird also tatsächlich dazu führen, dass im Image wieder 100 GB Speicher frei werden. Hier zeigt sich auch, wie fatal es ist, wenn die Maximalkapazität (bzw. der maximale freie Speicher) des Containers kleiner als die Kapazität des Images ist. In diesem Fall wird sich der freie Speicher immer am Container orientieren. Das Image wird irgendwann unbrauchbar, weil die Image-Datei immer weiter anwächst und damit der scheinbar freie Speicher im Image immer kleiner wird.

In genau diese Falle tappt Time Machine, wenn man beim freien Speicher auf dem Netzlaufwerk nicht aufpasst. Angenommen im Time-Machine-Image ist weniger Platz verfügbar als Time Machine für das nächste Backup benötigt. Time Machine wird dann automatisch alte Backups löschen, um zusätzlichen Platz zu schaffen. Ist auf dem Netzlaufwerk mehr freier Speicher verfügbar als im Image (d.h. ist der freie Speicher im Image nicht vom Container betroffen), läuft alles problemlos. Durch jedes gelöschte alte Backup wird im Image etwas mehr Speicher frei.

Ist aber der freie Speicher im Image durch den Container begrenzt, wird das Löschen eines Backups keinen zusätzlichen Speicher verfügbar machen. Time Machine wird dann alle Backups bis auf das letzte löschen und anschließend das Backup wegen Speichermangel abbrechen (wie im o. g. Apple-Support-Thread).

Mögliche Lösungen für dieses Problem:

1. Auf der Netzfreigabe sicher stellen, dass von vornherein und dauerhaft genug freier Speicher zur Verfügung steht (also mindestens die Maximalgröße des Images muss verfügbar sein). Die Imagekapazität darf auf keinen Fall größer als der freie Speicher im Container sein.
2. Regelmäßig auf der Netzfreigabe weiteren freien Speicher zur Verfügung stellen, so dass immer genug Speicher für das nächste Backup zur Verfügung steht. Das läuft im Endeffekt auf Punkt 1 hinaus. Benötigt mehr Aufmerksamkeit, solange das Backup-Image aber klein bleibt, kann der freie Speicher noch genutzt werden. Auch hier darf die Imagekapazität auf keinen Fall größer als der maximal freie Speicher im Container sein.
3. Regelmäßig in Time Machine manuell alte Backups löschen und per hdiutil den dadurch im Image formal frei gewordenen Speicher wieder freigeben. Komplizierteste Lösung, dafür aber auch die flexibelste.

Disclaimer: Ich selber habe diese Probleme nie im Zusammenhang mit Time Machine erlebt und kann daher auch nicht garantieren, dass obige Lösungen wirklich funktionieren. Hier ist momentan genug Speicher auf der Netzfreigabe verfügbar, so dass Backups problemlos erstellt werden. Für Praxisberichte und Erfahrungen wäre ich dankbar.

Man sollte sich auch dessen bewusst sein, dass Time Machine Backups auf Netzwerkfreigaben (Time Capsule ausgenommen) nicht von Mac OS X unterstützt werden. Im Zweifel sollte man einer solchen Lösung also nicht vertrauen.

* Es gibt auch die Möglichkeit, per hdiutil den unbelegten Speicher wieder freizugeben. Diese Möglichkeit nutzt Time Machine (um die es hier geht) jedoch nicht von alleine, weswegen ich diese Möglichkeit außen vor lasse.