Time-Machine-Backups auf Netzwerkfreigaben 2: Mögliche Probleme

(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.

16 Antworten zu “Time-Machine-Backups auf Netzwerkfreigaben 2: Mögliche Probleme”


  1. 1 svenor

    Wäre es dann nicht besser, keine Sparse-Images zu benutzen, sondern normale? Die verbrauchen von Beginn an ihren vollen Platz, okay, aber man erspart sich die ganzen Probleme.

  2. 2 flokru

    Bei dem Problem vielleicht. Sparse-Images haben dafür aber andere Vorteile. Will man beispielsweise ein 200-GB-Image erstellen, müssen für das Dateisystem erst mindestens 200 GB übers Netz geschoben werden. Da ist ein Sparse-Image mit Anfangsgrößen im MB-Bereich wesentlich praktischer.

    Warum Apple die Sparse-Images gewählt hat, weiß ich nicht. Ich hab auch keine Ahnung, ob Time Machine sich ein normales Image unterschieben lässt.

    Offiziell ist Time Machine ja eh nur für die Time Capsule und Airport Extreme vorgesehen. Wie das Problem da angegangen wird, weiß ich gar nicht.

  3. 3 Tim Berlin

    Hallo, Deine Anleitung hat mir sehr geholfen, ich habe heute endlich Time Machine mit meiem LACIE ETHERNET NAS ans Laufen bekommen. Vielen Dank! Ein Problem stellt sich mir jetzt allerdings: LACIE ETHERNET NAS birgt einen Streamingserver in sich, der das jetzt auf der Platte vorhandene Sparsebundle nicht nach “.MP3″ und “.JPG” durchsuchen kann bzw. je 0 Einträge findet. Ich bin mir sicher, dass eine Lösung für dieses Problem gibt, wer kann mir helfen? Danke, Tim aus Berlin

  4. 4 flokru

    Ich fürchte, das wird nicht so ohne weiteres gehen. Das Gerät müsste dafür ein Funktionen mitbringen, Mac-OS-Disk-Images zu öffnen und damit auch Unterstützung für das Dateisystem HFS+ von Mac OS X bereitstellen. Ich denke nicht, das dein Gerät sowas kann (aber das ist nur meine Vermutung, ich kenn es nicht).

  5. 5 phil

    GENIAL, einfach mal hinterfragt, was TM eigentlich macht und so gelöst. Klasse

  6. 6 off-road-biker

    Partitioniert einfach die Festplatte und nutzt eine Partition ausschließlich für das TM-Backup und schon gibt es keine Probleme mehr. :D *funktioniert jedenfalls an meiner USB-Festplatte*

  7. 7 Dave

    Auf Svenors Frage:
    Ja, die Verwendung von normalen Images (DMG) funktioniert — bei mir ist es die einzige Moeglichkeit die stabil funktioniert, da die Sparebundles nicht nur bei der Imageerstellung, sondern auch beim spaeteren Raufkopieren der Daten Probleme gemacht haben. Diese Probleme traten zwar erst bei relativ großen Datenmengen auf — aber ich hab nunmal viele Daten. Ein paar mehr Infos dazu habe ich als Kommentar zum ersten Teil dieses Artikels hinterlassen.

  8. 8 der Dennis

    Vielen Dank für die ausführliche Erläuterung.

    Es scheint als wäre das Problem mit dem löschen aller Backups ausser einem gelöst.

    Apple hat in dem Time Machine und Airport Update 1.0 der Zeit Maschine die Fähigkeit gegeben die SparseImages mit hdiutil bearbeiten zu können. Dadurch wird Platz frei gegeben und es kommt nicht zu den fatalen Löschaktionen. Logauszüge gibt es bei Adam Cohen-Rose zu lesen…

    Ich werde hier dann noch mal kommentieren wenn ich das in meinem Setup verifizieren kann…

  9. 9 parley

    Dank deiner Anleitung habe ich TimeMachine mt einer NSLU2 zum Laufen bekommen - vielen Dank dafür!

    Nun bin ich auf diesen Artikel gestoßen und das macht mir ein wenig Bauchschmerzen.

    Eine Verständnisfrage:

    Ich habe ein Macbook mit 160gb großer Festplatte.
    Am NSLU2 hängt eine 1TB Platte.

    Das Sparse-Image ist auf umfasst 650gb maximum.

    Um sicher zu gehen das mir obiges nicht passiert;
    Reicht es wenn ich immer darauf achte, dass mindestens 160gb auf der externen Festplatte frei sind?

    Denn das kann ja die maximal größte Backup sein, dass TimeMachine machen kann, oder?

  10. 10 flokru

    @parley: Ja, das sollte reichen. Time Machine sorgt inzwischen aber auch von selber dafür, dass die Sparse-Bundles für die Backups klein gehalten werden.

  11. 11 parley

    Hey, danke für die schnelle Antwort.

    Was meinst du mit “achtet darauf, dass die Sparse-Bundles klein gehalten werden”?
    … er lässt immer etwas frei im Bundle und beschreibt es nie bis zur maximal vorgegebenen Größe?

    p.s.: noch mal vielen Dank für deine Artikel - habe lange im Internet gesucht und viele Stunden damit verbracht eigene Lösungen zu finden bis ich auf deine detaillierte Anleitung gestoßen bin.

  12. 12 flokru

    Nein. Der Artikel oben ist leider inzwischen veraltet. Das beschriebene Problem kommt ja hauptsächlich daher, dass Dateien, die im Image gelöscht werden, nicht dazu führen, dass auch die Image-Datei kleiner wird. Somit bringt das Löschen alter Backups keinen zusätzlichen Speicher und birgt die Gefahr, dass Time Machine aus lauter Verzweiflung alle Backups löscht.

    Mac OS X sieht aber Möglichkeiten vor, diesen Speicher wieder frei zu geben (das kann man im Terminal mit hdiutil compact erreichen). Leider nutzte Time Machine diese Möglichkeit zum Zeitpunkt des Artikels nicht, was das Dilemma verursachte.

    Inzwischen soll Time Machine aber in der Lage sein, dies automatisch zu tun, nachdem alte Backups gelöscht wurden. Ich habe das aber nie getestet und würde mich im Zweifel auch nicht darauf verlassen.

  13. 13 parley

    darüber hinaus kann man in den Systemeinstellungen einstellen, dass Time Machine einen warnt bevor es überhaupt etwas löscht.

    Oder sind diese “Verzweiflungstaten” von TM Ausnahmen davon, und das Programm löscht wahllos ohne mich zu warnen?

  14. 14 flokru

    darüber hinaus kann man in den Systemeinstellungen einstellen, dass Time Machine einen warnt bevor es überhaupt etwas löscht.

    Also bei mir hat diese Einstellung nur bewirkt, dass mich Time Machine nach dem Löschen alter Backups darüber informiert hat.

  1. 1 Time-Machine-Backups auf Netzwerkfreigaben unter Leopard auf flokrus Blog
    Pingback am 15. Mrz 2008 um 19:53
  2. 2 Time Machine backups on network shares 2: possible problems auf flokrus Blog
    Pingback am 28. Mrz 2008 um 1:31

Eine Antwort hinterlassen