Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Warum weigert sich Time Machine, einen bestimmten Ordner beim Backup zu berücksichtigen?

Warum weigert sich Time Machine, einen bestimmten Ordner beim Backup zu berücksichtigen?

Weia
Weia24.04.2022:20
Hallo allerseits,

ich kämpfe gerade damit, dass Time Machine sich (jedenfalls in Mojave) weigert, Backups von ~/Library/Saved Application State/ zu machen.

Hintergrund ist, dass ich die offenen Fenster in von mir verwendeten Programme oftmals als „To-Do-Liste“ benutze oder aber als Zwischenprotokoll eines Arbeitsprozesses, also jedenfalls darauf angewiesen bin, dass sie auch bei Crashs oder Neustarts sicher erhalten bleiben.

Das klappt in macOS auch meistens recht gut, aber manchmal „vergisst” doch das eine oder andere Programm seine offenen Fenster.

Läuft dieses Programm in einer Sandbox, ist das kein Problem, denn Time Machine macht ein Backup der entsprechenden Statusdateien (bei TextEdit z.B. wären das die Dateien in ~/Library/Containers/com.apple.TextEdit/Data/Library/Saved Application State/), und so lassen sich die „vergessenen“ offenen Fenster wieder herstellen.

Programme aber, die nicht in einer Sandbox laufen, speichern die Statusdateien direkt in ~/Library/Saved Application State/; dazu gehört auch das für mich äußerst wichtige Terminal (Statusdateien in ~/Library/Saved Application State/com.apple.Terminal.savedState/).

Aus irgendeinem Grund, den man nur in Cupertino kennt (und vielleicht nicht mal dort), schließt macOS aber ausgerechnet den gesamten Ordner ~/Library/Saved Application State/ vom Backup aus (wie gesagt, in krassem Gegensatz zu den Pendants innerhalb von ~/Library/Containers/):
root# tmutil isexcluded /Users/Weia/Library/Saved\ Application\ State/
[Excluded]    /Users/Weia/Library/Saved Application State

Kein Problem, sollte man meinen, dann nimmt man die Exklusion halt zurück:
root# tmutil removeexclusion /Users/Weia/Library/Saved\ Application\ State
Dieser Befehl wird anstandslos und ohne Fehlermeldung ausgeführt, nur ist danach die Exklusion unverändert da:
root# tmutil isexcluded /Users/Weia/Library/Saved\ Application\ State/
[Excluded]    /Users/Weia/Library/Saved Application State

WTF?

Ist das mal wieder einer der ungezählten macOS-Bugs oder muss man noch irgendwas machen, was ich übersehen habe? Weiß da jemand etwas?

Vielen Dank im Voraus für jede eventuelle Info!
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
+2

Kommentare

Weia
Weia26.04.2003:26
KeinereineIdee?
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
0
Noname081526.04.2007:07
Schon mal was von Leerzeichen zwischen den Worten gehört?
-2
Weia
Weia26.04.2009:38
Noname0815
Schon mal was von Leerzeichen zwischen den Worten gehört?
Selbstverständlich. KeinereineIdee? ist aber ein Wort.

(Schon mal was von Binnenmajuskeln und kreativem Umgang mit Sprache gehört?)
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
+1
macfori26.04.2009:38
Eventuell funktioniert die Maskierung nicht richtig.
Du könntest die Pfade, die Leerzeichen enthalten mal mit "" einrahmen.
0
Weia
Weia26.04.2010:21
macfori
Eventuell funktioniert die Maskierung nicht richtig.
Du könntest die Pfade, die Leerzeichen enthalten mal mit "" einrahmen.
Hmmmm – angestoßen durch Deinen Tipp scheint sich das Problem tatsächlich gelöst zu haben, allerdings ist nicht ganz klar, wodurch genau.

Für die Statusabfrage tmutil isexcluded sind die Anführungszeichen (statt \ vor Leerzeichen) egal bzw. führen zu keiner Änderung der Ausgabe.

Beim Setzen der Einstellung mit tmutil removeexclusion habe ich zunächst außer den Anführungszeichen aus Versehen auch noch die Option -p (fester Pfadname, kein Folgen des Objekts, wenn dieses bewegt wird) benutzt und das brachte ebenfalls keinen Erfolg. Daraufhin habe ich das aber gleich nochmal ohne die Option (aber wieder mit Anführungszeichen) gemacht, und dann ging es plötzlich.

Ich hatte das mit und ohne diese Option aber auch schon früher probiert und da ohne Erfolg, aber vielleicht nicht direkt hintereinander. Ob der jetzige Erfolg also an den Anführungszeichen lag oder Option -p und gleich danach nochmal ohne Option -p oder beides kombiniert, weiß ich also leider nicht; ich lasse das Ergebnis jetzt aber erstmal und warte ab, ob es einen Neustart überlebt und auch tatsächlich eine Veränderung des Verhaltens von Time Machine auslöst.

Seltsam ist das in jedem Fall. Nachdem ich den Saved Application State-Ordner ja nicht bewegt habe, dürfte die Option gar keine Rolle spielen. Und das Ausmaskieren von Leerzeichen nimmt die Shell vor, bevor sie den Pfad and das Unix-Programm übergibt; da kann es eigentlich auch nicht sein, dass das sonst immer funktioniert, aber einmal nicht.

Wie auch immer, jetzt geht es erstmal , und ich warte ab, wie lange.

Danke!
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
+2
Weia
Weia29.04.2002:00
Weia
Wie auch immer, jetzt geht es erstmal , und ich warte ab, wie lange.
Die Antwort scheint zu lauten: Bis zum nächsten Neustart.

Den habe ich gerade gemacht, und seitdem ist ~/Library/Saved Application State wieder Excluded.

Bis dahin allerdings hat Time Machine getreulich Backups dieses Ordners erstellt. removeexclusion funktioniert also prinzipiell, wird aber aus mir völlig unerfindlichen Gründen von macOS bei mutmaßlich jedem Neustart wieder auf Excluded zurückgesetzt und das, wenn ich meinem Time-Machine-Backup vertrauen kann, seit Mavericks (unter Mountain Lion ging es noch).

Da hilft wohl nur ein launch-daemon-Skript, das den Ordner nach jedem Neustart wieder zu Time Machine hinzufügt.

Oh, Apple!
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
+1
macfori29.04.2008:07
Eventuell. brauchts noch die Optionen -pv (bitte erst nachlesen - ich übernehme keine Verantwortung für Folgeschäden.


man tmutil

addexclusion [-pv] item ...
             Configure an exclusion that tells Time Machine not to back up a file, directory, or volume during future backups.

             There are three kinds of user-configurable exclusions in Time Machine:

             The first kind of exclusion, which is the default behavior for the addexclusion verb, is a location-independent
             ("sticky") exclusion that follows a file or directory. When the file or directory is moved, the exclusion goes
             with the item to the new location. Additionally, when the item is copied, the copy retains the exclusion.

             The second kind of exclusion is a fixed-path exclusion. With this, you tell Time Machine that you want a specific
             path to be excluded, agnostic of the item at that path. If there is no file or directory at the specified path,
             the exclusion has no effect; if the item previously at the path has been moved or renamed, the item is not
             excluded, because it does not currently reside at the excluded path. As a consequence of these semantics, moving
             a file or directory to the path will cause the item to be excluded--fixed-path exclusions are not automatically
             cleaned up when items are moved or deleted and will take effect again once an item exists at an excluded path.

             The third kind of exclusion is a volume exclusion. These track volumes based on file system UUID, which is per-
             sistent across volume name and mount path changes. Erasing the volume will cause Time Machine to apply default
             behavior for the newly erased volume.

             The -p option configures fixed-path exclusions. The -v option configures volume exclusions. Both require root
             privileges. The -v option is the only supported way to exclude or unexclude a volume; behavior is undefined if a
             sticky or fixed-path exclusion is specified.

     removeexclusion [-pv] item ...
             Configure Time Machine to back up a file, directory, or volume during future backups. This verb follows the same
             usage, exclusion style, and privilege semantics as addexclusion.
0
Weia
Weia29.04.2011:53
macfori
Eventuell. brauchts noch die Optionen -pv (bitte erst nachlesen - ich übernehme keine Verantwortung für Folgeschäden.
Nö, -v ist nur für ganze Volumes statt einzelner Ordner und -p hatte ich ja probiert.

Naja, wenn ich Zeit habe, mache ich noch ein paar Tests mit Neustarts.
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
0
Wiesi
Wiesi29.04.2012:27
Weia
Folgendes kannst Du noch überprüfen:

Im Backup.log des allerersten Bkp auf dem Volume steht die ellenlange Liste der Exclusions.

Im folgenden Falle geht die (letzte) Änderung einer Datei verloren:

Da TM nur das letzte Bkp des vergangenen Tages aufbewahrt, geht der Bkp einer Datei, die am frühen Morgen geändert wurde, dann aber noch vor dem Abend gelöscht wurde, verloren. Ob, "gelöscht" und "excluded" gleich behandelt werden (was natürlich eine Wanze wäre), weis ich nicht.

Auf jeden Fall, währe es interessant heraus zu finden, wo die plist mit den exclusions abgelegt wird, und ob diese selbst vom Bkp ausgeschlossen wird, oder gar beim Neustart aus dem Bkp restauriert wird. Aus dem o.g. Bkp.log sollte sich eine geeignete Signatur für ein Suchen nach der plist finden lassen.
„Everything should be as simple as possible, but not simpler“
0
Weia
Weia04.05.2002:04
Wiesi
Im Backup.log des allerersten Bkp auf dem Volume steht die ellenlange Liste der Exclusions.
Welche macOS-Version liegt dieser Aussage zugrunde?

Bei mir (Mojave) gibt es in jedem Backup-Zeitpunkt-Ordner eine Datei .Backup.log, in der aber nie die Exlusions stehen. Die stehen bei mir (ebenfalls in jedem Ordner) jeweils in der Datei .exclusions.plist.

Nur dokumentieren diese Dateien ja immer nur die Parameter für das damalige Backup, aber nicht die jetzigen Einstellungen für zukünftige Backups.
Im folgenden Falle geht die (letzte) Änderung einer Datei verloren:

Da TM nur das letzte Bkp des vergangenen Tages aufbewahrt, geht der Bkp einer Datei, die am frühen Morgen geändert wurde, dann aber noch vor dem Abend gelöscht wurde, verloren. Ob, "gelöscht" und "excluded" gleich behandelt werden (was natürlich eine Wanze wäre), weis ich nicht.
Schon klar, aber das ist hier nicht relevant. Der Ordner ~/Library/Saved Application State enthält immer bestimmte Dateien, wird aber nie gesichert. Und das ist ja auch konsistent – tmutil berichtet ja nach jedem Neustart erneut, dass ~/Library/Saved Application State excluded ist.
Auf jeden Fall, währe es interessant heraus zu finden, wo die plist mit den exclusions abgelegt wird,
In der Tat (ob plist oder nicht).
Aus dem o.g. Bkp.log sollte sich eine geeignete Signatur für ein Suchen nach der plist finden lassen.
Leider nicht.
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
0
Wiesi
Wiesi04.05.2009:40
Weia
Wiesi
Im Backup.log des allerersten Bkp auf dem Volume steht die ellenlange Liste der Exclusions.
Welche macOS-Version liegt dieser Aussage zugrunde?

Ich habe seit drei Wochen Catalina installiert, habe aber auch die Bkp vom letzten Mojave verfügbar. Auch ein Klon von Mojave ist vorhanden. (Ich bewahre das alte Betriebssystem immer komplett auf.) Ich kann und werde bei mir mal alles überprüfen. In der nächsten Nacht, dürfte das Ergebnis vorliegen.
„Everything should be as simple as possible, but not simpler“
0
Wiesi
Wiesi04.05.2023:10
Weia

Ich habe den ersten Bkp vom meinem Mojave angesehen, darin ist als versteckte Datei .Backup.log die Logdatei mit allen exclusions enthalten.

Wie Du siehst, hast Du daran keine Rechte und je nachdem wie Du an die Datei ran gehst, bekommst Du einfach nichts, auch keine Fehlermeldung. Da Du aber ein Leserecht für das übergeordnete Verzeichnis hast, kannst Du die Datei kopieren und Dir dann die nötigen Rechte zuweisen. Das habe ich gemacht. Wenn mein Texteditor richtig gezählt hat, sind es bei mir 183 exclusions, die alle alle mit
Excluding '/Volumes/com.apple.TimeMachine.localsnapshots/Backups.backu pdb/Wiesis iMac/2019-03-16-111033/ Macintosh HD/

beginnen. Die nächsten beiden Bilder zeigen Anfang und Ende der Logdatei als Ausschnitt.



„Everything should be as simple as possible, but not simpler“
+1
Weia
Weia04.05.2023:51
Wiesi
Ich habe den ersten Bkp vom meinem Mojave angesehen, darin ist als versteckte Datei .Backup.log die Logdatei mit allen exclusions enthalten.
Ah – der Unterschied ist, dass ich diese erste Logdatei gar nicht mehr habe, weil irgendwann meine Backupplatte voll war und Time Machine dann ordnungsgemäß die frühesten Backups gelöscht hat.

Bei mir fangen die Daten daher erst nach ca. 1 Jahr nach dem ersten Backup an, und da finde ich dann keine entsprechenden Einträge in den Logdateien.

Ich würde diese Einträge aber ohnehin einfach so interpretieren, dass darin aufgelistet wird, was bei dem Backup tatsächlich ausgelassen wurde – das ist ja der Sinn einer Logdatei, dass sie Geschehenes protokolliert.

Gleichzeitig gibt es ja aber auch noch – auch bei Dir auf dem Finder-Screenshot – die Datei .exclusions.plist, und in der stehen die eingestellten Vorgaben für die Exclusions – aber natürlich eben auch nur für das jeweilige damalige Backup.

Die Vorgaben dafür, was beim nächsten, noch in der Zukunft liegenden Backup ausgeschlossen werden sollte, muss an anderer Stelle stehen, und das konnte ich nirgendwo finden. Es scheint jedenfalls keine Datei namens .exclusions.plist außerhalb der schon bestehenden Backups zu geben.

Aber ich denke, letztlich ist das auch egal, wo tmutil die Einstellungen speichert. Sie sind ja konsistent und Time Machine gehorcht ihnen.

Das Rätsel ist, warum macOS bei jedem Neustart meine mit tmutil gemachte Einstellung wieder zurücksetzt. Entweder das oder die Einstellung wird aus irgendeinem Grund in überhaupt keiner Datei gespeichert und befindet sich nur im Arbeitsspeicher. Dann wäre klar, warum sie nach einem Neustart verschwunden ist. Ich kann nicht so häufig neu starten, aber ich werde demnächst mal ausprobieren, ob ich eine exclusions-Einstellung für einen x-beliebigen anderen Ordner so abspeichern kann, dass sie einen Neustart übersteht.
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
+1
Wiesi
Wiesi06.05.2009:06
Hallo Nachtarbeiter,
habe heute morgen nach dem Neustart des nachts abgeschalteten iMacs die Inclusion geprüft:


Mein System ist das neuste Catalina, die Inclusion habe ich gestern eingerichtet; war bis dahin excludet.
„Everything should be as simple as possible, but not simpler“
+1
Weia
Weia06.05.2013:34
Wiesi
Mein System ist das neuste Catalina, die Inclusion habe ich gestern eingerichtet; war bis dahin excludet.
Hmpf, das wäre natürlich typisch, wenn dieser Bug in genau der ersten macOS-Version gefixt ist, die auf meinem Mac Pro nicht mehr läuft. Aber grundsätzlich natürlich höchst erfreulich. Danke für die Info!
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
0
Weia
Weia08.05.2003:52
So, ich bin jetzt hoffentlich entscheidende Schritte weitergekommen.

Im wesentlichen gibt es 2 Punkte: Verschiedene Arten von Exclusionen und Persistenz über einen Neustart hinaus.

Verschiedene Arten von Exklusionen

tmutil addexclusion und tmutil removeexclusion können beide mit oder ohne die Option -p benutzt werden.

Mit -p bedeutet, dass die Exklusion für einen Pfad gespeichert wird, so wie ein Unix-Softlink. Lösche ich also einen exkludierten Ordner und lege den unter demselben Namen an derselben Stelle wieder neu an, so ist auch der neue Ordner exkludiert. Verschiebe ich den Ordner, ist er nicht mehr exkludiert.

Ohne -p bedeutet, dass die Exklusion für ein Objekt im Verzeichnisbaum des Dateisystems gespeichert wird, so wie ein macOS-Alias. Lösche ich also einen exkludierten Ordner und lege den unter demselben Namen an derselben Stelle wieder neu an, so ist der neue Ordner nicht exkludiert. Verschiebe ich den Ordner, ist er weiterhin exkludiert.

Das Problem ist nun, dass diese beiden Exklusionsvarianten völlig unabhängig voneinander sind.

Sprich, wurde eine Exklusion mit tmutil addexclusion -p eingerichtet, kann ich sie auch nur mit tmutil removeexclusion -p wieder entfernen, und entsprechend bei Verwendung ohne -p. Man kann auch beide Varianten gleichzeitig einrichten, dann muss man ggf. natürlich auch beide wieder entfernen.

Das allein wäre ja vielleicht noch kein großes Ding; das Problem ist aber, dass tmutil isexcluded diese Option ignoriert und den Status Excluded anzeigt, wenn auch nur eine der beiden Exklusionen vorgenommen wurde, ohne aber zu sagen welche.

Hat man die Exklusion also nicht selbst vorgenommen (was bei mir mit Saved Application State ja der Fall war) oder kann man sich nicht mehr erinnern, ob man -p benutzt hat oder nicht, so muss man sicherheitshalber immer beide Varianten mit tmutil removeexclusion mit und ohne -p entfernen oder jedenfalls mit tmutil isexcluded überprüfen, ob die Exklusion entfernt wurde.


Persistenz über einen Neustart hinaus

Ich habe jetzt zum Test explizit einen Neustart veranlasst, nachdem ich zuvor die Exklusion für Saved Application State ohne -p entfernt hatte (was zu reichen schien). Und siehe da, die Einstellung war auch nach dem Neustart noch da, genau wie bei Wiesi.

Alle Neustarts zuvor waren de facto durch Crashs verursacht. Das passiert mir mit Mojave zur Zeit ja leider so häufig, dass ich diese Crashs zum Testen der Persistenz verwendet hatte, statt noch einen weiteren Neustart „ohne Not“ selbst zu veranlassen. Und dann scheint die Persistenz nicht gegeben.

Das kann nun theoretisch zweierlei bedeuten:
  • Ein Crash zerstört die Einstellung, wie es ja z.B. bisweilen auch mit dem Spotlight-Index passiert, der nach einem Crash nichts mehr findet, bis er wieder neu aufgebaut wird. – Wenn das so ist, dann ist meine Exklusion mit dem nächsten Crash wieder futsch und ich muss letztlich permanent ein Auge darauf haben.
  • macOS hält die Einstellung zunächst nur im Arbeitsspeicher und speichert sie erst bei (regulärer) Beendigung von macOS dauerhaft ab, wie es z.B. auch mit einigen Einstellungen für das nichtflüchtige NVRAM geschieht. In diesem Fall wird bei einem irregulären Neustart aufgrund eines Crashs natürlich gar nichts abgespeichert und deshalb ist die Einstellung danach wieder futsch. – Wenn das so ist, dann müsste meine Exklusion, nachdem sie jetzt einmal einen Neustart erfolgreich überstanden hat, also offenkundig persistent abgespeichert wurde, in Zukunft auch bei Crashs erhalten bleiben.

Ich werde das jetzt eine zeitlang beobachten und dann berichten, welche der beiden Varianten bei mir zutraf.
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
+1
Weia
Weia10.05.2015:08
Weia
Ich werde das jetzt eine zeitlang beobachten und dann berichten, welche der beiden Varianten bei mir zutraf.
Dankenswerterweise ist Mojave wieder gecrasht und siehe da, Saved Application State ist wieder Excluded.

Das Problem ist also, dass die Exklusionsentfernung einen Crash nicht überlebt, nicht, dass sie überhaupt erst beim Herunterfahren des Rechners abgespeichert würde.

Worauf ich jetzt leider noch nicht geachtet habe, ist, was mit Exklusionen geschieht, die ich (nicht Apple) angelegt habe. Das trage ich noch nach.
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
0
Weia
Weia14.05.2022:50
Nach weiteren Crashs kann ich nun berichten, dass via tmutil selbst eingerichtete Exklusionen überleben. Nur die selbst eingestellte Inklusion des Ordners Saved Application State, den macOS von Haus aus warum auch immer exkludiert, überlebt nicht.

Ich werde jetzt also einen Launch Agent schreiben, der das bei jedem Login erneut einrichtet.
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.