Bitfehler verhindern: Cloudspeicher?

C

Caspian DeConwy

Gast
Hi,

Ich habe einige sehr alte Videos aus den "Anfängen" des Internets (als 320x240 Pixel noch annehmbar waren ;)).

Leider sind einige davon teilweise kaputt oder lassen sich gar nicht abspielen. Ich nehme an, dass es sich hier um Bitfehler*/gekippte Bits handelt, die durch x-faches Verschieben im Laufe der Jahre entstanden sind.

Wie kann man so etwas verhindern, wenn man in seinem Desktoprechner keine ECC-Komponenten o.ä. verbaut hat?

Ich dachte mir nun, dass man bzgl. o.g. Fehler doch gefeit sein müsste, wenn man seine Daten in der Cloud speichert. Denn bei bekannten Anbietern (Dropbox, OneDrive, Google Drive, ...) - oder mehr oder weniger bei jedem Server - sollten die Server doch entsprechend ausgerüstet sein!?

Ansonsten fielen mir als Alternative für privat nur optische Datenträger ein.


*) entstehen solche Fehler nur beim Verschieben/Kopieren, oder können Daten auch durch "Rumliegen" kaputt gehen?
 
Bitfehler bei der Übertragung sind unwahrscheinlich. Ich denke eher dass ein Medium auf dem die Daten gespeichert waren, nicht mehr zuverlässig gespeichert hat/lesen konnte.
 
Caspian DeConwy schrieb:
*) entstehen solche Fehler nur beim Verschieben/Kopieren, oder können Daten auch durch "Rumliegen" kaputt gehen?

eher genau umgedreht ...

Verschieben Kopieren = CRC Check = Kopie = Original

Rumliegen = Datenträger kann über die Zeit kaputt gehen.
 
Kannst ein anderes Filesystem verwenden.
zB zfs oder mit snapraid werden Parity Informationen angelegt womit du dann die Daten regelmäßig überprüfen kannst und je nach deinen Einstellungen auch reparieren.
 
D.h. dass ich da aber selbst aktiv werden müsste und wenn ich zu lange warte, ist es evtl irreparabel? Das ist ja auch nicht das gelbe vom Ei 🥴
 
Als Langzeitsicherung gibt es eigentlich nur M-DISC. Wenn man mal länger als 10 Jahre ins Visier nimmt
 
Rar Archiv mit Reparatur Daten
 
Caspian DeConwy schrieb:
Wie kann man so etwas verhindern, wenn man in seinem Desktoprechner keine ECC-Komponenten o.ä. verbaut hat?
Indem man den Rechner wechselt und einen nimmt der ECC RAM hat und wo natürlich auch die CPU und das Board die ECC RAM Funktion unterstützen, da sonst die 8 zusätzlichen Bits sinnlos in der Luft hängen, ECC RAM unterscheidet sich von dem ohne ECC nämlich nur in der Datenbreite von 72 statt 64 Bit, die ECC Funktion ist dann im RAM Controller und nutzt die zusätzlichen Bits für Code zu ECC.
Gee858eeG schrieb:
Bitfehler bei der Übertragung sind unwahrscheinlich.
Eben, denn seit Ultra-DMA eingeführt wurde gibt es dort und auch bei SATA eine CRC32 für jedes übertragene Paket (FIS) und ein Datenpaket kann bis zu 8192 Byte Nutzdaten übertragen. Bei einer CRC32 über 8k bleiben Fehler mit einer Wahrscheinlichkeit von irgendwas um die 1:10^46 unerkannt, was mal 8k dann ein Datenvolumen ergibt, welches das aller je gebauten HDDs und SSDs immer noch im Zehnerpotenzen übersteigt.
Gee858eeG schrieb:
Ich denke eher dass ein Medium auf dem die Daten gespeichert waren, nicht mehr zuverlässig gespeichert hat/lesen konnte.
Wobei HDDs hinter jedem physikalischem Sektor eine ECC haben, ebenso wie SSDs für jede NAND Page. Wenn diese nicht reicht um Bitfehler zu korrigieren, dann liefern HDDs oder SSD einen Lesefehler, aber keine korrupten Daten, jedenfalls nicht die üblichen Consumer SATA Platten. Es gibt Ausnahmen bei den ATA Streamingbefehlen für Surveillance HDDs, die aber von Windows nicht verwendet werden, sondern nur von Systemen für Echtzeitvideoaufzeichnungen, also vor allem Überwachungskameras oder bei SAS, wenn die Platten statt mit 512 Byte pro Sektor auf 520 oder 528 Byte Sektoren formatiert werden, denn dann legt der Controller dort selbst einen ECC Code ab um Fehler selbst zu erkennen, was man macht um Verzögerungen zu vermeiden die durch die wiederholten Versuche der Platten die Daten doch noch korrekt zu lesen, entstehen.

Korrupte Dateien können also entweder von FW Bug der Platte oder des Host Controllers kommen, ggf. auf durch Fehler auf deren internen Datenpfaden (wobei gute HDDs und SSDs einen Schutz davor haben), wahrscheinlicher sind aber durch RAM Fehler des Rechners oder Fehler der Software beim Umgang mit Dateien bei denen eben beim lesen ein Lesefehler aufgetreten ist. Wenn Dateien kopiert werden und dabei ein Lesefehler auftritt und die Software den ignoriert statt die Kopie zu löschen, dann ist diese Kopie natürlich auch korrupt.
 
Eh, bit rot interessiert sich einen Keks für ECC. Daten verfallen nun mal nach einer Weile und wenn mehr als nur zwei bit vergammelt sind, dann hilft auch kein ECC.

Zfs und Ähnliches sind schon guter Ansatz, denn da hängen Prüfsummen nach sha256 dran, wenn da was fehlert, dann hört man davon.

Aber auch zfs & co funktionieren NUR in diesem Sinne wie erwarte, wenn

— man mehr als eine Platte redundant verbindet
— man regelmäßig Checks durchführt. Dabei werden alle Daten gelesen und Prüfsummen validiert und wenn Fehler gefunden werden, können diese aus der vorhandenen Redundanz restauriert werden.

Tut man das nicht, können auch zfs&co nur sehr bedingt helfen.
 
RalphS schrieb:
Eh, bit rot interessiert sich einen Keks für ECC.
So ein Quatsch, ECC steht für Error Correction Code und der dient gerade dazu Bitfehler zu erkennen und zu beheben, also bit rot zu verhindern. Wenn du damit ECC RAM meinst, so sollte klar sein, dass alle Daten immer irgendwann im RAM stehen und ohne ECC RAM kann man RAM Fehler nie als solche erkennen, sondern sieht nur die Folgen.
RalphS schrieb:
Daten verfallen nun mal nach einer Weile und wenn mehr als nur zwei bit vergammelt sind, dann hilft auch kein ECC.
Wo sollen denn bitte genau die "Daten verfallen"? HDDs und SSDs haben wie gesagt eine ECC hinter jedem Sektor / jeder Page, die reicht um die allermeisten Bitfehler des Mediums zu korrigieren und den Rest fast ohne Ausnahmen zu erkennen und dann geben sie eben wie gesagt keine korrupten Daten sondern einen Lesefehler als Antwort. Laber bitte nicht so viel Müll, wenn du keine Ahnung und nur mal irgendwo was gelesen hast.

Erst vor kurzem hatte ich doch erst auf diesen Kommentar von dir:
RalphS schrieb:
Abgesehen davon, daß Surveillance Platten im Zweifel Daten verwerfen... kann man die sicher im Datengrab verbauen. Wenn einem seine Daten egal sind.
Eine Antwort gegeben:
Holt schrieb:
Aber nur, wenn die besonderen ATA Streamingbefehle für Echtzeitvideoaufzeichnung verwendet werden, da hat jeder Befehl einen eigenen Timeout und im Zweifel stört es die Videowiedergabe weniger, wenn fehlerhafte Daten kommen als gar keine. Die HDDs wird also bis zu dem jeweiligen Timeout versuchen die Daten korrekt zu lesen und im Zweifel dann auch korrupte Daten liefern, bevor der Timeout abgelaufen ist. Aber eben nur bei Nutzung der besonderen Befehle für Echtzeitvideoaufzeichnung, nicht wenn sie ganz normal als Datenlaufwerk genutzt wird, wie es ein Windows PC macht und auch ein NAS machen dürfte, wenn es nicht für Aufzeichnung der Videos von (Sicheheits-)Kameras genutzt wird, denn dafür sind diese Surveillance Platten eigentlich gedacht.
 
Zurück
Oben