Ich habe für diesen Zweck eine Reihe von Tools erstellt, die Reed-Solomon verwendet, und pyFileFixity genannt ( die Liste der enthaltenen Tools finden Sie hier ). Es funktioniert meistens von der Kommandozeile aus, aber es wird eine experimentelle Benutzeroberfläche bereitgestellt, wenn Sie es wirklich ausprobieren möchten (verwenden Sie einfach die --gui
Kommandozeile).
Ich habe dieses Tool so entwickelt, dass es Open Source und zuverlässig ist. Es wurde mit 83% getestet (Filialabdeckung). Die gesamte Bibliothek ist ausführlich kommentiert, und ich habe den Reed-Solomon-Codec selbst entwickelt, alles in reinem Python (dh das gesamte Projekt ist eigenständig, es gibt keine externe Bibliothek) und ist somit zukunftssicher (sofern Sie einen Python 2 haben.) Interpreter, aber eine Python 3-Version ist in Arbeit ). Es sollte produktionsreif sein, ich verwende es regelmäßig selbst und hatte mehrere positive Rückmeldungen, und jedes zusätzliche Feedback ist sehr willkommen!
Das von mir entwickelte ecc-Format sollte SEHR stabil und unempfindlich gegen Beschädigungen sein, da sogar die ecc-Dateien korrigiert werden können (siehe repair_ecc.py und die Indexdateien). Das Projekt gibt Ihnen alles, um Ihre Daten zu kuratieren UND um Ihr Kuratierungsschema zu testen (siehe filetamper.py und resilency_tester.py. Sie können das gesamte Kuratierungsschema mit einer makefileähnlichen Datei testen, in der das Kuratierungsschema beschrieben wird Dateikonvertierungen, ZIP-Komprimierung, pyFileFixity ecc-Berechnung oder ein anderes ecc-Berechnungsschema usw. und testen, ob Ihre Kurationspipeline einem gewissen Ausmaß an zufälliger Datenbeschädigung standhalten kann.
Die Einschränkung besteht jedoch darin, dass die Berechnungen einige Zeit in Anspruch nehmen werden. Derzeit liegt die Rate bei ~ 1 MB / s, obwohl ich vorhabe, die Geschwindigkeit mit Parallelität zu vervierfachen. Trotzdem kann man dies als Einschränkung sehen, und leider glaube ich nicht, dass es einen schnelleren Fehlercode für die Fehlerkorrektur gibt (Reed-Solomon ist so ziemlich der einzig reife, LDPC kommt aber noch nicht).
Wenn Sie nicht die WHOLE-Datenintegrität, sondern die meisten Datenintegrität sicherstellen müssen, besteht die Alternative darin, einen nicht soliden Archivierungsalgorithmus wie ZIP DEFLATE zu verwenden und dann den ECC-Hash nur im Header mithilfe von header_ecc.py zu berechnen ( in pyFileFixity bereitgestellt). Dadurch wird sichergestellt, dass Ihr Archiv immer geöffnet werden kann und die meisten Daten darin nicht komprimierbar sind. Es können jedoch nicht alle Datentampfer korrigiert werden.
Es gibt auch das DAR-Archivformat, eine Alternative zu TAR, die eine unkomprimierte Komprimierung (damit eine teilweise Dekomprimierung beschädigter Archive möglich ist) und eine auf PAR2 basierende Wiederherstellungs-Hashberechnung ermöglicht. Daten wie Verzeichnisbaum separat als Backup gespeichert). Aber ehrlich gesagt glaube ich nicht, dass Sie mit PAR2 an Geschwindigkeit gewinnen werden, und Sie werden viel an Redundanz verlieren (das PAR2-Format basiert ebenfalls auf Reed-Solomon, hat aber viele Einschränkungen, die meine Bibliothek kennt nicht, und auch PAR2 ist irgendwie tot ...).
Sie müssen also darüber nachdenken, ob Sie mehr kosten müssen, um Daten zu kopieren (Speicherplatz) oder einen ecc-Hash (CPU-Zeit und Stromverbrauch) zu berechnen. In Bezug auf den Speicher kann der ecc-Hash eine beliebige Größe haben, aber normalerweise sind 20% - 30% eine Menge Schutz (optische Discs haben nur ~ 5%, Festplatten haben weniger und funktionieren bereits sehr gut!) .
Wenn Sie die Duplizierung als Alternative überdenken, können Sie auch Ihre Daten korrigieren, wenn Sie sicherstellen, dass Sie mindestens 3 Kopien Ihres Archivs erstellen. Sie können dann eine bitweise Mehrheit für die Wiederherstellung der Datenkorruption verwenden (pyFileFixity stellt dazu ein Python-Skript bereit: replication_repair.py). Dies ist nicht so belastbar wie ein ecc-Code, auch wenn die Ausfallsicherheitsrate gleich ist: 3 Kopien geben Ihnen eine Ausfallsicherheitsrate von 33% (dh 2 redundante Kopien von 3 geteilt durch 2, dies ist die theoretische Grenze), aber das FensterDer Schutz ist nur 1 Byte "ecc" (eher "Spare Byte") für 3 Bytes, während bei einem echten Ecc-Code mit pyFileFixity oder PAR2 das Fenster bis zu 255 Bytes umfasst: Sie schützen 255 Bytes, indem Sie 168 Bytes als Ecc-Bytes zuweisen ( Sie haben also (255-168) = 87 Bytes, die durch 168 ecc-Bytes geschützt sind, zu jedem Zeitpunkt in einer beliebigen Datei. In der Tat ist die Resilienzrate = 0,5 * von ecc-Bytes, also benötigen Sie ein Verhältnis von 66% ecc-Bytes, um eine Ausfallsrate von 33% zu erhalten. Am Ende haben Sie jedoch ein Duplizierungsschema, das die doppelte Größe des Originalarchivs benötigt, um ein geschütztes Fenster von 1/3 Byte zu erhalten, während das ecc-Schema nur 0,66x zusätzlichen Speicherplatz benötigt, um ein geschütztes 87/255 Byte zu erreichen. Intuitiv bedeutet das:
- Wenn beim Duplikationsschema mehr als 1 Byte beschädigt ist, geht das Byte verloren.
- Für das ecc-Schema müssen Sie jedoch mehr als 87 Bytes hintereinander beschädigt bekommen, um sie zu verlieren. Wenn die beschädigten Bytes über das gesamte Archiv verteilt sind, ist dies kein Problem, da die Beschränkung auf 87 Bytes pro Fenster auf 255 aufeinanderfolgende Bytes beschränkt ist.
Zusammenfassend sind ecc-Schemata fast immer zuverlässiger, weil sie eine größere Fenstergröße haben . Die Duplizierung ist jedoch der schnellste und in der Regel billigste Weg, um Dateikorrekturen durchzuführen (da Speicherplatz heutzutage billig ist).