Moyo
Anmeldungsdatum: 9. Juni 2014
Beiträge: 17
|
Hallo, wundere mich gerade wie folgendes Problem zustande kommt. | sudo rsync --delete --stats -PSvahHAXx --log-file=rsync.log --link-dest=/media/<username>/Volume/backup_20200702 /home/<username> /media/delluser/Volume/backup_20200726
|
Mit der Zeile sollte ein neues Backup "backup_20200726" angelegt werden, bei dem nur die geänderten Dateien seit dem letzten backup "backup_20200702" gesichert werden.
Für die ungeänderten Dateien soll ein Hard Link erzeugt werden. Das Skript funktioniert wunderbar, wenn ich es lokal auf meinem Ubuntu System laufen lasse, auf der externen Festplatte (Partition Type: NTFS/exFAT/HPFS) werden die Dateien jedes Mal komplett neu kopiert ohne Hardlinks. Weiß vielleicht jemand, woran das liegen könnte. Vielen Dank und Grüße Moyo
|
dingsbums
Anmeldungsdatum: 13. November 2010
Beiträge: 3544
|
Wenn das Ziel-Dateisystem kein Linux-Dateisystem ist, könntest du mit dem Schalter --modify-window=2 probieren. Dann nimmt es rsync mit dem exakten Zeitstempel-Vergleich nicht so genau.
|
Moyo
(Themenstarter)
Anmeldungsdatum: 9. Juni 2014
Beiträge: 17
|
Hallo dingsbuns, danke, werde ich probieren und berichten, ob es funktioniert. Wär super, wenn ich drum herum komme, die ganze 1 TB Platte neu formatieren zu müssen.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
Moyo schrieb:
danke, werde ich probieren und berichten, ob es funktioniert. Wär super, wenn ich drum herum komme, die ganze 1 TB Platte neu formatieren zu müssen.
Dazu rate ich allerdings. Das Formatieren an sich geht ja schnell - aufwändiger ist es, die Sicherungsdaten wieder drauf zu bekommen. Dass man aus Linux heraus NTFS, FAT usw. lesen und schreiben kann, ist nur eine Krücke. Du solltest dann lieber ein Linux-Dateisystem nehmen - nicht nur wegen des möglichen Problems mit den Zeitstempeln sondern auch, weil Du dann sicher sein kannst, dass alle Namen korrekt übernommen werden. Ich z.B. nutze eine 1TB-USB 3-Platte mit btrfs für meine Backups, was sehr angenehm ist, weil das die Daten mit Prüfsummen absichert.
|
Moyo
(Themenstarter)
Anmeldungsdatum: 9. Juni 2014
Beiträge: 17
|
Hallo, hab das Ganze jetzt mit probiert. Hat nicht funktioniert. Werde die Platte jetzt mal neu formatieren, auch wenn das lange dauert, mit dem vorher Wegsichern und Wiederaufspielen der Daten. Denke dann müsste es eigentlich funktionieren.
|
Jogikue
Anmeldungsdatum: 7. April 2019
Beiträge: Zähle...
|
Ist zwar schon etwas älter, aber ich habe gerade das selbe Problem.
Auch bei mir hat das mit
nichts gebracht. Nur so als Zwischen-Hint für Leute mit ähnlichen Problemen: Allerdings habe ich gerade festgestellt, dass die Permissions meiner vorherigen Sicherung und der Source nicht übereinstimmen und darum rsync das File neu schreibt.
Dabei "ändert" es wieder die Permissions ab... Ich bin mir sicher, ICH habe ein mount-Problem mit meinem USB-NTFS-Stick und muss da tiefer einsteigen...
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
Jogikue schrieb:
Ich bin mir sicher, ICH habe ein mount-Problem mit meinem USB-NTFS-Stick und muss da tiefer einsteigen...
NTFS verwaltet nicht exakt dieselben Meta-Daten wie Linux-Dateisysteme. Das kann ein Grund für die Abweichungen sein.
|
san04
Anmeldungsdatum: 19. Januar 2010
Beiträge: 1068
|
rklm schrieb: Ich z.B. nutze eine 1TB-USB 3-Platte mit btrfs für meine Backups, was sehr angenehm ist, weil das die Daten mit Prüfsummen absichert.
Damit meinst du die Absicherung der Daten während der Übertragung, oder? Wenn auf deinem Quellmedium ein Bit kippt wird das ja auch ins Backup geschrieben. Wenn du mit btfrs
dort einen Snapshot angelegt hast kannst du natürlich zurück, aber sonst ist dein Backup dann fehlerhaft, oder sehe ich das falsch?
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
san04 schrieb: rklm schrieb: Ich z.B. nutze eine 1TB-USB 3-Platte mit btrfs für meine Backups, was sehr angenehm ist, weil das die Daten mit Prüfsummen absichert.
Korrektur: die Platte hat 2TB. ☺
Damit meinst du die Absicherung der Daten während der Übertragung, oder?
Nein. Es geht um die Prüfsummen der Daten auf dem Datenträger. Hilft gegen Bitrot und hat mir auch schon mal geholfen, kaputtes RAM zu entdecken.
Wenn auf deinem Quellmedium ein Bit kippt wird das ja auch ins Backup geschrieben.
Nur, wenn das Quellmedium keine Prüfsummen hat (wie z.B. ext4). Wenn die Quelle ein btrfs ist, dann wird beim Lesen der Datei ein Fehler generiert und das bekommen dann die Backup-Software und der Nutzer mit.
Wenn du mit btfrs dort einen Snapshot angelegt hast kannst du natürlich zurück, aber sonst ist dein Backup dann fehlerhaft, oder sehe ich das falsch?
Der Snapshot hilft nur, wenn sich die Datei seit dem Snapshot geändert hat und das gekippte Bit in neuen / geänderten Blöcken vorhanden ist. Ansonsten ist das gekippte Bit Teil von mehreren / allen Versionen der Datei. Das liegt daran, dass btrfs ein CoW-Dateisystem ist. Generell ist ein btrfs Snapshot kein Backup - u.a. aus den o.g. Gründen. Egal, um welchen Datenträger es sich handelt (Quelle oder Backup-Ziel), hilft btrfs Fehler zu erkennen, die nach dem Schreiben auftreten (Bitrot). Bei borg, was ich nutze, ist das nicht unbedingt nötig, weil das seine eigene Konsistenzprüfung macht. Aber bei anderen Lösungen (z.B. BackInTime, rsync) hat man das nicht und da ist die Erkennung solcher Fehler durch das Dateisystem durchaus hilfreich. Für Metadaten nutzt man unter btrfs normalerweise ein Profil mit Redundanz (dup, raid1 u.ä.), so dass hier i.d.R. Bitrot sogar repariert werden kann, ohne dass Datenverlust entsteht.
|
san04
Anmeldungsdatum: 19. Januar 2010
Beiträge: 1068
|
rklm schrieb: san04 schrieb Wenn auf deinem Quellmedium ein Bit kippt wird das ja auch ins Backup geschrieben.
Nur, wenn das Quellmedium keine Prüfsummen hat (wie z.B. ext4).
Von dem Fall war ich jetzt ausgegangen. Aber bei anderen Lösungen (z.B. BackInTime, rsync) hat man das nicht und da ist die Erkennung solcher Fehler durch das Dateisystem durchaus hilfreich.
Ich nutze Backintime mit Hardlinks, wenn ein Bit kippt wird es eben neu ins Backup geschrieben. Wenn man irgendwann feststellt, dass dadurch ein Foto kaputt ist kann man zumindest zurückgehen. Aber natürlich ist es schöner, wenn das Dateisystem es direkt selbst bemerkt. Dafür müsste ich aber erstmal Systeme auf btrfs oder zfs umziehen, habe ich bisher noch nicht gemacht, aber schon mit dem Gedanken gespielt. Für Metadaten nutzt man unter btrfs normalerweise ein Profil mit Redundanz (dup, raid1 u.ä.), so dass hier i.d.R. Bitrot sogar repariert werden kann, ohne dass Datenverlust entsteht.
Aber damit meinst du wohl eher den Server/NAS-Bereich, oder? Am privaten PC habe ich kein raid.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
san04 schrieb: rklm schrieb: san04 schrieb Wenn auf deinem Quellmedium ein Bit kippt wird das ja auch ins Backup geschrieben.
Aber bei anderen Lösungen (z.B. BackInTime, rsync) hat man das nicht und da ist die Erkennung solcher Fehler durch das Dateisystem durchaus hilfreich.
Ich nutze Backintime mit Hardlinks, wenn ein Bit kippt wird es eben neu ins Backup geschrieben. Wenn man irgendwann feststellt, dass dadurch ein Foto kaputt ist kann man zumindest zurückgehen.
So lange die letzte Version ohne den Fehler noch nicht rausrotiert wurde. Und es ist halt die Frage, ob das gekippte Bit erkannt wird.
Aber natürlich ist es schöner, wenn das Dateisystem es direkt selbst bemerkt. Dafür müsste ich aber erstmal Systeme auf btrfs oder zfs umziehen, habe ich bisher noch nicht gemacht, aber schon mit dem Gedanken gespielt.
Aber damit meinst du wohl eher den Server/NAS-Bereich, oder? Am privaten PC habe ich kein raid.
Du kannst da mindestens DUP haben. Und ein Privat-Rechner mit zwei Platten ist auch nicht so ungewöhnlich.
|
san04
Anmeldungsdatum: 19. Januar 2010
Beiträge: 1068
|
rklm schrieb: So lange die letzte Version ohne den Fehler noch nicht rausrotiert wurde.
Die müssen zum Glück nicht rotieren, so groß ist die veränderliche Datenmenge nicht.
Und es ist halt die Frage, ob das gekippte Bit erkannt wird.
Wie meinst du das, bzw. wer erkennt das? Ich bin von dem Fall ausgegangen, das Bit ist gekippt, dann wird es so erkannt und als gekippt ins Backup geschrieben, oder eben nicht, dann ist eh alles gut.
Du kannst da mindestens DUP haben.
Meinst du damit Deduplikation?
Und ein Privat-Rechner mit zwei Platten ist auch nicht so ungewöhnlich.
Ok, dann bin ich da zu hobbymäßig unterwegs 😉
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
san04 schrieb: rklm schrieb: So lange die letzte Version ohne den Fehler noch nicht rausrotiert wurde.
Die müssen zum Glück nicht rotieren, so groß ist die veränderliche Datenmenge nicht.
Üblicherweise hat man ja bei Backups das Verfahren, dass man eine bestimmte Anzahl Backups erzeugt und dann immer die ältesten löscht. Egal, wie das jetzt im Einzelfall organisiert ist, bedeutet das, dass irgendwann mal ein alter Stand einer Datei gelöscht wird. Man hat ja nicht unendlich Platz - und will vielleicht auch gar nicht zu viele Stände verfügbar halten.
Und es ist halt die Frage, ob das gekippte Bit erkannt wird.
Wie meinst du das, bzw. wer erkennt das?
rsync liest ja nicht alle Dateien komplett um festzustellen, ob es eine Änderung gab (außer man nutzt "--checksum"). Das bedeutet, dass es Heuristiken benutzt, die schnell ausgewertet werden können (z.B. den Namen, die Größe, die verschiedenen Daten) und die entsprechend gekippte Bits nicht erkennen würden. Was also passiert: Datei ist OK Sicherungen werden gemacht Bit in der Quelldatei kippt Nehmen wir an, es wird erkannt (rsync --checksum ), dann wird eine neue Sicherung mit dem gekippten Bit gemacht. Weitere Sicherungen werden gemacht und alte werden gelöscht. Irgendwann ist der letzte Stand ohne das gekippte Bit gelöscht und man hat nur noch die Version mit dem gekippten Bit auf der Platte und im Backup. Jetzt kann man nicht mehr zur heilen Version zurück.
Wenn das gekippte Bit im Schritt 4 nicht erkannt wird, hat man im Backup immer die Version ohne das gekippte Bit. Wenn die erste Sicherung gemacht wird, nachdem das Bit gekippt ist, hast Du also auch immer nur die Version mit gekipptem Bit im Backup.
Ich bin von dem Fall ausgegangen, das Bit ist gekippt, dann wird es so erkannt
Aber es wird ja nicht erkannt, wenn man kein btrfs oder anderes Dateisystem mit Prüfsummen nutzt.
und als gekippt ins Backup geschrieben, oder eben nicht, dann ist eh alles gut.
Selbst dann hast Du ein Problem, denn Du weißt nicht, ob die Daten in Ordnung sind oder nicht. Und Dir kann ja auch noch im Backup ein Bit unbemerkt kippen... Es gibt eine ganz interessante Studie vom CERN zum Thema "Data Corruption".
Du kannst da mindestens DUP haben.
Meinst du damit Deduplikation?
Nein. Das ist eins der btrfs-Profile.
|
san04
Anmeldungsdatum: 19. Januar 2010
Beiträge: 1068
|
rklm schrieb: Üblicherweise hat man ja bei Backups das Verfahren, dass man eine bestimmte Anzahl Backups erzeugt und dann immer die ältesten löscht.
Bei mir gehts hauptsächlich um private Fotos und ein paar Dateien, da kann ich mir das erlauben nicht zu rotieren, die werden nur mehr 😉
Ich könnte daher immer zur heilen Version zurückkehren. (außer bei deinem Szenario weiter unten, Bit-Fehler im Backup) Weil ich genau so vor einigen Jahren mal eine Hand voll Fotos verloren habe war mir das wichtig. Ich bin von dem Fall ausgegangen, das Bit ist gekippt, dann wird es so erkannt
Aber es wird ja nicht erkannt, wenn man kein btrfs oder anderes Dateisystem mit Prüfsummen nutzt.
Sorry, hier war meine Formulierung einfach falsch... Ich meinte "gelesen" und nicht "erkannt". Wenn das Bit falsch gelesen wird, wird es entsprechend falsch ins Backup geschrieben. Ohne rotierendes Backup kann ich auf den vorherigen Stand zurück, wenn ich feststelle, dass z.B. ein Foto kaputt ist.
Und Dir kann ja auch noch im Backup ein Bit unbemerkt kippen...
Daran hab ich tatsächlich bisher nicht gedacht. Wenn ich das dann erst feststelle, wenn ich das Backup einspiele, wäre das wirklich blöd...
Es gibt eine ganz interessante Studie vom CERN zum Thema "Data Corruption".
Danke für den Link, wirklich interessante Studie und überraschende Zahlen... Also bei der nächsten Gelegenheit wohl doch mal auf btrfs/zfs umstellen ☺
|