ZFX + Developia

Moin,

Ich synchronisere meine Dateien ja per Seafile. Neulich ging mein Server kaputt und es hat etwas gedauert ihn neu aufzusetzen und danach waren eigentlich synchronisierte Ordner auf verschiedenen Geräten unterschiedlich und ich habe sie von Hand gemerged als der Server wieder lief. Das lief auch alles ganz gut bis auf eine einzige Ausnahme. Eine PDF aus dem letzten Jahr (die ich runtergeladen und garantiert nie von Hand geändert habe) war auf beiden Geräten subtil unterschiedlich. Mein Merge-Tool zeigt das hier an:
Die meisten Unterschiede sind binär und nicht zu verstehen. Das Tool arbeitet ja "zeilenweise", insgesamt sind, wie man links sieht, vlt. 5% der Dateien unterschiedlich. Der Teil, in dem man zumindest ein wenig lesen kann, scheint irgendwie mit embedded Fonts zu tun zu haben.

Beide Dateien lassen sich mit Sumatra PDF problemlos öffnen und sehen am Bildschirm komplett identisch aus. Eigentlich brauch ich die pdf auch gar nicht mehr, es geht hier also nicht irgendwie um Datenverlust. Aber zwei Fragen beschäftigen mich doch:

- Wie kann es sein, dass sich eine PDF einfach verändert? Ein Reader der die PDF automatisiert in einer aktuelleren Dokumentenversion speichert? Oder irgendetwas auf lokal installierte Fonts anpasst (das dürfte aber ja nicht sein, da PDF ja Geräteunabhängig sein sollten)?

- Wieso wurde die Datei, wenn geändert, nicht synchronisiert? Ich habe mit Sicherheit die PDF seit der Server down war nicht mehr angefasst, es könnte höchstens ein Hintergrundprozess damit irgendetwas getan haben. Ein Bug in Seafile, der Änderungen nicht erkennt (etwa weil das Dateidatum nicht modifiziert wurde und Seafile aus Effizienzgründen nicht bei jedem Start jede Datei bit für bit überprüft)? Eine Sonderbehandlung von PDF Dateien, weil es Unterschiede gibt die irrelevant sind und damit nicht synchronisiert werden sollten?

Wie gesagt, die PDF ist mir egal, aber ich möchte den Sachverhalt gerne verstehen. Ich will mich ja darauf verlassen können, dass meine Daten wirklich synchronisiert sind und zwar binär-identisch. Und die Frage ist ja auch ansich von Seafile unabhängig: Wenn man ein Backup macht, vergleicht man dann die Daten nach dem kopieren nochmal? Oder muss man die Dateien alle paar Wochen/Monate mit dem Backup Vergleich um zu erkennen, ob sich etwas "von selber" geändert hat, obwohl man sie nicht angefasst hat? Hat man hier einen partiellen Datenverlust, weil Teile der Datei nicht mehr gelesen werden können, aber "kluge" Reader das Problem verschleiern? Usw...

Jonathan hat geschrieben: ↑04.06.2023, 22:48Beide Dateien lassen sich mit Sumatra PDF problemlos öffnen und sehen am Bildschirm komplett identisch aus.

Nicht alle Teile eines PDFs sind tatsächlich genutzt. Tatsächlich enthält ein PDF alle Revisionen und von Software wird erwartet, Änderungen immer hinten anzuhängen. Darum kannst du PDFs oft auch noch öffnen, wenn in der Mitte was kaputt ist – das ist halt nicht die Revision, die aktiv angezeigt wird.

Jonathan hat geschrieben: ↑04.06.2023, 22:48Die meisten Unterschiede sind binär und nicht zu verstehen.

Die Änderungen ergeben keinen Sinn und erinnern an nichts aus dem PDF-Standard.

o und k sind genau ein Bit auseinander (01101111 vs. 01101011); t und 4 ebenfalls (01110100 vs. 00110100). Das lässt auf einen Hardware-Fehler schließen.

Durch die Änderungen ist das PDF kaputt. Die Änderungen sind definitiv Beschädigung, nicht Absicht.

Ich glaube nicht, dass die HDD hier ihren Geist aufgibt – dann wären die Fehler wahrscheinlich blockweise. Übertragungsfehler im Netzwerk oder Bug in Seafile klingt wahrscheinlicher.

Das würde dann auch erklären, warum die Datei nicht synchronisiert ist: Seafile hat sie synchronisiert. Sie sind aber entweder dabei oder danach kaputtgegangen. Übertragungsfehler ändern natürlich nicht das letzte Änderungsdatum der Datei.

Ein Bug in Seafile, der Änderungen nicht erkennt (etwa weil das Dateidatum nicht modifiziert wurde und Seafile aus Effizienzgründen nicht bei jedem Start jede Datei bit für bit überprüft)?

Kein Bug, sondern Feature, denke ich. Macht schon einen krassen Performance-Unterschied.

Wenn man ein Backup macht, vergleicht man dann die Daten nach dem kopieren nochmal?

Ja. Das schreibe ich hier seit Jahren, weil ich bereits zwei Mal stillen Datenverlust hatte, der nur durch ein komplettes Diff gefunden werden konnte (steht x Mal im Jammer-Thread). Dann merkst du auch schnell, warum Seafile das wahrscheinlich nicht tut – „langsam“ ist gar kein Ausdruck :D

Ugh, ja, klingt schlecht...

Nun denn. Wie vergleiche ich Dateien am besten übers Netzwerk? Also, stöpsel ich meine externe USB Platte ein würde ich einfach Tools wie WinMerge oder FreeFileSync benutzen, die jeweils Optionen haben, die kompletten Dateiinhalte zu vergleichen. Aber wenn ich einen Ordner per Netzwerk auf 2 verschiedenen Rechnern habe bräuchte ich ja eher eine Lösung die z.B. eine Liste aller Dateien anlegt, zu jeder Datei den Hash berechnet und diese Liste dann in einer Datei speichert die ich "atomar" synchronisieren und dann vergleichen kann. Gibts dazu schon etwas fertiges?

Und wie ist das "Langzeitprotokoll": Angenommen ich habe ein Backup von meinem Projektordner auf meiner externen Datensicherungsplatte angelegt und auch verifiziert dass die Dateien identisch sind. Ein halbes Jahr später möchte ich ein neues Backup anlegen. Wie finde ich heraus, ob irgendeine Datei versehentlich kaputt gegangen ist? Ich habe ja in dem Verzeichnis gearbeitet, natürlich sind zig Dateien anders. Da kann ich nicht jede einzige Änderung per Hand überprüfen.
Das beste was mir einfällt ist nach jedem Backup alle Daten wieder in die andere Richtung zu kopieren, damit sie "frisch" sind und hoffentlich länger halten, und dann später einfach davon auszugehen, dass der Abstand zwischen 2 vollständigen Backups kurz genug war, so dass alle Dateien ihren korrekten Inhalt haben.
Aber eigentlich müsste das Dateisystem ja auch so Dinge tun wie Dateien bei jedem Schreibvorgang hashen damit erkannt werden kann, ob sich etwas gewollt oder ungewollt verändert hat (eigentlich muss man ja eher Dateien vor und nach dem schreiben hashen, damit falls nur ein Teil überschrieben wird klar ist, das sich der Rest der Datei auch nicht verändert hat). Sowas gibt es bestimmt, aber vermutlich eher nicht in NTFS...

Jonathan hat geschrieben: ↑05.06.2023, 06:46Nun denn. Wie vergleiche ich Dateien am besten übers Netzwerk? Also, stöpsel ich meine externe USB Platte ein würde ich einfach Tools wie WinMerge oder FreeFileSync benutzen, die jeweils Optionen haben, die kompletten Dateiinhalte zu vergleichen. Aber wenn ich einen Ordner per Netzwerk auf 2 verschiedenen Rechnern habe bräuchte ich ja eher eine Lösung die z.B. eine Liste aller Dateien anlegt, zu jeder Datei den Hash berechnet und diese Liste dann in einer Datei speichert die ich "atomar" synchronisieren und dann vergleichen kann. Gibts dazu schon etwas fertiges?

Keine Ahnung. 7-Zip ist sehr schnell im Hashen von Dateien. Bedenk auch, dass digitale Signaturen dieses Problem zuverlässig beseitigen (falls du irgendwas hast, um Archive zu signieren).

Das beste was mir einfällt ist nach jedem Backup alle Daten wieder in die andere Richtung zu kopieren, damit sie "frisch" sind und hoffentlich länger halten,

… wenn’s in die TiB geht, verbrennst du eher die Lebenszeit der Platte. Intuitiv würde ich sagen, je weniger du die Daten anpackst, desto besser.

Aber eigentlich müsste das Dateisystem ja auch so Dinge tun wie Dateien bei jedem Schreibvorgang hashen damit erkannt werden kann, ob sich etwas gewollt oder ungewollt verändert hat (eigentlich muss man ja eher Dateien vor und nach dem schreiben hashen, damit falls nur ein Teil überschrieben wird klar ist, das sich der Rest der Datei auch nicht verändert hat). Sowas gibt es bestimmt, aber vermutlich eher nicht in NTFS...

Das Dateisystem wird nicht informiert, wenn die Festplatte Daten verliert. Die Platte merkt es ja selber kaum. Theoretisch sollte NTFS anfangen, dich zu warnen, wenn Sektoren kippen; praktisch hatte ich bisher immer nur Datenverlust ohne Warnung o. Ä.

Krishty hat geschrieben: ↑05.06.2023, 08:21Bedenk auch, dass digitale Signaturen dieses Problem zuverlässig beseitigen (falls du irgendwas hast, um Archive zu signieren).

Hm, ja schon, aber ich synchronisiere quasi mein Arbeitsverzeichnis, da ist eigentlich nichts signiert. Ein paar Sachen sind in git-Repositories, das signiert ja prinzipiell alles, aber ich bezweifle, dass git regelmäßig alle Dateien scannt um umgekippte Bits zu finden. Wenn die Datei-Größe und das Änderungsdatum gleich bleibt kriegt git vermutlich von den Änderungen nichts mit.

… wenn’s in die TiB geht, verbrennst du eher die Lebenszeit der Platte. Intuitiv würde ich sagen, je weniger du die Daten anpackst, desto besser.

Die Idee entsprang mir aus dem anderen Thread über die Zuverlässigkeit von Festplatten. Im Sinne von "Es gibt keinen Datenspeicher, auf den man einmal alles schreiben kann und dann 10 Jahre im Schrank liegen lassen kann, und danach ist garantiert noch alles da".

Das Dateisystem wird nicht informiert, wenn die Festplatte Daten verliert. Die Platte merkt es ja selber kaum. Theoretisch sollte NTFS anfangen, dich zu warnen, wenn Sektoren kippen; praktisch hatte ich bisher immer nur Datenverlust ohne Warnung o. Ä.

Naja, meine Idee war halt, dass das Dateisystem nicht informiert werden muss, sondern selbstständig bei jedem Zugriff überprüft, ob die Daten noch heil sind. Ab dem Zeitpunkt sind die Daten zwar schon kaputt, aber wenn man frühzeitig gewarnt wird, hat man vermutlich noch irgendwo ein Backup um sie wiederherzustellen. Meine Backups funktionieren zumindest so, dass ich den Ordner mit all den wichtigen Dateien auf eine externe Festplatte kopiere und nach dem Datum benenne. Ich habe dann jeweils noch 1-2 ältere Versionen des Ordners (ggf. auf anderen Platten) die ich dann aber irgendwann auch lösche. Wenn eine Datei kaputt geht und ich nicht gewarnt werde, hab ich so nach ein paar Monaten keine einzige Kopie mehr davon.

Krishty hat geschrieben: ↑05.06.2023, 08:217-Zip ist sehr schnell im Hashen von Dateien.

Tatsächlich sieht
7z h * > hashs.txt
ziemlich gut aus. Liefert eine Textdatei mit Hashs zu allen Dateien in allen Unterordnern des aktuellen Verzeichnis. Ich hoffe die Reihenfolge ist wohldefiniert, dann kann man das einfach einmal auf beiden Maschinen ausführen und sein Lieblings-Text-Diff Tool darauf anschmeißen um Unterschiede zu finden.

Das sollte ja auch das "Daten sollten regelmäßig gelesen werden um die Platte neu zu magnetisieren"-Problem lösen, wenn man den Befehl regelmäßig auf seinem Backup-Verzeichnis ausführt.

(Da kommt mir doch glatt die Idee einen Context-Menü-Eintrag dafür anzulegen :D )

Jonathan hat geschrieben: ↑08.06.2023, 12:19(Da kommt mir doch glatt die Idee einen Context-Menü-Eintrag dafür anzulegen :D )

7-Zip bringt doch schon einen mit?!

Jonathan hat geschrieben: ↑08.06.2023, 12:19Das sollte ja auch das "Daten sollten regelmäßig gelesen werden um die Platte neu zu magnetisieren"-Problem lösen, wenn man den Befehl regelmäßig auf seinem Backup-Verzeichnis ausführt.

Genau. Der Unterschied zum Neubeschreiben ist, dass dann nur die Festplatte remagnetisiert, und sich nicht das Dateisystem ändert.

Krishty hat geschrieben: ↑08.06.2023, 12:447-Zip bringt doch schon einen mit?!

Haha, hupsi, ich hab wohl unterbewusst nach Einsatzmöglichkeiten für mein neues Spielzeug gesucht :D