[10.6 Snow Leopard] TimeMachine: Backup enthält nicht mehr die veränderten Daten

[naich]

Hallo,
Ich benutze nen direkt angeschlossene externe Platte für mein TM Backup.

Folgendes Problem: Ich habe mich gewundert, dass seit heute die TM Backups sehr schnell fertig sind, trotz der Tatsache, dass ich mehrere GB an Daten geändert habe. Die Backups sind einwandfrei durchgelaufen, ohne Fehlermeldung.

Allerdings zeigt mir das Programm BackupLoupe an, dass lediglich nen Log und die Einstellungsdatei gesichert wurden.

Ebenfalls steht in der Konsole:

30.04.11 23:15:31 com.apple.backupd[29216] Starting standard backup
30.04.11 23:15:31 com.apple.backupd[29216] Backing up to: /Volumes/Backup/Backups.backupdb
30.04.11 23:15:32 com.apple.backupd[29216] No pre-backup thinning needed: 3.57 GB requested (including padding), 16.19 GB available
30.04.11 23:15:33 com.apple.backupd[29216] Copied 8 files (93 bytes) from volume Macintosh HD.

D.h. er sichert wirklich nur die Einstellungen.

Alle Backups von heute sehen so aus, während ältere noch eine sinnvolle Größe haben.

Ich habe schon versucht, alle Backups von heute zu löschen, und dann ein neues zu erstellen, allerdings mit dem gleichen Ergebnis. Weiterhin habe ich schon Rechte- und Festplattenüberprüfung auf beiden Platten (externe und interne) durchlaufen lassen, ohne dass das geholfen hat.

Hat jemand eine Idee, wie man das Problem lösen könnte? TM scheint ja manchmal (nach Fehlern) ein Komplettscan des (letzten?) Backups durchzuführen (123 Objekte werden überprüft...). Kann man evt. diesen Prozess manuell anstoßen?

 

[gKar]

Ich würde mal den Metadaten-Index („Spotlight-Index“) der zu sichernden Platte löschen.
(Z.B., indem man die Platte in den Spotlight-Einstellungen vorübergehend auf die Exclude-Liste setzt und etwas später (nicht sofort) wieder von dieser Liste runternimmt. Dann müsste Spotlight neu indizieren und m.W. auch TimeMachine einen neuen Komplettscan nach zu sichernden Dateien durchführen.

 

[Rastafari]

Du hast vermutlich deinen fsevents-Daemon zerschossen. Ein bisserl ungeschickt "ge-sudo"t?
(Oder ungeschickt an der Systemuhr gedreht? TM mag es nicht, wenn die Uhr rückwärts zu laufen scheint.)

Last Resort:
Starte deine Kiste mal im Single-User Modus (Vorsicht, englische Tastaturbelegung!) und führe dort folgendes durch:

/sbin/fsck -fy
/sbin/mount -uw /
/usr/bin/find -dx / -type d -o -type f -print -exec /usr/bin/touch {} +
/bin/sync
/bin/rm -f  /.fseventsd/*
/bin/sync
exit

Einfacher gemacht:
Speichere obiges Skript als Textdatei (Reiner Text!) im Stammordner deines Startvolumes, dann kannst du es ganz einfach mit nur einem einzigen Kommando aufrufen:

source [I]repair.txt[/I]

Danach sollte (müsste) deine TM ein brutalstmögliches Vollbackup fahren.

 

[naich]

Vielen Dank für die schnellen Antworten.

Den Spotlight-Index neu aufbauen hat nix gebracht.

Nach leeren des .fseventdb-Ordners macht TM wieder den schon erwähnten Scan:

01.05.11 13:32:10 com.apple.backupd[909] Event store UUIDs don't match for volume: Macintosh HD
01.05.11 13:32:10 com.apple.backupd[909] Node requires deep traversal:/ reason:must scan subdirs|new event db|

Nun werden alle ab jetzt geänderten Dateien scheinbar wieder ordentlich gesichert.

Wegen der Datenmenge wiederstrebt es mir, ein erneutes Komplettbackup anzustoßen, daher habe ich erstmal nur den Ordner mit touch bearbeitet, in dem ich gestern Änderungen gemacht habe.

Gibt es evt. noch eine Möglichkeit zu überprüfen, ob nun noch andere gestern geänderte Dateien im Backup fehlen?
Ich habe gesehen, dass auch das Backup-Volume einen .fseventd/ - Ordner besitzt, macht es Sinn, diesen zu löschen?!

Edit:

Dein find findet nur Dateien, keine Ordner. Du meintest wahrscheinlich wohl sowas:

/usr/bin/find -dx / \( -type d -o -type f \) -print -exec /usr/bin/touch {} +

 

[Rastafari]

Gibt es evt. noch eine Möglichkeit zu überprüfen, ob nun noch andere gestern geänderte Dateien im Backup fehlen?

Eine zuverlässige Prüfung würde länger dauern als die Daten gleich ohne Prüfung zu sichern.

dass auch das Backup-Volume einen .fseventd/ - Ordner besitzt, macht es Sinn, diesen zu löschen?!

Nein.

Dein find findet nur Dateien, keine Ordner.

Wie kommst du denn da drauf??

 

[naich]

Wie kommst du denn da drauf??

Weil ich das getestet habe, und danach alle Dateien den neuen Datumstempel haben, die Ordner aber noch den alten!?

Eine zuverlässige Prüfung würde länger dauern als die Daten gleich ohne Prüfung zu sichern.

Zeit habe ich prinzipiell, mir gehts darum, dass ich bei einem neuen Vollbackup wohl fast meine komplette TM-Historie verlieren würde, was ich nicht unbedingt will.

Kennst du (außer diff) nen Tool, was mir veraltete Dateien im Backup möglichst zuverlässig anzeigen könnte?

 

[florian1977]

Neu starten hilft meistens.


Sent from my iPhone using Tapatalk

 

[Rastafari]

Weil ich das getestet habe

Teste es vielleicht noch mal mit einem '-print'

TM-Historie verlieren

Äääh. Wat?

außer diff) nen Tool, was mir veraltete Dateien im Backup möglichst zuverlässig anzeigen könnte?

Content: cmp || rsync || md5 || ...
Meta: stat && xattr && GetFileInfo && 'ls -le' && afsctool + ...

 

[naich]

Neu starten hilft meistens.

Hehe, wir sind doch hier nicht unter Windows. :-D
Aber natürlich hab ich das nebenbei auch schon gemacht.

Teste es vielleicht noch mal mit einem '-print'

Ich hab die ganze Zeit mit print getestet. Ich weiß zwar nicht welche find-Version du besitzt, aber meine hört bei einem OR auf, den 2. Ausdruck zu evaluieren, wenn der erste schon TRUE ist.

Äääh. Wat?

Man nehme eine Backup-Platte, auf der 250 GB gesamt fürs Backup Platz ist, der aktuelle freie Speicherplatz sei 20 GB. Nun führe man ein Vollbackup von ca. 140 GB Größe aus.
Hier ist nun die Frage, wieviele der Alt-Backups hierbei gelöscht werden müssen. Schließlich müssen die verbleibenden Alt-Backups immer noch vollständig sein...

rsync

Ja, auf die Idee bin ich auch schon gekommen...

 

[Rastafari]

Ich weiß zwar nicht welche find-Version du besitzt, aber meine hört bei einem OR auf, den 2. Ausdruck zu evaluieren, wenn der erste schon TRUE ist.

Ein Ordner, der gleichzeitig ein File ist? Hmmm... überlegenswert.
Teste es doch noch mal ganz simpel:

find -dx $HOME -type f -o -type d

Wie lautet die letzte Zeile? Etwa '/Users/naich' ?

 

[MacAlzenau]

Hier ist nun die Frage, wieviele der Alt-Backups hierbei gelöscht werden müssen. Schließlich müssen die verbleibenden Alt-Backups immer noch vollständig sein...

Soviele, bis der Platz reicht, inklusive etwas mehr, was zur Arbeit gebraucht wird. Dateien aus den gelöschten Backupversionen, die in späteren Versionen noch vorhanden sind, werden entsprechend verschoben, die Hardlinks der noch neueren Versionen angepasst.
Dabei wird peu à peu vorgegangen, was erklärt, wieso das manchmal arg lange dauern kann.

 

[naich]

Wie lautet die letzte Zeile? Etwa '/Users/naich' ?

Ach, ist ja auch kein Wunder, wenn du nach "-type d" nix weiter schreibst. Wie wärs wenn du es selbst mal testest und hintenan noch "-print" oder "-exec echo {} \;" hängst?! Ich dachte du würdest die Vorrangregeln von den boolschen Operatoren kennen ...

Btw ist es prinzipiell überhaupt nötig, die Folder mit zu "touchen"? Ich kann mir vorstellen dass es auch reicht, wenn man es nur mit den Dateien macht.

@MacAlzenau
Eben. Wenn ich annehme, dass vor dem Backup-Problem ein Vollbackup auch ca. 120 Gb groß ist würde ich max. ein älteres Backup behalten, was mir etwas wenig ist.

BTT: Ich habe mir jetzt mal mit rsync eine Liste aller Dateien gemacht, die noch verschieden sind. Dabei ist in der Textdatei jede Datei / jedes Verzeichnis in einer Zeile aufgelistet.

Nun versuche ich nur die Dateien an touch zu übergeben:

cat /Users/lll/diffNeu.txt | xargs -I {} /Users/lll/touchIfExists.sh "{}"

und das Script:

#!/bin/bash
test -e "/$1" && touch "/$1"

Nun ist das Problem, dass xargs wohl auch nach Leerzeichen trennt, und "unterminated quote" als Fehler ausspuckt. Einzige Variante ist wohl, dass man den Trenner auf \0 umbastelt und xargs mit -0 startet. Weiß jemand wie das machbar wäre?
Oder vielleicht gibt es eine Variante, die gänzlich ohne xargs auskommt?

Edit:
OK, auch ohne xargs geht es einfacher, als ich dachte:

#!/bin/sh
while read line; do
test -e "/$line" && touch "/$line"
done < /Users/lll/diffNeu.txt

 

[naich]

Nachdem nun einige Zeit die Backups wieder normal funktioniert haben, geht das Problem seit gestern abend wieder von vorne los (zu dem Zeitpunkt habe ich die interne Festplatte überprüfen und Rechte reparieren lassen).

Das Log meint:

May 28 20:33:59 macbook fseventsd[30]: check_vol_last_mod_time:XXX failed to get mount time (45; &mount_time == 0x10037f8b8)
May 28 20:33:59 macbook fseventsd[30]: log dir: /Volumes/HDD2/.fseventsd getting new uuid: 92593E6D-7AB9-4323-A6A1-0248378AD183
May 28 21:31:13 macbook fseventsd[30]: scan_old: bailing out because device mounted @ /Volumes/WualaDrive has dls 0x0 and dls->fci 0x0
May 28 21:42:36 macbook fseventsd[30]: scan_old: bailing out because device mounted @ /Volumes/WualaDrive has dls 0x0 and dls->fci 0x0
May 28 21:42:53 macbook fseventsd[30]: scan_old: bailing out because device mounted @ /Volumes/WualaDrive has dls 0x0 and dls->fci 0x0
May 29 10:04:17 macbook fseventsd[30]: could not open <</Volumes/HDD2/.fseventsd/fseventsd-uuid>> (No such file or directory)
May 29 10:04:17 macbook fseventsd[30]: log dir: /Volumes/HDD2/.fseventsd getting new uuid: 999F8643-E42B-495F-B95F-4A5A6ADD2033

Weiß jemand, ob die erste Zeile für TM von Belang ist? HDD2 ist eine 2. Partition auf der externen Festplatte, auf die manuelle Backups geschrieben werden.
Und die Fehler bzgl. dem WualaDrive kommen häufiger, die habe ich aber bisher ignoriert, weil sie imho nix mit dem Problem zu tun haben.

Ich überlege, ob es Sinn macht, die Backups komplett zu löschen und neu anzufangen (formatieren der Backup-Partition ist aber schlecht, da dort noch andere Daten liegen). Ich bin mir nur unsicher ob es wirklich das Problem löst...