• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

Ist Time Machine die Lösung oder das Problem?

sortenreyn

Empire
Registriert
09.01.08
Beiträge
84
Hallo,

da fehlt mir doch ein passender Thread hier im Forum!
Habe ich doch neulich bei einem Freund gesehen, dass Time Machine nach guten 20-30 Minuten Werkelns die Meldung bringt, dass nicht genug Speicherplatz vorhanden sei. Da frage ich mich: Warum kann Time Machine das nicht zu Beginn der Operation mitteilen? Dürfte ja schon klar sein. Hinzu kommt, dass ja laut Produktbeschreibung im Falle von Speicherknapptheit Time Machine den Nutzer darauf hinweisen wird, dass es automatisch beginnend bei den ältesten Backups ältere Backups sukzessive zu löschen.
Auf Nachfrage bei AppleCare schlug der Mitarbeiter vor, die Backup Festplatte manuell zu leeren.
Wie macht ihr das denn? Und welche Größe empfehlt ihr für die Backup Platte bei 120 GB interner Platte fürs Leben mit dem Mangel?

Viele Grüße
Sam
 

larkmiller

Saurer Kupferschmied
Registriert
18.11.07
Beiträge
1.702
.....Und welche Größe empfehlt ihr für die Backup Platte bei 120 GB interner Platte fürs Leben mit dem Mangel?

Hi Sam,

Bei einer 120GB HD sollte das Backup-Medium rund 250GB oder groesser sein.
TM speichert naemlich nicht windowstypisch einfach Backup-Daten ab, sondern verwaltet diese anders und stellt sie ziemlich trickreich und fuer Microsoftuser ungewohnt idiotensicher dar.
Das erkennt man zum Beispiel daran, dass es nur diesen einen "grossen" Schalter gibt ;), also nix mit rumfrickeln und 1000-fach einstellen koennen.

Und ich bin mr fast sicher (ist schon wieder etwas her), dass die empfohlene Backup-Groesse von OS X angegeben wird. Wurde wahrscheinlich als unwichtige Bestaetigung weggeklickt.
 

Marcel Bresink

Hadelner Sommerprinz
Registriert
28.05.04
Beiträge
8.560
Warum kann Time Machine das nicht zu Beginn der Operation mitteilen?

Weil das technisch unmöglich ist. Time Machine verwendet eine äußerst raffinierte Datenstruktur, die es möglich macht, dass jede einzelne Datensicherung eine Komplettsicherung ist, wobei aber nur geänderte Daten übertragen werden müssen (Inkrementelle Sicherung). Die benötigte Speichergröße ist im Vorhinein nicht berechenbar.

Zudem wird die Sicherungsplatte nicht gesperrt und ist auch für andere Dinge nutzbar. Während der Sicherung oder Prüfung kann sich also der vorhandene Speicherplatz auf der Sicherungsplatte und auch der belegte Speicherplatz auf den Originalplatten ständig ändern.

Hinzu kommt, dass ja laut Produktbeschreibung im Falle von Speicherknapptheit Time Machine den Nutzer darauf hinweisen wird, dass es automatisch beginnend bei den ältesten Backups ältere Backups sukzessive zu löschen.

Ja, das stimmt auch, es sei denn man hat bei der ersten Benutzung von Time Machine eine Meldung nicht genau gelesen und weggeklickt und dabei unbeabsichtigt die Speicherwarnung eingeschaltet. Man kann die Meldung in "Systemeinstellungen > Time Machine > Optionen > Warnung beim Löschen von alten Backups" abschalten.
 

Scotch

Bittenfelder Apfel
Registriert
02.12.08
Beiträge
8.036
Weil das technisch unmöglich ist. Time Machine verwendet eine äußerst raffinierte Datenstruktur, die es möglich macht, dass jede einzelne Datensicherung eine Komplettsicherung ist, wobei aber nur geänderte Daten übertragen werden müssen (Inkrementelle Sicherung).

TM benutzt sogar eine ausgesprochen primitive Methode zur Sicherung, da es schlicht und einfach alle Dateien, die seit der letzen Änderung geändert wurden (oder genauer: Deren Änderungsdatum sich geändert hat!) kopiert - und zwar auf Dateisystem-Ebene, d.h. ohne tatsächlich zu wissen, ob sich eine Datei überhaupt geändert hat (der Klassiker ist hier Entourage, der seiner DB bei jedem Start einen neuen Datumsstempel gibt, ob sich nun was geändert hat oder nicht...).
Das hat Vorteile, z.B. dass man selbst ohne TM auf TM-Backups zugreifen kann (einfach das sparsebundle mounten), aber auch Nachteile, insb. in Bezug auf die Geschwindigkeit: Da TM nicht komprimiert belegen Backups relativ viel Platz und da TM ebenfalls keine Kataloge anlegt ist die Verwaltung der Daten sehr zeitintensiv. Um festzustellen, welche Datei sich geändert hat, muss TM durch (im Extremfall) alle zurückliegenden Backups - und das ohne DB/Katalogunterstützung. Im schlechtesten Fall muss also TM ein paar tausend Backupsätze lesen um festzustellen, ob eine Datei geändert wurde. Das macht die Backup-Vorbereitung teilweise so langsam (abhängig davon, in welcher Frequenz und wieviele Dateien seit dem letzten Backup geändert wurden). Das eigentliche Backup geht ja i.d.R. sehr schnell. Um das ein wenig abzumildern wird ein Log geführt, wo TM "spicken" kann - wird TM allerdings abgebrochen (Sleep, Abschalten, Neustart usw.), dann ist das Log nicht mehr konsistent und beim nächsten Start muss TM alle (!) Backupsätze neu einlesen, um wieder eine Basis für die Bewertung ob eine Datei geändert wurde oder nicht zu erhalten. Das dauert dann meistens fast so lange wie das initiale Backup, nur dass sehr viel weniger Daten geschrieben werden.

Kurz und gut: TM ist eine sehr bequeme und vollautomatische (und damit relativ zuverlässige ;) ) Sicherungsmethode, aber technisch ganz und gar nichts besonders. Die Funktionalität kann man (und hat man) unter Unix seit Jahren mit Skripten und cron-jobs realisiert - das wirklich "Neue" an TM ist die perfekte Integration in die MacOS Oberfläche.

Gruss,
Dirk
 

gKar

Maunzenapfel
Registriert
25.06.08
Beiträge
5.362
Im Normalfall, den oben genannten Fall des inkonsistenten Logs also mal ausgeklammert, läuft es doch so: Ein Dämon des Betriebssystems überwacht alle Dateisystemzugriffe und loggt Schreibzugriffe auf nicht aus den Backups ausgeschlossene Dateien. Beim nächsten Backup steht also fest, welche Dateien genau zu übertragen sind. Dieses Hintergrund-Loggen des OS ist gerade eine der Stärken von TimeMachine. Als ich unter Tiger meine inkrementellen Backups noch mit rsync machte, musste wirklich vor der Sicherung erst analysiert werden, welche Dateien geändert wurden, was lange dauerte. Aber dazu sind auch nicht alle beliebig alten Backupsätze zu untersuchen, sondern es genügt ja ein Vergleich mit dem letzten Backupsatz (der dank der Hardlinks ja auch alle in früheren Backups gesicherten und danach nicht mehr veränderten Dateien enthält).

Kurz: Eigentlich müssten in eben diesem Normalfall TimeMachine auch sofort und ohne lange Rechenzeit schon vor Beginn des Backups wissen, wieviele Bytes zu übertragen sind — und dementsprechend feststellen können, ob der Platz reicht.

Ich habe die oben beschriebene Fehlermeldung übrigens auch nie erlebt: Bei mir wurde das Backup stets abgeschlossen, danach erschien ggf. eine Meldung, dass aus Platzgründen ein oder mehrere alte Backupsätze gelöscht werden mussten, um Platz für das neue zu schaffen, und dass ich, wenn in Zukunft nicht noch weitere alte Backupsätze verloren gehen sollen, eine neue Platte verwenden sollte.
O.a. Verhalten ist daher m.E. nicht normal. Ich könnte es mir nur so erklären, dass die Platte derart klein ist, dass es selbst durch Löschen aller älteren Backups nicht möglich ist, genug Platz fürs aktuelle zu schaffen (also dass die Platte – bzw. der auf der Platte für TimeMachine zur Verfügung stehende Platz – zu klein für ein einziges Vollbackup ist).