Wäre tatsächlich relevant zu wissen, welches Betriebssystem auf dem PC von @maxmoon läuft.
Hallo maxmoon,
Du willst anscheinend kein NAS aber genau dessen Funktionen hinsichtlich Dateisystem.
rsync wie vermutlich auch robocopy arbeiten beim Syncronisieren von Quelle und Ziel nach meinem Kenntnisstand ausschließlich mit dem Metainformationen der Dateien innerhalb des Dateisystems. Also Erstellung-/Änderungsdatum, Dateigröße etc.
Da läuft nichts mit Prüfsummen.
Aber genau das macht ZFS. Beim Scrub werden die Prüfsummen verwendet und vermutlich zum Vergleich neu berechnet.Und damit kann ZFS dann Bitflips korrigieren.
Damit bist du wieder beim Thema NAS. Direkt attached Storage i (DAS) st m. W. nur eine Frage des Anschlusses am Host. Aber solange du auf deinem PC kein ZFS hast geht es kaum anders. Weil du eben im Idealfall ein BSD-System als Basis für ZFS brauchst. Das bekommst du auf z. B. TrueNAS.
Was das replizieren deiner Daten auf ein und dieselbe Platte betrifft:
Du willst, so ich richtig verstanden habe, Datenstrukturen synchronisieren. Soweit so gut. Aber dazu gibst du rsync oder auch robocopy die Löschweitergabe in den Parametern mit. Wenn also beim sync was mit der Quelle passiert, was rsync/robocopy nicht SOFORT um Absturz bringen, dann werden beide Programme brav die in der Quelle fehlenden Daten am Ziel ebenfalls killen. Deshalb immer Zieldatenträger mit mindestens 2 Generationen. Denn sobald auf der Zielplatte Daten gelöscht werden, sind die Blöcke frei und werden u. U. direkt überschrieben.
1 „Gefällt mir“
Genau aus diesem Grund außerhalb von dem zu prüfenden Datenträger eine Tabelle mit Prüfsummen der darauf enthaltenen Daten führen und dann die Datei überschreiben, die als „geändert“ erkannt wird (bzw. den Bitrost hat), weil Videodateien ändern sich zumindest bei mir nicht. Und so hätte man den unglaublich unwahrscheinlichen Fall vom Bitrost abgefangen, wenn man das unbedingt machen will.
Aber so etwas wie Bitrost ist doch wirklich schon abgefangen, wenn man 2 Festplatten hat auf denen man die Videodateien kopiert (nicht synchron hält) und einfach nur nach Existenz einer Datei geht. Also wenn diese auf Platte 1 existiert, diese auf Platte 2 kopiert und nicht darauf schaut ob sich diese verändert hat. Spätestens beim Editieren könnte dann der Bitrost auffallen und wenn dieser tatsächlich auftritt, die selbe Datei von Platte 2 auf Platte 1 kopieren lassen.
Und das war jetzt eine sehr einfache Lösung, wo man sich ein kurzes Skript schreiben kann, um Daten auf zwei Festplatten rostfrei und recht sicher halten kann. 
Auf den Bitrost bin ich oben schon eingegangen, doch möchte ich noch tiefer eingehen:
Bitrost - Ein Bit flippt in einer Datei
Es ist ein unglaublich unwahrscheinlicher Fall, dass nur ein Bit in einer Datei flippt. Und selbst wenn es passiert, wird es je nachdem nur ein Fehler im Video sein, bzw. ein Frame oder ein Pixel, der nicht auffällt. Das der Flip an einer Stelle in der Datei passiert, wo die Datei irreversibel zerstört wird, ist doch noch unwahrscheinlicher als der Bitrost selbst.
Es wäre ungefähr so, als würde ich darauf hoffen mehrmals in Folge den Lotto-Jackpot abzuräumen, obwohl es schon unglaublich unwahrscheinlich ist den Jackpot nur einmal abzuräumen.
Wie viele Leute gibt es denn hier, die schon einen Bitrost/geflippten Bit hatten? Ich bin mir ziemlich sicher, dass jede Platte, die ich hatte, vorher mechanisch kaputt gegangen ist, bevor ich einem Bitrost begegnet bin.
ZFS oder ähnliche Dateisysteme
Bei solchen Dateisystemen sehe ich immer noch die Gefahr, dass der Datenträger mehr abgenutzt wird und viel eher verschleißt als bei klassischen Dateisystemen (z.B. ext4). Also auch die Wahrscheinlichkeit erhöht wird einem Bitrost oder komplettes Versagen des Datenträgers zu begegnen.
In der Sache bin ich halt wirklich skeptisch² und sehe da ein Paradoxon.