Hallo ich benutze W7 64bit und speichere meine Daten u.A. auf einem linux NAS Kann ich davon ausgehen, dass wenn Daten auch 10mal hin und her geschoben werden, sie immer noch bitgleich sind? Bzw. würde ich beim Verschieben eine Fehlermeldung erhalten, wenn die verschobene Datei nicht mehr zu 100% der ursprünglichen entspricht?
Ich habe diesen Thread mal abonniert, bin gespannt auf die Antworten. Ich kenne Fotografen, die ihre Bilder von einer Speicherkarte auf eine HDD kopieren und beim Vergleich mit TotalCommander Unterschiede feststellen und dann nochmal kopieren, bis alles gleich ist.
Wenn du von den Dateisystem-Metadaten absiehst und keine dummen Sachen machst wie über FTP im nicht-Binary-Mode zu kopieren, ja. Außer auf der Platte sind irgendwie kaputte Sektoren oder so.
Der binäre Inhalt der Datei ist immer gleich. Jedoch gibt es Dateisystem-Spezifischen Rechte welche sich unterscheiden nach dem Kopiervorgang unterscheiden können. Aus den Analog-Zeiten sind wir raus wo jede Kopie noch verlustbehaftet war.
Wenn beim Dateien kopieren so viele Fehler passieren würden, würde sich keine Datei mehr öffnen lassen, denn ein einziges kaputtes Bit in einem "nicht-trivalen" Format wie .jpeg , .exe , .doc ... würde die Datei unbrauchbar machen. Daher werden beim kopieren/downloaden/... zB Checksums verwendet, um eine korrekte Übertragung zu gewährleisten.
Nö, stimmt nicht. Beim Herunterladen schon gar nicht, und beim Kopieren nur bei einigen wenigen ganz modernen Dateisystemen wie btrfs. Der übliche Kram wie ext oder ntfs rechnet keine Prüfsummen, gar nicht, nie.
Sven B. schrieb: > Der übliche Kram wie ext oder ntfs rechnet keine Prüfsummen, gar nicht, > nie. Aber die Platten machen das. Die Elektronik ist zuverlässig genug, dass das nicht alle Nasen lang schief geht.
Uhu Uhuhu schrieb: > Sven B. schrieb: >> Der übliche Kram wie ext oder ntfs rechnet keine Prüfsummen, gar nicht, >> nie. > > Aber die Platten machen das. Die Elektronik ist zuverlässig genug, dass > das nicht alle Nasen lang schief geht. Aber nicht so zuverlässig, daß es nie niemals nicht passieren kann. Und Rechner haben auch RAM-Speicher, durch den die Daten gehen, wenn z.B. als Festplattencache benutzt. Wenn der Speicher einen Fehler hat, kann die Festplatten-Elektronik dagegen auch nichts mehr machen.
Es gibt viele Stellen an denen Bitfehler passieren koennrn. Am haeufigsten sind das lange, schnelle Uebertragungsstrecken, zB das Internet. Deshalb werden dort auf der Bitsicherungsschicht in der Tat Pruefsummen verwendet, siehe Ethernet. Was auch passieren kann sind Probleme mit Speicher, daher gibt es ECC RAM (v.A. in Servern und Workstations) und Pruefsummen im Flash Chip/HDD Controller. Wenn bei deinen bekannten haeufig Bitfehler vorkommen kann das an defektem Arbeitsspeicher liegen, vielleicht mal in die Richtung suchen?
Ich habe auch schon mal einen Fall erlebt, wo ein Haarriss in einer Leiterbahn zwischen Festplattencontroller und CPU für interessante Bitfehler gesorgt hat, deren Häufigkeit von der Temperatur im Gehäuse abgehangen hat ... Wow, wir haben damals echt lange gesucht, bis wir das rausgefunden hatten.
Highway Crossin Frog schrieb: > sie immer noch bitgleich sind? Bei Dateisystemen, die die Länge der Datei bytegenau festhalten (es gab auch mal andere, z.B. CP/M), muss auch der Inhalt exakt übereinstimmen. Auf dem Massenspeicher, z.B. Festplatte, wird gegen Fehler mit CRC gesichert, auf den Übetragungsstrecken, z.B. Ethernet, ebenfalls. Das funktioniert sehr zuverlässig zumindest in dem Sinn, dass Fehler erkannt und gemeldet werden. Natürlich kann die Datei auf der Festplatte nach dem Kopieren fehlerhaft werden (wird erkannt) oder es tritt ein Fehler im RAM-Speicher auf - der wird leider nicht sicher erkannt, da nur Server mit CRC ausgestattet sind. Hat man öfter mal unerklärliche Fehler, so sollte man als erstes eine Memtest-Boot-CD erstellen und mal ein paar Stunden laufen lassen - hat bei mir beim Backup auftretende Fehler beseitigt (nach dem Austausch des fehlerhaften Speichers natürlich). Georg
Georg schrieb: > Natürlich kann die Datei auf der Festplatte nach dem Kopieren fehlerhaft > werden (wird erkannt) von wem soll das denn erkannt werden? Aus den Grund wurde bei einigen Filesystem ja erst eine Prüfsumme eingebaut, weil es nicht erkannt wurde. http://en.wikipedia.org/wiki/Comparison_of_file_systems
Beim TotalCommander kann man für das sichere Kopieren oder Verschieben von Dateien einfach ein Häkchen bei Verifizieren setzen. Dann wird gleichzeitig immer ein CRC-Check ausgeführt. http://www.chip.de/downloads/Total-Commander_12992663.html Die Shareware läuft ohne Einschränkungen mit einem NagScreen beim Start auch Nicht Registriert im ewigen Testmodus über die 30 Tage weiter. ;)
prg schrieb: > Beim TotalCommander kann man für das sichere Kopieren oder Verschieben > von Dateien einfach ein Häkchen bei Verifizieren setzen. Dann wird > gleichzeitig immer ein CRC-Check ausgeführt. bringt aber nichts, wenn die Festplatte schon das falsche liefert. Damit kann man nur sicherstellen, das das geschrieben identisch mit den gelesenen ist. Aber nicht das das gelesene auch stimmt.
Aber so geht es: Torsten C. schrieb: > … und beim Vergleich mit TotalCommander Unterschiede > feststellen und dann nochmal kopieren, bis alles gleich ist.
Peter II (Gast) schrieb: prg schrieb: >> Beim TotalCommander kann man für das sichere Kopieren oder Verschieben >> von Dateien einfach ein Häkchen bei Verifizieren setzen. Dann wird >> gleichzeitig immer ein CRC-Check ausgeführt. > bringt aber nichts, wenn die Festplatte schon das falsche liefert. Damit > kann man nur sicherstellen, das das geschrieben identisch mit den > gelesenen ist. Aber nicht das das gelesene auch stimmt. Der Einwand ist aber Käse. Es gilt sicherzustellen, dass das die Kopie mit dem Original übereinstimmt und GENAU DAS wird damit gewährleistet. Wenn du natürlich bereits deinem Original nicht traust ist sowieso alles zu spät. Nur wie soll ich mir das jetzt vorstellen? Was kann deine PC HW dafür, wenn bereits das zu kopierende Bild auf der Speicherkarte fehlerhaft sein soll? Dann hast du ein Problem mit deiner CAM und nicht mit dem PC.
Schon die Quelldatei kann halt fehlerhaft sein (Stichwort "bitrot"). Das kann man nur erkennen durch Dateisysteme mit Prüfsummen (btrfs) und nur korrigieren durch Dateisysteme mit Prüfsummen und Redundanz (btrfs raid). Sicher dass drehender Rost-Platten Prüfsummen rechnen? Das wäre mir neu. Habt ihr dafür eine Quelle? Die Daten werden mit irgendwie 8 "bit pro bit" redundant gespeichert, also es entspricht nicht jeder physikalische Speicherbereich einem Bit, aber Prüfsummen gibt's da meines Wissens keine. Grüße, Sven
prg schrieb: > Der Einwand ist aber Käse. Es gilt sicherzustellen, dass das die Kopie > mit dem Original übereinstimmt und GENAU DAS wird damit gewährleistet. nein wird es nicht, wenn du schon das Original nicht sauber lesen kannst. > Nur wie soll ich mir das jetzt vorstellen? Was kann deine PC HW > dafür, wenn bereits das zu kopierende Bild auf der Speicherkarte > fehlerhaft sein soll? und was ist wenn die Festplatte oder Speicherkarte fehlerhafte Daten liefert? > Dann hast du ein Problem mit deiner CAM und nicht mit dem PC. es kann beides sein, im das Problem sicher zu lösen, müsste man bei ersten erzeugen einer Datei gleich die Prüfsumme mit wegschreiben. Nur so kann man sicherstellen, das sie nie etwas ändert.
Aus dem Grunde benutze ich unter Windows noch häufig den xcopy /v Befehl, weil damit jede geschriebene Datei mit der Ursprungdatei verglichen wird. Macht das der normale Windows Drag-n-Drop-Kopiervorgang auch ? prg schrieb: > Beim TotalCommander kann man für das sichere Kopieren oder Verschieben > von Dateien einfach ein Häkchen bei Verifizieren setzen. Dann wird > gleichzeitig immer ein CRC-Check ausgeführt.
Ich denke man kann davon ausgehen dass die Standardtools mit den Standard-Optionen (cp, xcopy, $Standard-Dateimanager ...) nie Vergleiche / Prüfsummen machen, einfach weil das doppelt so lange dauert.
Peter II (Gast) schrieb: prg schrieb: >> Der Einwand ist aber Käse. Es gilt sicherzustellen, dass das die Kopie >> mit dem Original übereinstimmt und GENAU DAS wird damit gewährleistet. > nein wird es nicht, wenn du schon das Original nicht sauber lesen > kannst. Dazu hast du mehrere Möglichkeiten. Zum einen über die CAM per USB-Kabel und zum anderen durch externes Auslesen der Speicherkarte mittels einer unzähligen CARD-Reader. Das beides dir falsche Dateien beim Lesen liefert kommt bei dir wo vor? > Dann hast du ein Problem mit deiner CAM und nicht mit dem PC. > es kann beides sein, im das Problem sicher zu lösen, müsste man bei > ersten erzeugen einer Datei gleich die Prüfsumme mit wegschreiben. Nur > so kann man sicherstellen, das sie nie etwas ändert. Das ERSTE Erzeugen der Datei geschieht in der CAM. Was soll daran fehlerhaft sein, solange deine CAD nicht kaputt ist?
Matthias (Gast) schrieb: > Aus dem Grunde benutze ich unter Windows noch häufig den xcopy /v > Befehl, weil damit jede geschriebene Datei mit der Ursprungdatei > verglichen wird. Wäre mir viel zu unbequem. Zu Win9x Zeiten wo die DOSShell noch öfter wichtig war habe ich das auch so gemacht. Mit so einem Commander lässt sich ein Verzeichnisvergleich/Synchronisierung viel übersichtlicher und einfacher bewerkstelligen. > Macht das der normale Windows Drag-n-Drop-Kopiervorgang auch ? Checksummen überprüfen? Eher nicht .. Vielleicht mit Zusatzsoftware. Gibt ja nahezu für alles irgendwelche netten Tools.
> Das ERSTE Erzeugen der Datei geschieht in der CAM. Was soll daran > fehlerhaft sein, solange deine CAD nicht kaputt ist? arrg "CAD" .. CAM latürnich. ;)
Das Problem mit fehlerhaft kopierten Dateien gab es früher mal bei AMD Board aufgrund eines HW-Fehlers in der Southbridge eines bestimmten Chipsatzes. Das trat aber nur bei heftigem Datenverkehr (hoher Auslastung) auf. Wurde durch eine Änderung der Chipsatztreiber dann behoben.
Bei jedem hin und herschieben werden einzelne Bits abgerieben. Je nach Material der Festplatten, Kabel,... ist die Abnutzung schneller oder langsamer. Um dem gegenzuwirken gibt es spezielle Bitgleitmittel damit die Bits besser durchflutschen und nicht abgehobelt werden. Abgehobelte Bits können auch die Leitungen verstopfen, deshalb wird die Übertragungsgeschwindigkeit mit der Zeit auch langsamer. Hier hilft ab und an die Leitungen zu putzen dafür gibt es spezielle Kabelreiniger, Ultraschallrüttler wo man das ganze Gerät reinstellt und die Bits rausgerüttelt werden.
Peter II schrieb: > von wem soll das denn erkannt werden? Aus den Grund wurde bei einigen > Filesystem ja erst eine Prüfsumme eingebaut, weil es nicht erkannt > wurde. Von der Platte - die meldet einen Bad Sector.
prg schrieb: > Das ERSTE Erzeugen der Datei geschieht in der CAM. Was soll daran > fehlerhaft sein, solange deine CAD nicht kaputt ist? das schreiben auf dem Flash? Auch diese haben eine Fehlerquote! > Dazu hast du mehrere Möglichkeiten. Zum einen über die CAM per USB-Kabel > und zum anderen durch externes Auslesen der Speicherkarte mittels einer > unzähligen CARD-Reader. Das beides dir falsche Dateien beim Lesen > liefert kommt bei dir wo vor? wenn der Flash fehlerhaft arbeitet, liefert beide das gleiche falsche Ergebnis. Bei (sterbenden) Festplatte kommt es vor, das man sie ohne Fehler auslesen kann, aber die Daten am ende falsch sind. Und ja größer die Festplatten werden desto höher ist die Wahrscheinlichkeit das Fehler nicht bemerkt werden.
Uhu Uhuhu schrieb: > Von der Platte - die meldet einen Bad Sector. nein leider nicht immer. Das bit kann auch im Ram vom Festplattencontroller umkippen.
Uhu Uhuhu schrieb: > Von der Platte - die meldet einen Bad Sector. das macht sie aber nur wenn die CRC nicht stimmt, leider erkennt man mit der CRC nur 1 oder 2 bit Fehler. Wenn ein paar mehr bits falsch sind, kann die CRC wieder stimmen. Man müsste einen Hash verwenden und das Problem weiter zu minimieren.
Peter II (Gast) schrieb: prg schrieb: >> Das ERSTE Erzeugen der Datei geschieht in der CAM. Was soll daran >> fehlerhaft sein, solange deine CAD nicht kaputt ist? > das schreiben auf dem Flash? Auch diese haben eine Fehlerquote! Für meine Begriffe theoretisierst du hier zu viel. Schlechte Aufnahmen entstehen i.a. nicht durch die Kamera, sondern durch den der auf den Auslöser drückt. >> Dazu hast du mehrere Möglichkeiten. Zum einen über die CAM per USB-Kabel >> und zum anderen durch externes Auslesen der Speicherkarte mittels einer >> unzähligen CARD-Reader. Das beides dir falsche Dateien beim Lesen >> liefert kommt bei dir wo vor? > wenn der Flash fehlerhaft arbeitet, liefert beide das gleiche falsche > Ergebnis. Wenn, wenn, wenn. Wenn die Katze ein Pferd wäre, könnte sie die Bäume raufreiten. Dann kauf dir eine anständige Flashkarte und nicht den billigsten Mist per Paypal beim Chinamann für 1 Euro. > Bei (sterbenden) Festplatte kommt es vor, das man sie ohne Fehler > auslesen kann, aber die Daten am ende falsch sind. Kauf dir rechtzeitig eine neue Platte und gut ist. Entweder man traut seiner HW oder man holt sich besser neue.
Peter II (Gast) schrieb: > das macht sie aber nur wenn die CRC nicht stimmt, leider erkennt man mit > der CRC nur 1 oder 2 bit Fehler. Wenn ein paar mehr bits falsch sind, > kann die CRC wieder stimmen. > Man müsste einen Hash verwenden und das Problem weiter zu minimieren. Wenn du so misstrauisch bist lass dir halt md5 oder sha Prüfsummen von all deinen Dateien generieren und bewahre die irgendwo mehrfach redundant auf. Das hilft gegen Bitparanoia bestimmt.
prg schrieb: > Kauf dir rechtzeitig eine neue Platte und gut ist. Entweder man traut > seiner HW oder man holt sich besser neue. Diese Sichtweise ist Unsinn. Auch gute Hardware kann jederzeit auf unerwartete Weise kaputt gehen. "Ich kaufe die zweitbilligste SD-Karte und werde deshalb nie Probleme mit schleichendem Datenverlust haben" ist nicht die Wahrheit.
Peter II schrieb: > das macht sie aber nur wenn die CRC nicht stimmt, leider erkennt man mit > der CRC nur 1 oder 2 bit Fehler. Wenn ein paar mehr bits falsch sind, > kann die CRC wieder stimmen. Das ist ein wenig mehr als bloss eine CRC für 1-Bit Fehler am Werk.
Sven B. (scummos) schrieb: prg schrieb: >> Kauf dir rechtzeitig eine neue Platte und gut ist. Entweder man traut >> seiner HW oder man holt sich besser neue. > Diese Sichtweise ist Unsinn. Nö. > Auch gute Hardware kann jederzeit auf > unerwartete Weise kaputt gehen. Morgen kann dich ein Erdbeben verschlingen oder ein Eisbrocken fällt dir aufs Hirn. Nur wie wahrscheinlich wird das wohl sein? > "Ich kaufe die zweitbilligste SD-Karte > und werde deshalb nie Probleme mit schleichendem Datenverlust haben" ist > nicht die Wahrheit. Wenn du unter "schleichendem Datenverlust" leidest solltest du mal deine HW erneuern.
prg schrieb: > lass dir halt md5 oder sha Prüfsummen von > all deinen Dateien generieren So mache ich das z.B., damit ich im Zweifelsfall von zwei unterschiedlichen backups noch das Original identifizieren kann: 'ne XML-Datei als "Sidecar" in jedem Verzeichnis. Klar, kann auch beim erstenLesen schon ein Fehler drin sein. Aber oft hilft mehrfach lesen und eine "Mehrheitsentscheidung". "Schlechte Aufnahmen entstehen i.a. nicht durch die Kamera" und "spezielle Bitgleitmittel" sind ja mal cool. :-)
:
Bearbeitet durch User
Sven B. (scummos) schrieb: > Auch gute Hardware kann jederzeit auf > unerwartete Weise kaputt gehen. Im übrigen hat man für solche Krisenherde ein Gegenmittel schon längst erfunden. Das nennt sich Daten-Backup. Schon mal gehört?
Das Backup bringt dir gar nix, wenn du es beim letzten Erneuern mit kaputten Daten überschrieben hast ohne es zu merken. https://en.wikipedia.org/wiki/Data_corruption#Silent_data_corruption
prg schrieb: > Wenn, wenn, wenn. Wenn die Katze ein Pferd wäre, könnte sie die Bäume > raufreiten. oder man kennt das Risiko und entscheidet selber wie man damit umgeht. Du ignorierst es. http://www.it-administrator.de/themen/storage/fachartikel/111409.html http://en.wikipedia.org/wiki/Data_corruption
A. K. schrieb: > Das ist ein wenig mehr als bloss eine CRC für 1-Bit Fehler am Werk. aber auch das hilft nicht. http://en.wikipedia.org/wiki/Data_corruption [...] As another example, a real-life study performed by NetApp on more than 1.5 million HDDs over 41 months found more than 400,000 silent data corruptions, out of which more than 30,000 were not detected [...]
prg schrieb: > Wenn du unter "schleichendem Datenverlust" leidest solltest du mal deine > HW erneuern. und woran merkt man den "schleichendem Datenverlust"? Schaust du dir jeden Tag alles Bilder und Filme auf der Festplatte an um nach defekten bits zu suchen?
Sven B. (scummos) schrieb: > Das Backup bringt dir gar nix, wenn du es beim letzten Erneuern mit > kaputten Daten überschrieben hast ohne es zu merken. Und das kommt bei dir wie oft vor? Hortest du Abschusscodes für Nukleare Sprengsätze oder sonst irgendwelche für die Menschheit überlebenswichtige Datensätze? Die solltest du vom Beginn der Erzeugung an mehrfach redundant in geschützten Räumen aufbewahren und gleichzeitig in die Cloud hinterlegen, aber nicht ohne den ALLEINIGEN Zugriff darauf NUR VON DIR SICHERSTELLEN zu können. Ich fürchte nur an diesem Problem wirst du verzweifeln. Am besten trennst du dich von all deiner Technik. Die ist nicht sicher in den Griff zu kriegen. Never!
Anhand von den Beispielen in dem Wiki-Ausschnitt kann man abschätzen, dass es sehr wahrscheinlich ist, dass jeder von uns auf seiner Festplatte solche Fehler hat. Meist sind die halt an Stellen wo man es nie merkt. Wie gesagt schaust du dir ja nicht jeden Tag jedes einzelne Bild auf deiner Platte an. Und ja, ich hatte schon z.B. JPEG-Bilder die jahrelang in einem Ordner lagen und dann plötzlich halb grün waren. Was du da sagst bedeutet im Endeffekt "mir sind meine Daten nicht wichtig genug um mich mit dieser Problemstellung auseinanderzusetzen". Das ist okay. Was halt nicht okay ist ist so zu tun als ob das Problem nicht existiert.
:
Bearbeitet durch User
Peter II (Gast) schrieb: > und woran merkt man den "schleichendem Datenverlust"? Wenn du einen "schleichenden Datenverlust" bereits annimmst wirst du wohl auch einen hinreichenden Grund dafür haben oder? > Schaust du dir > jeden Tag alles Bilder und Filme auf der Festplatte an um nach defekten > bits zu suchen? Nö. Ich leide nicht unter Paranoia. Ich war selber mal betroffener vom AMD South Chip Bug beim VIA 686B Chipsatz (das Board habe ich noch). Da hatte ich diese Einstellung eine Zeitlang. Der Fehler zeigte sich aber nur sporadisch, jedoch konnte ich ihn reproduzieren bei künstlich hoher Auslastung. Das mit der "Paranoia" legte sich aber zum Glück wieder. Meine >10 Jahre alten Bilder auf der FP sehen noch genauso aus wie früher. Die Filmchen von damals laufen auch noch, sind aber vereinzelt in der Qualität inzwischen nicht mehr zeitgemäß (noch einiges per avi-Capturing in VGA mit damals vergleichsweise schwachbrüstigem Rechner) und somit eher für die Tonne bzw. nostalgisch.
prg schrieb: > Peter II (Gast) schrieb: > >> und woran merkt man den "schleichendem Datenverlust"? > > Wenn du einen "schleichenden Datenverlust" bereits annimmst wirst du > wohl auch einen hinreichenden Grund dafür haben oder? Die Realität ist dass der schleichende Datenverlust immer passiert und du ihn nur meist nicht bemerkst weil du anteilig ziemlich viele Daten hast die du nie bit-genau anschaust.
Offiziell sollten sie gleich sein, da:
1. Die Daten auf einem Datenträger mit Prüfsummen gesichert sind.
2. Der Transportweg, Prinzip bedingt sehr Fehleranfällig, mit Prüfdaten
versehen ist.
3. Die Daten auf dem Ziel, ebenfalls überprüfbar sind.
Insbesondere Punkt drei beinhaltet einen ganzen Sack voll Pferdefüße.
Beispiel: Du nimmst die billigen CD's und machst einen Flotten
Heinrich (kein verify), dann kann's schon mal holprig
werden.
P.S. Der Hersteller der CD wird, falls Feststellbar, Dir natürlich
gerne einen Ersatzdatenträger liefern.
Sven B. (scummos) schrieb: > Und ja, ich hatte schon z.B. JPEG-Bilder die jahrelang in einem Ordner > lagen und dann plötzlich halb grün waren. Sowas habe ich noch nie erlebt. Wenn ein USB-Stick den Geist aufgab war darauf mehr oder weniger alles weg oder eine FP-Partition war nicht mehr lesbar mit Teildatenverlust. Aber halbgründe Bilder? Dafür hat man seine Backups auf unterschiedlichen Medien.
prg schrieb: > Aber halbgründe Bilder? Dafür hat man seine > Backups auf unterschiedlichen Medien. ... die dir aber nichts nützen, wenn du sie vor einem halben Jahr erneuert hast und der Fehler vor fünf Jahren unbemerkt aufgetreten ist. Das ist doch gerade der Punkt, um den es geht.
Peter II schrieb: > nein leider nicht immer. Immer gibts sowieso nicht. Selbst einem ECC kann in seltenen Fällen was durchflutschen. Die ganze Geschichte ist immer eine Kosten/Nutzen-Abwägung. Auf nicht völlig desolater Hardware muss man eine Datei schon sehr lange hin und her kopieren, dass sich irgend wann mal der Inhalt ändert. > Man müsste einen Hash verwenden und das Problem weiter zu minimieren. ...einem Problem, das offensichtlich keines ist.
:
Bearbeitet durch User
Sven B. (scummos) schrieb: prg schrieb: >> Peter II (Gast) schrieb: >> >>> und woran merkt man den "schleichendem Datenverlust"? >> >> Wenn du einen "schleichenden Datenverlust" bereits annimmst wirst du >> wohl auch einen hinreichenden Grund dafür haben oder? > Die Realität ist dass der schleichende Datenverlust immer passiert Ist das eine Annahme oder eine gesicherte Erkenntnis? Wenn das (d)eine gesicherte Erkenntnis ist, dann würde ich darauf mit redundanter Speicherung reagieren. > und > du ihn nur meist nicht bemerkst weil du anteilig ziemlich viele Daten > hast die du nie bit-genau anschaust. Sorry, aber Bitparanoia ist nicht mein Ding. Sven B. (scummos) schrieb: prg schrieb: >> Aber halbgründe Bilder? Dafür hat man seine >> Backups auf unterschiedlichen Medien. > ... die dir aber nichts nützen, wenn du sie vor einem halben Jahr > erneuert hast und der Fehler vor fünf Jahren unbemerkt aufgetreten ist. > Das ist doch gerade der Punkt, um den es geht. Und gerade das ist doch an den Haaren herbei konstruiert. Entspricht jedenfalls nicht meiner Erfahrung. Ich kann das Thema auch nochmals anders beleuchten. Was kümmert dich die Sorge in einer Bilddatei mit 8, 12, 16 oder gar 24 Millionen Pixel, wenn irgendwo EIN Pixel einen Bitfehler hat? Werden deine Aufnahmen dadurch unbrauchbar? Überlege mal wieviel Dateien Windows als OS permanent beackert (lesen, schreiben). Glaubst du das würde noch absturzfrei funktionieren, wenn da andauernd Bitfehler in den DLLs oder EXEs auftreten würden? Irgendwie erinnert mich das ganze hier an lustige Schulhofdiskussionen, als Ronny Reagan sein "dolles" SDI damals der Welt vorstellte. Da ging bei uns eine wilde Diskussion um Bitkipper um. Die Welt am atomaren Abgrund, weil NIEMALS sichergestellt werden kann, nicht einem zufälligen Bitkipper in der Software solcher Verteidigungssysteme anheim zu fallen. Damals hieß es pro ca. 1 Mio Bytes ein gekipptes Bit. Das blöde ist nur, wir leben immer noch. Wie das?
Uhu Uhuhu schrieb: >> Man müsste einen Hash verwenden und das Problem weiter zu minimieren. > > ...einem Problem, das offensichtlich keines ist. deswegen gibt es auch die Artikel (siehe oben) im Netzt. Auch die Macher von ZFS habe das nur als langerweile dien Prüfsumme eingebaut. Wie kannst könnt ihr nur behaupten das das Problem keines ist, aber anderseits überhaupt keine Möglichkeit habt es zu prüfen? Ja, man kann mit dem Problem leben (mache ich auch) aber man sollte wissen das es das Problem gibt. Und wenn ihr doch mal Daten über einen längen Zeitraum aufheben müsst und diese Daten 100% korrekt sein müssen, dann kostet es auch keinen Aufwand zusätzlich eine SHA1 Datei anzulegen. Und bei jeden Backup prüft man ob die Prüfsumme nicht richtig ist.
prg schrieb: > Ich kann das Thema auch nochmals anders beleuchten. Was kümmert dich die > Sorge in einer Bilddatei mit 8, 12, 16 oder gar 24 Millionen Pixel, wenn > irgendwo EIN Pixel einen Bitfehler hat? Werden deine Aufnahmen dadurch > unbrauchbar? schon mal was von Metadaten gehört? Was ist wenn das Bild auf einmal 2048pixel breiter ist? Dann ist nicht mehr erkennbar. Oder eine Zip-Datei. Ein falschen Bit und du bekommst CRC-Fehler beim entpacken und der Inhalt ist nicht mehr lesbar.
Peter II (Gast) schrieb: > Und wenn ihr doch mal Daten über einen längen Zeitraum aufheben müsst > und diese Daten 100% korrekt sein müssen, dann kostet es auch keinen > Aufwand zusätzlich eine SHA1 Datei anzulegen. Und bei jeden Backup prüft > man ob die Prüfsumme nicht richtig ist. Eben. Dann mach das doch einfach. Fass das Zeug in einem Archiv zusammen und speichere dazu die Prüfsumme ab und gut ist.
Peter II schrieb: > Und wenn ihr doch mal Daten über einen längen Zeitraum aufheben müsst > und diese Daten 100% korrekt sein müssen, dann kostet es auch keinen > Aufwand zusätzlich eine SHA1 Datei anzulegen. Und bei jeden Backup prüft > man ob die Prüfsumme nicht richtig ist. Und dann weißt du, daß dein Backup kaputt ist. Und dann? Aus dem Hash kannst du die Daten nicht wiederherstellen. Deswegen nimmt man dafür auch keinen Hash, sondern einen low density parity code oder Reed-Solomon oder ähnliches. Siehe parchive.
prg schrieb: > Eben. Dann mach das doch einfach. Fass das Zeug in einem Archiv zusammen > und speichere dazu die Prüfsumme ab und gut ist. was ich mache ist doch egal, es ging hier um die Frage ob eine Datei immer 100% korrekt kopiert wird und das ist nicht der Fall. Es gibt zu viele stellen an denen die Datei beschädigt werden kann und dafür reicht es nicht aus sie nach dem Kopieren noch einmal zu vergleichen.
Peter II (Gast) schrieb: > schon mal was von Metadaten gehört? Was ist wenn das Bild auf einmal > 2048pixel breiter ist? Dann ist nicht mehr erkennbar. Dann gibt es immer noch die Möglichkeit solche Dateien zu reparieren. Aber wieso glaubst du, dass ausgerechnet dein Bitkipper den Dateiheader betreffen muss? Das ist so wahrscheinlich wie wieviel richtige im Lotto? > Oder eine Zip-Datei. Ein falschen Bit und du bekommst CRC-Fehler beim > entpacken und der Inhalt ist nicht mehr lesbar. Na und? Du hast die Datei doch noch mindestens einmal woanders gespeichert oder etwa nicht? Ach du meinst du hättest auf zwei unterschiedlichen Medien an genau der gleichen Stelle deinen Bitkipper? Du solltest Lottoscheine ausfüllen gehen.
prg schrieb: > Ach du meinst du hättest auf zwei unterschiedlichen Medien an genau der > gleichen Stelle deinen Bitkipper? Wieso an der gleichen Stelle? Zwei unterschiedlich kaputte Dateien bringen dir auch keine heile Datei zurück. Ist aber lustig zu sehen, wie Blinde von Farbe reden. Bitkipper/Bitrot gibt es auf allen Ebenen: im RAM (viel öfter als man denken würde), auf Magnetspeichermedien, in Flash. Praktisch überall.
Angehängte Dateien:
-
lena_orig.jpg
74 KB
prg schrieb: > Sven B. (scummos) schrieb: > Ist das eine Annahme oder eine gesicherte Erkenntnis? Wenn das (d)eine > gesicherte Erkenntnis ist, dann würde ich darauf mit redundanter > Speicherung reagieren. Lies doch einfach mal den Absatz aus dem Link oben, da stehen diverse großskalige Experimente aus der echten Welt drin. Wenn man größere Datenmengen rumliegen hat, ist das eine gesicherte Erkenntnis. > Sorry, aber Bitparanoia ist nicht mein Ding. Das ist völlig ok und auch meine Auffassung als Privatperson zu dem Thema. Nur: Das ist kein hinreichender Grund um abzustreiten dass das Problem exisitiert und für manche Anwendungen auch relevant sein kann. > Und gerade das ist doch an den Haaren herbei konstruiert. Entspricht > jedenfalls nicht meiner Erfahrung. Was ist daran jetzt bitte konstruiert? Das ist einfach ein Fakt, außer du hebst wirklich sehr alte Backups auf. > Ich kann das Thema auch nochmals anders beleuchten. Was kümmert dich die > Sorge in einer Bilddatei mit 8, 12, 16 oder gar 24 Millionen Pixel, wenn > irgendwo EIN Pixel einen Bitfehler hat? Werden deine Aufnahmen dadurch > unbrauchbar? Unter Umständen ja. Der Fehler im Anhang wird durch ein einziges geflipptes Bit verursacht. > Überlege mal wieviel Dateien Windows als OS permanent beackert (lesen, > schreiben). Glaubst du das würde noch absturzfrei funktionieren, wenn da > andauernd Bitfehler in den DLLs oder EXEs auftreten würden? Das sind relativ wenige Daten verglichen mit einer 500GB Fotosammlung.
Peter II (Gast) schrieb: prg schrieb: >> Eben. Dann mach das doch einfach. Fass das Zeug in einem Archiv zusammen >> und speichere dazu die Prüfsumme ab und gut ist. > was ich mache ist doch egal, Achso, na dann. > es ging hier um die Frage ob eine Datei > immer 100% korrekt kopiert wird und das ist nicht der Fall. Doch ist es. DAS ist der Regelfall. Du erhebst eine seltene Ausnahme zum Regelfall und konstruierst daraus folglich eine Argumentationskette schlimmer annahmen. Genauso gut könnte man auf diese Art den Bundesbürgern die Gefahr schlimmer Erdbeben in Deutschland vorhalten, weil es keine ausreichenden Schutzräume für alle gibt und keiner ausschließen kann, dass nicht JEDERZEIT ein solches Erdbeben ausbrechen wird. Was glaubst du wohl warum nicht mal der KatS-Schutz sich auf so ein Gleis begibt? > Es gibt zu > viele stellen an denen die Datei beschädigt werden kann und dafür reicht > es nicht aus sie nach dem Kopieren noch einmal zu vergleichen. Doch in der Regel reicht das völlig aus.
Genau. "In der Regel". Für eine Weltraummission aber vielleicht nicht.
prg schrieb: > Dann gibt es immer noch die Möglichkeit solche Dateien zu reparieren. > Aber wieso glaubst du, dass ausgerechnet dein Bitkipper den Dateiheader > betreffen muss? Das ist so wahrscheinlich wie wieviel richtige im Lotto? genauso wie es Gewinner im Lotto gibt, gibt es "Verlierer" mit defekten Header. Blöd nur wenn man jahrelang davon nichts gemerkt hat und fleißig von den defekten Daten ein Backup gemacht hat. Und die Festplatte mit dem Backup von vor 10Jahren schon entsorgt hat.
prg schrieb: > Doch ist es. DAS ist der Regelfall. in der Regel baue ich mit dem Auto auch kein Unfall, anschnallen tut ich mich aber auch. In der Regel wird bestimmt bei dir auch nicht eingebrochen, warum schließt du deine Wohnung dann ab? In der Regel sind Atomkraftwerke sicher ...
Sven B. (scummos) schrieb:
> Das sind relativ wenige Daten verglichen mit einer 500GB Fotosammlung.
Wen interessiert denn bei einer 500 Gigabyte Fotosammlung, ob irgendwo
mal ein Bitchen nicht mehr stimmt?
Sorry, aber langsam wird's wirklich lächerlich. Glaubst du Papierfotos
halten eine Ewigkeit? Irgendwann fällt dir mal eine Kaffeetasse darüber
oder dein Lütter macht Hackfleisch aus einem deiner Bilder. So ist nun
mal das Leben. Die Erde dreht sich weiter. Wenn dir die Frau weggelaufen
ist willst du vielleicht die Hälfte deiner alten Bilder sowieso nicht
mehr sehen. So what?
Einfach mal ein bisschen realistisch bleiben und nicht soviel
herumtheoretisieren.
Liest du eigentlich was ich schreibe? Ich habe jetzt schon fünf Mal folgendes gesagt: - Für $privatperson mit $fotosammlung ist das Problem i.d.R. egal. Trotzdem kann man es in der Realität beobachten, auch wenn es meist nicht schlimm ist. Das ist meine eigene Erfahrung. - Trotzdem existiert das Problem und ich bin mir sicher dass z.B. YouTube auch über sowas nachdenken muss. Insofern verstehe ich nicht, was du für ein Problem damit hast dass hier über das Problem diskutiert wird.
:
Bearbeitet durch User
prg schrieb: > Sorry, aber langsam wird's wirklich lächerlich. Laecherlich ist nur, wie du dich voellig verrannt hast und nicht Ruhe geben kannst. Fakt ist und bleibt: Es gibt keine 100%ige Garantie und Fehler kommen in der Praxis vor. Wer sich davor schuetzen will, muss entsprechend hohen Aufwand betreiben. Ob das fuer ihn relevant ist, muss jeder Einzelne selbst entscheiden. Aber sicher nicht du fuer Andere.
prg schrieb: > Wen interessiert denn bei einer 500 Gigabyte Fotosammlung, ob irgendwo > mal ein Bitchen nicht mehr stimmt? das muss jeder für sich entscheiden, aber wenn man kein Interesse daran hat kann man sie auch gleich löschen. > Einfach mal ein bisschen realistisch bleiben und nicht soviel > herumtheoretisieren. Die Praxis hat die Fehler gezeigt nicht die Theroie! Du lebst in der Theorie und hoffst das es dich nicht trifft, obwohl die Praxis zeigt das des es bei einer gewissen Datenmenge immer auftritt.
Heinz S. schrieb: > Laecherlich ist nur, wie du dich voellig verrannt hast und nicht Ruhe > geben kannst. ACK.
Peter II schrieb: > Du lebst in der Theorie und hoffst das es dich nicht trifft, obwohl die > Praxis zeigt das des es bei einer gewissen Datenmenge immer auftritt. Nein, Theorie und Praxis stimmen da völlig überein. Im La-la-Land, wo man sich die Ohren und Augen zuhält, mag das anders sein.
Peter II (Gast) schrieb: > in der Regel baue ich mit dem Auto auch kein Unfall, anschnallen tut ich > mich aber auch. Du fährst also tatsächlich Auto, obwohl du damit tödlich verunfallen kannst. Warum? Ist dir dein Leben nichts wert? Was ist wohl wahrscheinlicher? Ein zufälliger Bitkipper in einer deiner zehntausend Bilddateien, ausgerechnet in deinem Lieblingsbild, ausgerechnet an einer kritischen Stelle im Dateiheader oder ein schlimmer Autounfall, wie er tagtäglich auf Deutschlands Straßen passiert? Tipp: Wenn du vor Bitkippern Angst hast solltest du NIE WIEDER in ein Auto einsteigen! > In der Regel wird bestimmt bei dir auch nicht eingebrochen, warum > schließt du deine Wohnung dann ab? Weil man das nun mal so macht hierzulande. In einer Hütte in Botswana wird das womöglich kulturell anders gehandhabt .. > In der Regel sind Atomkraftwerke sicher ... Bezogen auf deine angenommenen zufälligen Dateifehler aufgrund zufällig gekippter Bits scheint die Sicherheit im AKW nach allem was bekannt ist jedenfalls nicht bedroht. Da gibt es eine ganze Reihe anderer Fehler die die Sicherheit im AKW zumindest fraglich erscheinen lassen inkl. das Entsorgungsproblem des atomaren Mülls. Aber das wolltest du sicher nicht diskutieren.
Gustav schrieb: > Nein, Theorie und Praxis stimmen da völlig überein. warum wurde dann aufwendig Studien der der Praxis gemacht? Die Theorie konnte nicht vorhersehen wie sich diese Fehler Auswirken.
Peter II schrieb: > warum wurde dann aufwendig Studien der der Praxis gemacht? Die Theorie Um die Theorie zu überprüfen, konkret, die Fehlerraten. > konnte nicht vorhersehen wie sich diese Fehler Auswirken. Das ist lächerlich.
@prg Was willst du eigentlich? Es ist doch schon mit links bewiesen das in der Praxis diese Art von Fehlern vorkommen. Man kann diese Fehler ignorieren, aber zu behaupten das sie nicht vorkommen ist dumm.
Sven B. (scummos) schrieb: > Liest du eigentlich was ich schreibe? Langsam nicht mehr. Gähn! > - Für $privatperson mit $fotosammlung ist das Problem i.d.R. egal. Aha! > Trotzdem kann man es in der Realität beobachten, auch wenn es meist > nicht schlimm ist. Das ist meine eigene Erfahrung. Soll mal vorkommen. Spielt aber nicht die Rolle die du dem Thema hier beimisst. > - Trotzdem existiert das Problem und ich bin mir sicher dass z.B. > YouTube auch über sowas nachdenken muss. Insofern verstehe ich nicht, > was du für ein Problem damit hast dass hier über das Problem diskutiert > wird. Hier wird das Problem des TE diskutiert und nicht welche Probleme "YouTube" hat. Ist mir ehrlich gesagt völlig schnuppe welche Probleme einer der großen Internetfirmen mit seinen Bilddateien hat. Da habe weder ich noch du einen Einblick. Also was soll das ganze? Bleibe beim einfach Thema des TE. Heinz S. (Gast) schrieb: > Laecherlich ist nur, wie du dich voellig verrannt hast und nicht Ruhe > geben kannst. Nö. Die Paranoiker geben hier keine "Ruhe". > Fakt ist und bleibt: Es gibt keine 100%ige Garantie und > Fehler kommen in der Praxis vor. Wer sich davor schuetzen will, muss > entsprechend hohen Aufwand betreiben. Ob das fuer ihn relevant ist, muss > jeder Einzelne selbst entscheiden. Aber sicher nicht du fuer Andere. Aber auch DU nicht für mich! Aus meiner Sicht gibt es genügend andere Probleme. Wer Backups macht hat das besagte Problem nicht und wer es glaubt zu haben sollte mal über seine Datensicherheit neu nachdenken. Paranoia ist jedenfalls kein guter Ratgeber.
prg schrieb: > Aber auch DU nicht für mich! Aus meiner Sicht gibt es genügend andere > Probleme. Wer Backups macht hat das besagte Problem nicht und wer es > glaubt zu haben sollte mal über seine Datensicherheit neu nachdenken. du hast also immer noch nicht verstanden! Ein Backup von einer defekten Datei ist wertlos! Ein Backup löst das Problem also nicht!
Peter II (Gast) schrieb: > @prg > Was willst du eigentlich? Ich frage mich die ganze Zeit was DU eigentlich willst? > Es ist doch schon mit links bewiesen das in der Praxis diese Art von > Fehlern vorkommen. > Man kann diese Fehler ignorieren, aber zu behaupten das sie nicht > vorkommen ist dumm. Der Punkt ist, du überzeichnest maßlos! Ich kenne das Problem selber früher vom Southbridge Bug. DA gab es mal so ein Problem wie du das hier schilderst. Seitdem ist mir das aber nicht mehr untergekommen. Insofern habe ich im Gegensatz zu deinen theoretisierenden Annahmen damit schon mal zutun gehabt.
Peter II schrieb: > Ja, man kann mit dem Problem leben (mache ich auch) aber man sollte > wissen das es das Problem gibt. Au Mann, irgend wann wird die Welt untergehen...
prg schrieb: > Seitdem ist mir das aber nicht mehr untergekommen. wie hast du das festgestellt? Augen zu und denken alles ist ok?
Peter II (Gast) schrieb: > du hast also immer noch nicht verstanden! Ein Backup von einer defekten > Datei ist wertlos! Da musst du erstmal beweisen, dass das Backup defekt ist! > Ein Backup löst das Problem also nicht! Doch löst es. Du hast ja nicht nur EIN Backup oder? Deine Argumentation deckt sich nicht mit der Realität!
prg schrieb: > Da musst du erstmal beweisen, dass das Backup defekt ist! nein, man muss vor dem Backup prüfen ob die Daten nicht defekt sind. > Du hast ja nicht nur EIN Backup oder? Ach so, 20 Backups einer defekten Datei sind natürlich viel besser.
prg schrieb: > Deine Argumentation deckt sich nicht mit der Realität! Dann lege von jeder Datei auf deiner Festplatte eine Prüfsumme an, dann prüfst du sie in einen Jahr noch einmal. Wenn du dann keinen Fehler findest dann scheint es das Problem wirklich nicht zu gegeben. Aber solange du nichts prüfst, kann du lange behaupten das du nicht betroffen ist.
Peter II (Gast) schrieb: prg schrieb: >> Seitdem ist mir das aber nicht mehr untergekommen. > wie hast du das festgestellt? Augen zu und denken alles ist ok? Durch sporadische Dateivergleiche. Außerdem habe ich keine Bilder mit grünen Streifen oder sowas wie manch anderer hier in seinen alten Fotos bisher entdeckt. Lustigerweise ist jetzt die Argumentation wohl wieder beim privaten Dateigebrauch angekommen. Naja. Erinnert mich alles sehr an Spezies die einem einreden wollen das die Festplatte voll vor Viren sein muss, weil der Virenscanner ja NIE alle Viren findet. Ist immer das gleiche mit solchen Scheinargumenten. Irgendwas aus den Fingern saugen, dem anderen vor die Füße kippen mit dem Hinweis, nun beweise mal das Gegenteil. Solche Rituale sind hinlänglich bekannt und durchschaut.
prg schrieb: > Durch sporadische Dateivergleiche. also defekt mit defekt? Und was ist wenn die Dateien unterschiedlich sind, welche ist denn die defekte oder sind beide defekt? Genau für so etwas eine Prüfsumme erfunden. > Außerdem habe ich keine Bilder mit > grünen Streifen oder sowas wie manch anderer hier in seinen alten Fotos > bisher entdeckt. du hast selber geschrieben, das die Wahrscheinlichkeit viel höher ist das einfach nur ein Pixel falsch ist, das sieht man nicht.
Peter II (Gast) schrieb: > Dann lege von jeder Datei auf deiner Festplatte eine Prüfsumme an, dann > prüfst du sie in einen Jahr noch einmal. Die Arbeit kann ich mir sparen. Da kommt kein relevanter Informationsgehalt dabei heraus. > Wenn du dann keinen Fehler > findest dann scheint es das Problem wirklich nicht zu gegeben. Ich weiß schon was mir wichtig ist und worauf ich ein besonderes Augenmerk lege. Prüf du tagtäglich deine Bits. Ich gehe da anders vor. Ich leide nicht unter Wahrvorstellungen über plötzlich verkrüppelte Dateien. Das hatte ich alles mal beim Southbridge Bug. Never ever. Und jetzt ist mal Schluss mit den Kindereien hier. Die Bits im Rechner werden schon nervös. :-)
prg schrieb: > Die Arbeit kann ich mir sparen. Da kommt kein relevanter > Informationsgehalt dabei heraus. sehr sinnvoll, es gibt also ein Verfahren um nachzuweisen das du auch davon betroffen ist, aber du setzt es nicht ein weil du ja weist das du nicht betroffen bist. Aber du hast recht, der Informationsgehalt ist nicht relevant, weil es schon statisch sehr wahrscheinlich ist das du auch davon betroffen ist. Das muss man nicht erst nachweisen.
Da hier ja offenbar die absolute Datensicherheit gefordert wird, hier ein Vorschlag: Man nehme eine beliebige Anzahl an PCs, die jeweils ihre Daten im RAID1 (Mirroring) auf - sagen wir mal 10 - Festplatten parallel speichern. Jeder Rechner ist mit jedem Vernetzt und vergleicht seine Daten ständig mit denen der anderen. Tritt ein Fehler auf, prüft jeder PC die Stelle und es gewinnt die Mehrheit. Zur Sicherheit kann man natürlich auch noch die Leitungen zwischen den PCs redundant ausführen und die Daten mehrmals Senden. Und so wird alles immer komplizierter und irgendwer aus einem Mikrocontroller-Forum wischt all das mit den Worten "Aber was ist, wenn meine Quelldatei defekt ist?" wieder weg :-)
1 | Rezept: |
Aber auch dafür gibt es natürlich eine Lösung: Wir stellen den Originalrechner, der die Daten erzeugt, mehrfach hin. Falls er die Daten irgendwo her bekommt, stellen wir die entsprechende Datenquelle ebenfalls mehrfach zur Verfügung. Wenn diese ihre Daten wieder von irgendwo bekommt ->
1 | rjmp Rezept |
Und so haben wir schließlich ein paar Paralleluniversen auf unserer Einkaufsliste fürs Rechenzentrum stehen...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.