Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

macOS Sonoma: Schwächen von Time Machine – und wie man sie überwindet

Time Machine ist seit vielen Jahren ein fester Bestandteil von macOS. Apples Backup-Programm zeichnet sich unter anderem durch eine einfache Bedienung aus, sichert Apps und Dateien automatisch in regelmäßigen Abständen und geht dabei mit dem Platz auf Sicherungs-SSD oder -Festplatte so sparsam wie möglich um. Das Wiederherstellen von Daten lässt sich ebenfalls komfortabel und schnell erledigen. Zudem erleichtern Time-Machine-Backups den Wechsel von einem älteren Mac zu einem neuen erheblich und leisten wertvolle Dienste, wenn man einen Rechner aus Cupertino neu aufsetzen will oder muss. Time Machine ist aber nicht gänzlich frei von Unzulänglichkeiten, das gilt besonders beim Einsatz unter macOS Sonoma und der Verwendung des Apple File System (APFS).


Time Machine hat Probleme mit vielen kleinen Dateien
Howard Oakley hatte bereits vor einigen Wochen auf seinem Blog die Stärken und Schwächen von Time Machine beleuchtet. In seinem jüngsten Beitrag gibt er nun Tipps und nennt Workarounds, mit denen sich einige der weniger positiven Eigenschaften überwinden lassen. Dazu zählt unter anderem der Umgang mit vielen kleinen Dateien, den Apples Backup-App nicht allzu gut beherrscht. Besonders bemerkbar macht sich das beispielsweise im Falle von Xcode und anderen umfangreichen Anwendungen. Diese sollte man daher von Backups ausnehmen. Das gilt vor allem dann, wenn die Sicherungen auf ein Netzlaufwerk erfolgen, da der Protokoll-Overhead von SMB/CIFS den Prozess zusätzlich erheblich verlangsamen kann.

Nur lokal gespeicherte Apps und Daten werden gesichert
Time Machine sichert grundsätzlich nur lokal gespeicherte Dateien. Inhalte, welche sich auf dem iCloud Drive befinden, werden bei Backups nicht berücksichtigt. Besonderer Bedeutung kommt in diesem Zusammenhang der Option „Mac-Speicher optimieren“ in den iCloud-Einstellungen zu. Ist diese aktiviert, lagert macOS bei Bedarf Apps und Dateien in die Cloud aus und löscht die lokalen Kopien. Wer sichergehen will, dass alle gewünschten Daten im Time-Machine-Backup landen, sollte das Feature daher vor der Durchführung einer Sicherung abschalten oder zumindest die Dateien manuell herunterladen. Hat man „Mac-Speicher optimieren“ ausgeschaltet, ist das nicht erforderlich, denn alle in iCloud Drive vorhandenen Files sind auch auf dem Mac vorhanden.


Große temporäre Dateien auf separatem Volume ablegen
Obwohl Time Machine über diverse Techniken verfügt, welche die Sicherungen möglichst klein halten sollen, werden lokale Snapshots und Backups gelegentlich sehr groß. Ursache dafür sind laut Howard Oakley in aller Regel temporäre Dateien wie virtuelle Maschinen oder Downloads. Diese lassen sich zwar von Backups ausschließen, landen aber unter Umständen dennoch in Snapshots und belegen erheblichen Platz auf SSD oder Festplatte. Derart große und nur relativ kurze Zeit benötigte Dateien sollte man daher auf einem separaten Volume speichern, dessen Sicherung man Time Machine verbietet.

Integritäts-Check nur mit zusätzlichen Apps
Vollständigkeit und Integrität von Time-Machine-Backups lassen sich nicht mit Bordmitteln überprüfen. Die von Oakley entwickelten kostenlosen Apps namens Dintch und Fintch ermöglichen einen Vergleich von Hashwerten gesicherter Dateien mit den Originalen. Nachvollziehen kann man die Aktionen von Time Machine im Unified Log von macOS, für dessen Inspektion stellt Oakley das Gratis-Tool Mints zur Verfügung.

Kommentare

marm06.12.23 17:59
MTN
Hat man „Mac-Speicher optimieren“ einausgeschaltet, ist das nicht erforderlich, denn alle in iCloud Drive vorhandenen Files sind auch auf dem Mac vorhanden.
+4
BeeOne06.12.23 18:17
marm

Den Logikfehler im Artikel hatte ich auch gerade gefunden…
0
Alexios12306.12.23 18:21
Kann keinerlei Probleme mit Time Machine unter Sonoma feststellen. Was soll es denn für Probleme geben? Darüber schweigt sich der Artikel leider aus.
+5
DanAm
DanAm06.12.23 18:40
Mail geht immer noch nicht wieder mit TimeMachine, oder? Warum eigentlich nicht mehr?
+1
Dupondt06.12.23 18:45
marm:

Danke für den Hinweis, ist korrigiert.
+3
Dunkelbier06.12.23 19:26
DanAm
Mail geht immer noch nicht wieder mit TimeMachine, oder? Warum eigentlich nicht mehr?
Was meinst Du denn damit? Die Mails liegen doch sowieso auf dem Mailserver.
+2
Nebula
Nebula06.12.23 19:42
Time Machine machte bei mir auch keine Probleme, wohl aber iCloud Drive auf allen Macs. Dauerte Wochen, bis sich alles eingeruckelt hat. Teilweise wurde alles neu synchronisiert.
»Wir werden alle sterben« – Albert Einstein
+1
Cariño130206.12.23 20:27
DanAm

Die native Mail-App funktioniert einwandfrei unter Sonoma 14.2, davor auch bei der beta 4.
Lösch die E-Mail-Konten und füge sie neu hinzu - vielleicht läuft es dann besser. LG
+3
Cariño130206.12.23 20:28
Alexios123

Dito. Eben via ext. USB 3.0 - Festplatte Backup erfolgreich implementiert, keinerlei Aussetzer.
LG
+1
gorgont
gorgont06.12.23 20:32
Hab seit Sonoma wirklich Probleme mit TimeMachine auf eine Synology übers Netzwerk. Werde dazu nochmal nen separaten Post abgegeben. Ich komme einfach nicht weiter…
touch eyeballs to screen for cheap laser surgery
+3
Marcel Bresink06.12.23 20:46
Diesmal schreibt Oakley einigen Unsinn.

Objekte aus der Datensicherung auszuschließen, weil sie groß sind oder intern aus kleinen Dateien bestehen, ist völlig kontraproduktiv. Wozu soll das gut sein? Damit man im Notfall extra viel Daten verliert?

Dateien auf andere Volumes zu verlagern, ist praxisfern. Wenn es sich um Dateien handelt, die von sandboxgeschützten Apps abgelegt wurden, können die Programme in bestimmten Fällen den Zugriff auf diese Daten verlieren.

Dass Vollständigkeit und Integrität der Sicherungen nicht mit Bordmitteln geprüft werden können, stimmt auch nicht. macOS bietet zu diesem Zweck eingebaute Funktionen über den Befehl "tmutil" an.
+4
marm06.12.23 20:55
Marcel Bresink
Objekte aus der Datensicherung auszuschließen, weil sie groß sind oder intern aus kleinen Dateien bestehen, ist völlig kontraproduktiv. Wozu soll das gut sein? Damit man im Notfall extra viel Daten verliert?
Nehmen wir an, ich mache einen großen Download von 4 GB, gehe Kaffee trinken (der Mac nutzt Pausen für Time Machine) und ich möchte die Datei anschließend auf das NAS verschieben. Wenn nun nach dem Download ein Snapshot erstellt wird, weil der Mac gerade Lust dazu hat, dann ist das Snapshot mehr als 4 GB groß und wird in Time Machine gesichert. Unnötig, wie ich finde.
Sichere ich direkt auf ein externes Laufwerk passiert das nicht.
+3
DanAm
DanAm06.12.23 20:59
Dunkelbier
DanAm
Mail geht immer noch nicht wieder mit TimeMachine, oder? Warum eigentlich nicht mehr?
Was meinst Du denn damit? Die Mails liegen doch sowieso auf dem Mailserver.


Ich meine damit: Früher konnte man gelöscht E-Mails mit TimeMachine wiederherstellen. Seit einigen Jahren geht das nicht mehr.
+1
Loisl06.12.23 21:23
DanAm
Ich meine damit: Früher konnte man gelöscht E-Mails mit TimeMachine wiederherstellen. Seit einigen Jahren geht das nicht mehr.
Das ist mir auch schon unangenehm aufgefallen.
Schlimm ist auch, dass man Dateien nicht mehr aus dem BackUp löschen kann. „Alle Vorkommen von … löschen“ war sehr praktisch. Da konnte man einerseits schlagartig viel Platz freigeben. Andererseits konnte man Dateien loswerden, die man garantiert nicht mehr braucht: Ich arbeite gerne mit „Projektordnern“, in denen alle Dateien eines Projekts liegen. Sobald das Projekt abgeschlossen ist, brauche ich nur nich das Endprodukt und keinen der Zwischenschritte, letztere vergeuden aber Platz auf meinen TimeMachine-Volumes.
+1
TheRocka06.12.23 22:22
gorgont
Hab seit Sonoma wirklich Probleme mit TimeMachine auf eine Synology übers Netzwerk. Werde dazu nochmal nen separaten Post abgegeben. Ich komme einfach nicht weiter…
Dito. Das Ausrufezeichen und „Backup verzögert“ sind meine täglichen Begleiter
+1
feel_x06.12.23 22:39
marm
Nehmen wir an, ich mache einen großen Download von 4 GB, gehe Kaffee trinken (der Mac nutzt Pausen für Time Machine) und ich möchte die Datei anschließend auf das NAS verschieben. Wenn nun nach dem Download ein Snapshot erstellt wird, weil der Mac gerade Lust dazu hat, dann ist das Snapshot mehr als 4 GB groß und wird in Time Machine gesichert. Unnötig, wie ich finde.
Sichere ich direkt auf ein externes Laufwerk passiert das nicht.

..deswegen hab ich das Verzeichnis „Downloads“ von der Time Machine-Sicherung (und meinen Arq-Sicherungen) ausgenommen.
+2
Nebula
Nebula06.12.23 22:48
Marcel Bresink
Diesmal schreibt Oakley einigen Unsinn.

Objekte aus der Datensicherung auszuschließen, weil sie groß sind oder intern aus kleinen Dateien bestehen, ist völlig kontraproduktiv. Wozu soll das gut sein? Damit man im Notfall extra viel Daten verliert?

Dateien auf andere Volumes zu verlagern, ist praxisfern. Wenn es sich um Dateien handelt, die von sandboxgeschützten Apps abgelegt wurden, können die Programme in bestimmten Fällen den Zugriff auf diese Daten verlieren.

Dass Vollständigkeit und Integrität der Sicherungen nicht mit Bordmitteln geprüft werden können, stimmt auch nicht. macOS bietet zu diesem Zweck eingebaute Funktionen über den Befehl "tmutil" an.

Es geht hier ja wohl eher um besonders große Dateien wie virtuelle Maschinen. Die verstopfen unnötig die Snapshots, obwohl man sie vom Backup ausgeschlossen hat. Meine Windows-VM ist 50 GB groß.
»Wir werden alle sterben« – Albert Einstein
+2
Cariño130206.12.23 23:00
Nebula

…und sie wächst und wächst… 😒
0
RichMcTcNs06.12.23 23:28
@loisl
Ich meine mich zu erinnern, dass Dateien des TM-Backups gelöscht werden können, wenn das Backup-Volume HFS-formatiert ist.
+1
strateg
strateg07.12.23 00:27
deshalb nutze ich parallel zu time machine seit über 2 jahrzenten crashplan vom code42 — ist günstig, schnell, zuverlässig & hat mir schon einige mal den a… gerettet 😊
cuntentientscha, attentivitad, curaschi —
-3
DonBiela07.12.23 01:19
Ich warte auf eure dislikes
3 Chinesen mit dem Kontrabass
-2
Loisl07.12.23 02:33
RichMcTcNs
@loisl
Ich meine mich zu erinnern, dass Dateien des TM-Backups gelöscht werden können, wenn das Backup-Volume HFS-formatiert ist.

Ja, aber wenn Du die Sicherung in Monterey (oder neuer) beginnst, wird die leere Platte automatisch in APFS formatiert.

Das ist ja genau das Thema, dass etwas, das zuverlässig und gut funktioniert hat, „verschlimmbessert“ worden ist.

Man kann auch nicht erwarten, dass Anwender das 1. wissen und 2. einen alten Mac auf Lager haben, um damit ein HDD-Volume vorzubereiten.

Ich meine mich zu erinnern, dass ich damals alle Platten bewusst in HFS+ formatiert habe und irgendwann ziemlich blöd geschaut habe.

Mir fällt auch auf, dass nicht immer alle Vorversionen gefunden werden: Ich habe mehrmals hintereunander nach demselben Dateinamen gesucht. Mal war die letzte Version aus Oktober, mal aus dem August.

„It just works“ war einmal.
Man wiegt sich in falscher Sicherheit!

Meine neue BU-Strategie ist: Für kurzfristige BUs nehm ich SSDs. Zur Archivierung von Clones/Snapshots die alten TimeMachine HDs.
+3
strateg
strateg07.12.23 05:29
Loisl
RichMcTcNs
@loisl
Ich meine mich zu erinnern, dass Dateien des TM-Backups gelöscht werden können, wenn das Backup-Volume HFS-formatiert ist.

„It just works“ war einmal. :'(
Man wiegt sich in falscher Sicherheit!

Meine neue BU-Strategie ist: Für kurzfristige BUs nehm ich SSDs. Zur Archivierung von Clones/Snapshots die alten TimeMachine HDs.

ein backup ist kein backup sage ich noch heute als alter sicherheitsfanatiker.

ein gutes backup besteht immer aus einer tochter, mutter & grossmutter — lokal mit time machine jede stunde, in die cloud mit crashplan alle 15 minuten & je nach job mindestens alle 2 wochen regelmässig einen klon auf eine externe ssd.

so hat man einen kompletten datenbestand auf dem mac (5 bis 6 tb) mit versionen & 3 backups auf unterschiedlichen medien & an diversen orten

alle archivdaten (11 tb) habe ich lokal sowie im bankschliessfach auf ssds & in der cloud.

selbstverständlich sind alle archive & backups hoch verschlüsselt, ob lokal oder bevor sie in die cloud geladen werden. die zugangsdaten kenne nur ich & mein testament
cuntentientscha, attentivitad, curaschi —
0
Marcel Bresink07.12.23 09:18
Nebula
Es geht hier ja wohl eher um besonders große Dateien wie virtuelle Maschinen. Die verstopfen unnötig die Snapshots

Ja natürlich geht es darum. Der Sinn einer Datensicherung ist aber doch, Daten zu sichern. Und jetzt will man genau das verhindern, weil das Platz benötigt, der gerade sowieso nicht gebraucht wird?
0
Nebula
Nebula07.12.23 10:57
Da ich genau so vorgehe, wie Oakley empfiehlt, spreche ich mal von mir:

Ich möchte nicht, dass mein Time Machine Backup so große Snapshots erzeugt, weil ich jetzt schon kaum noch Platz habe (trotz 2 TB). macOS bestraft einen ja regelrecht, wenn der Speicher knapp wird. Auch möchte ich nicht, dass in meinen Backups so schnell alte Daten verworfen werden. Ich weiß, das ersetzt kein Archiv, aber es ist schon mal praktisch, einen Monat in die Vergangenheit reisen zu können. Nicht jede App unterstützt Versions. Wären meine VMs Bestandteil von Time Machine, käme ich mittlerweile keinen Monat zurück. Meine VMs sichere ich seltener und separat. Das gilt auch für meine Sammlung mit macOS-Installern. Die müsste ich eigentlich gar nicht sichern, denn die gibt's auch Online. Meine ganzen Downloads aus den ÖRR-Mediatheken muss/will ich gar nicht sichern, weshalb sie auf einem anderen Volume liegen. Deren Verlust täte mir nicht weh.
»Wir werden alle sterben« – Albert Einstein
+1
marm07.12.23 11:18
Marcel Bresink
Diesmal schreibt ... einigen Unsinn.
Deine Standardeinleitung
Objekte aus der Datensicherung auszuschließen, weil sie groß sind oder intern aus kleinen Dateien bestehen, ist völlig kontraproduktiv. Wozu soll das gut sein? Damit man im Notfall extra viel Daten verliert?
Dahinter kann auch die Entscheidung stehen, bestimmte Daten mit einem anderen Backup-Programm zu sichern. Time Machine hat seine Stärken, wenn es um die Sicherung von Versionsständen geht oder wenn die Konfiguration gesichert wird. Aber die Sicherung von Xcode gehört zum Beispiel gemäß Oakley nicht dazu. Meinen Devonthink-Ordner sichere ich auch mit anderen Mitteln.
Dateien auf andere Volumes zu verlagern, ist praxisfern. Wenn es sich um Dateien handelt, die von sandboxgeschützten Apps abgelegt wurden, können die Programme in bestimmten Fällen den Zugriff auf diese Daten verlieren.
Was ist daran praxisfern eine externe SSD anzuschließen? Und vom Ausschließen von explizit sandboxgeschützten Apps sprach niemand.
Dass Vollständigkeit und Integrität der Sicherungen nicht mit Bordmitteln geprüft werden können, stimmt auch nicht. macOS bietet zu diesem Zweck eingebaute Funktionen über den Befehl "tmutil" an.
Oakley möchte dafür ein GUI haben und sieht tmutil nicht als Tool für Jedermann.
+1
mschue
mschue07.12.23 13:47
Marcel Bresink
Dateien auf andere Volumes zu verlagern, ist praxisfern. Wenn es sich um Dateien handelt, die von sandboxgeschützten Apps abgelegt wurden, können die Programme in bestimmten Fällen den Zugriff auf diese Daten verlieren.

Also in Anbetracht der (zumindest für Privatleute) prohibitiven Preise für Plattenplatz von Apple finde ich das alles andere als "praxisfern".

Ich z.B. habe gleich zwei externe USB-Platten: eine TM-Platte und eine "Medienplatte", auf der Bilder, Musik, Filme, etc. liegen. Also voluminöse Daten mit geringer Änderungshäufigkeit.

Die Systemplatte wird vollständig jede Stunde gesichert, die "Medienplatte" zusammen mit der Systemplatte nur ca. alle 4 Wochen auf eine (im Grunde genommen) dritte USB-Platte, die aber nur zu eben dieser monatlichen Sicherung angeschlossen wird um dann wieder im Schreibtisch zu verschwinden - das hält den möglichen Verlust durch Ransomware (für mich) in Grenzen.

Bei anderen Änderungshäufigkeiten müsste diese "OffLine-Sicherung" natürlich angepasst werden.
+2
Marcel Bresink07.12.23 17:35
marm
Was ist daran praxisfern eine externe SSD anzuschließen?

Überhaupt nichts. Praxisfern ist, zu behaupten, eine Auslagerung auf ein sekundäres Volume wäre mit jeder großen Datei ohne Probleme möglich. Es hängt vom Programm ab, das diese Datei nutzt, ob das Programm nach der Auslagerung der Datei noch in der Lage ist, auf diese Datei zuzugreifen.
marm
Und vom Ausschließen von explizit sandboxgeschützten Apps sprach niemand.

Richtig, ich auch nicht.
mschue
Also in Anbetracht der (zumindest für Privatleute) prohibitiven Preise für Plattenplatz von Apple finde ich das alles andere als "praxisfern".

Was ich gesagt habe, war, dass Apple noch viel "prohibitiver" ist, weil macOS bestimmte Systemfunktionen und Funktionen in Drittanbieterprogrammen sperrt, wenn benötigte Dateien nicht innerhalb der Systemvolumegruppe liegen.
+2
Nebula
Nebula07.12.23 19:36
Kannst du eine Anwendung nennen, bei der man Dokumentdateien nicht an beliebiger Stellen speichern kann? Also vor allem eine Anwendung, die wirklich große Dokumente erzeugt? Und selbst bei Library-basierte Sachen wie Fotos oder Musik kommen mit einem separaten Volume zurecht (sofern es direkt beim Start verfügbar ist).
»Wir werden alle sterben« – Albert Einstein
+2
marm07.12.23 20:56
Marcel Bresink
Praxisfern ist, zu behaupten, eine Auslagerung auf ein sekundäres Volume wäre mit jeder großen Datei ohne Probleme möglich. Es hängt vom Programm ab, das diese Datei nutzt, ob das Programm nach der Auslagerung der Datei noch in der Lage ist, auf diese Datei zuzugreifen.
Und Du meinst, dass dies Oakley (oder seinen Lesern) nicht klar ist und er daher diesmal Unsinn schreibt?
0
Weitere News-Kommentare anzeigen

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.