Müssen digitale Bilder regelmäßig bewegt werden?

[Gast Olyver]

 Panomatic said:

Die Rolle ich dann einmal pro Jahr durch der Rittersaal bei meinen Eltern. Das ändert doch nichts an der Lebensdauer? Oder?

Wie immer - kommt ganz darauf an: Wie alt sind denn Deine Eltern??? LG Olyver

[ED]

Hallo Angelika,

 photofan said:

... vor kurzem erzählte mir ein Fotograf und Grafiker, dass die digitalen Bilder regelmäßig auf den Festplatten bewegt werden müssen, damit keine Bildverluste entstehen. ...

Wie schon geschrieben, Bits bleichen nicht aus. Hier aber ein Aspekt zum Thema "Datenkorruption", den die bisherige Diskussion vermissen lässt. Das Nachfolgende lässt ist übrigens, samt den technischen Hintergründen, sehr gut in der Dokumentation der smartmontools nachzulesen. Diese Open Source Software lässt sich von heise.de für alle gängigen Betriebssysteme herunter laden. Festplatten kennen einen Fehlerzustand, der unter SMART als "pending blocks" bezeichnet wird. Einen solchen Block kann die Platte nicht mehr lesen, bzw. nicht mehr fehlerfrei lesen. Sie unternimmt aber bei Lesevorgängen kein Block Remapping, weil es ja sein könnte, dass der Block vielleicht irgendwann einmal lesbar sein könnte, wenn man es nur oft genug versucht. Spezielle Rettungssoftware tut so etwas auch typischerweise und hat damit manchmal Glück. Ein solcher "pending block" fällt im Normalbetrieb nur dann auf, wenn man die Datei liest, die diesen Block enthält. Das Betriebssystem hat von "pending blocks" keine Kenntnis. Bei Schreibvorgängen auf einen "pending block" wird dieser Block von der Platte sofort remapped, also durch einen Reserve-Block ersetzt. Auch davon bemerkt das Betriebssystem nichts. Fazit: Derartige "pending blocks" würden zwar bei einem Umkopiervorgang der Daten auffallen, aber der Inhalt dieses Blocks wäre in sehr vielen Fällen verloren, sofern nicht eine spezielle Rettungssoftware beim zehn-millionsten Leseversuch vielleicht doch noch einmal Glück hat und diesen Block wenigstens einmal lesen kann. Unter'm Strich bleibt eigentlich nur, wertvolle Daten doppelt zu sichern, bzw. die erste Sicherung zu kopieren. Um "pending blocks" frühzeitig zu erkennen und um Festplatten-Tests durchzuführen, sollte man smartmontools regelmäßig nutzen. Deren Dokumentation ist hervorragend, setzt aber ein gerüttelt Maß an IT-Hintergrund voraus und erschließt sich nicht aus der Tiefe des Gemüts. PS: Das hier Gesagte ist nur eingeschränkt auf SSDs anwendbar, da diese (eigentlich) keine "pending blocks" entwickeln können. Allerdings wird man sehr große Datenmengen ohnehin auf herkömmlichen Festplatten sichern. Gruß, ED

[ED]

Hallo,

 shoffmeister said:

.. Auch das "Bewegen der Daten" macht auf modernen (Netzwerk-)Dateisystemen exakt - nichts. Da werden nur ein paar Verzeichniseinträge hin und her geschrieben, die Nutzdaten (die Bilder) bleiben identisch. ...

Korrrekt, solange das Verschieben innerhalb eines Dateisystems passiert. Wenn Du allerdings innerhalb des gleichen Dateisystems kopierst (nicht aber "verlinkst"!), dann sieht das schon anders aus. Und sofern Du die Kopien (nicht "Links"!!!) in einem anderen Dateisystem anlegst, dann ebenfalls. Gruß, ED

[anselm]

 ED said:

Wenn Du allerdings innerhalb des gleichen Dateisystems kopierst (nicht aber "verlinkst"!), dann sieht das schon anders aus.

Sicher kann man sich da nicht sein. Moderne Dateisysteme merken sich nur, dass die Datenblöcke der ursprünglichen Datei jetzt zu zwei Dateien gehören. Erst wenn in die Datei (entweder das Original oder die Kopie) etwas Anderes geschrieben wird, werden die betroffenen Datenblöcke – und nur diese – dupliziert. (Beispiel: Man kopiert ein Foto und ändert in der Kopie irgendwas in den EXIF-Daten, vielleicht die Ausrichtung. Die resultierenden zwei Dateien teilen sich alle Datenblöcke bis auf den einen, wo die unterschiedlichen EXIF-Daten stehen.)

 ED said:

Und sofern Du die Kopien (nicht "Links"!!!) in einem anderen Dateisystem anlegst, dann ebenfalls.

Da schon eher. Viele Grüße – Anselm

[AK77]

 anselm said:

Sicher kann man sich da nicht sein. Moderne Dateisysteme merken sich nur, dass die Datenblöcke der ursprünglichen Datei jetzt zu zwei Dateien gehören. Erst wenn in die Datei (entweder das Original oder die Kopie) etwas Anderes geschrieben wird, werden die betroffenen Datenblöcke – und nur diese – dupliziert. (Beispiel: Man kopiert ein Foto und ändert in der Kopie irgendwas in den EXIF-Daten, vielleicht die Ausrichtung. Die resultierenden zwei Dateien teilen sich alle Datenblöcke bis auf den einen, wo die unterschiedlichen EXIF-Daten stehen.)

Hmm, ist das wirklich so? Ich kann's mir ehrlich gesagt nicht vorstellen, denn das würde das Ändern an einer zig-fach kopierten Datei ja total ineffizient machen. Und beim Konzept des Unix-Hardlinks ist es so, daß tatsächlich zwei Inodes auf denselben Bereich zeigen; ändert man die eine, ändert sich auch die andere Datei. André

[ED]

Hallo Anselm, vielleicht haben wir ein Terminologie-Problem, möglicherwiese auch unterschiedliche Vorstellungen davon, was ein "modernes Betriebssystem" ist. Ich möchte hier keinesfalls einen Flame War "Unix/Linux/*BSD kontra Windows" los treten und betrachte vereinfachend im Folgenden nur die Filesysteme dieser Betriebssysteme. Und ja, ich habe mehr als drei Jahrzehnte Unix im Blut und habe Interna dieser Betriebssystem-Familie hinreichend lange unterrichtet. Aber das ist ja bei Dir wohl auch ähnlich, soweit ich mich erinnere. Will heißen, ich bin sehr verwöhnt, was Filesysteme angeht, und betrachte die jenigen Filesysteme, die mir unter Windows über den Weg gelaufen sind, im Vergleich nicht als "moderne Filesysteme". Wie ich schon schrieb, unterscheide ich sehr deutlich zwischen "Kopie" und "Link" in meinen Postings.

 anselm said:

 ED said:

Wenn Du allerdings innerhalb des gleichen Dateisystems kopierst (nicht aber "verlinkst"!), dann sieht das schon anders aus.

Sicher kann man sich da nicht sein. Moderne Dateisysteme merken sich nur, dass die Datenblöcke der ursprünglichen Datei jetzt zu zwei Dateien gehören. Erst wenn in die Datei (entweder das Original oder die Kopie) etwas Anderes geschrieben wird, werden die betroffenen Datenblöcke – und nur diese – dupliziert. (Beispiel: Man kopiert ein Foto und ändert in der Kopie irgendwas in den EXIF-Daten, vielleicht die Ausrichtung. Die resultierenden zwei Dateien teilen sich alle Datenblöcke bis auf den einen, wo die unterschiedlichen EXIF-Daten stehen.)

Das wäre zunächst ein Link, also keine Kopie, plus ein "Copy on Write"-Fall. "Copy on Write" wird typischerweise nur bei sehr speziellen Filesystemen eingesetzt, wie beispielsweise bei Overlay-Filesystemen. An welches Filesystem/Betriebssystem denkst Du denn in Deinem obigen Beispiel? @André

 AK77 said:

... Und beim Konzept des Unix-Hardlinks ist es so, daß tatsächlich zwei Inodes auf denselben Bereich zeigen;

Nicht ganz korrekt, aber fast. Tatsächlich passiert folgendes: 1. Du legst die Datei "bild1.jpg" an, z.B. durch Kopieren von der Memory-Karte. Diese Datei hat genau eine Inode, den Link-Zähler "1" und es gibt nur einen einzigen Directory-Eintrag (=Namen), der auf diese Inode verweist. (In der Inode stehen u.a. Eigentümer, Zugriffsrechte, Pointer auf Datenblöcke, Link-Zähler etc.) 2. Nun legst Du einen (Hard-)Link an: ln bild1.jpg bild1a.jpg Damit erzeugst Du einen zusätzlichen Namen (=Directory-Eintrag), der auf die gleiche Inode verweist. Damit wird also keine zusätzliche Inode angelegt, sondern in der unter (1.) angelegten, bereits vorhandenen Inode wird der Link-Zähler von "1" auf "2" erhöht. Insbesondere werden auch keine neuen Datenblöcke mit Kopien der unter (1.) angelegten Daten erzeugt. Du kannst nun wahlweise mit dem Namen "bild1.jpg" oder "bild1a.jpg" auf die Daten zugreifen, denn es sind in beiden Fällen dieselben Datenblöcke.

 AK77 said:

...ändert man die eine, ändert sich auch die andere Datei.

Absolut korrekt. Siehe Punkt (2.) des obigen Beispiels. Gruß, ED

[AK77]

 ED said:

Nicht ganz korrekt, aber fast.

Du hast Recht, ein Hardlink verbraucht keinen zusätzlichen Inode. Gerade getestet. Das bedeutet, daß man noch (fast) beliebig viele Hardlinks anlegen könnte, selbst wenn alle Inodes aufgebraucht sind. War mir nicht mehr bewusst … ist aber auch schon Ewigkeiten her daß ich da mal in eine Begrenzung gelaufen bin. André

[anselm]

 ED said:

Das wäre zunächst ein Link, also keine Kopie, plus ein "Copy on Write"-Fall. "Copy on Write" wird typischerweise nur bei sehr speziellen Filesystemen eingesetzt, wie beispielsweise bei Overlay-Filesystemen. An welches Filesystem/Betriebssystem denkst Du denn in Deinem obigen Beispiel?

ZFS bei Solaris, {Free,Net}BSD oder Linux und Btrfs bei Linux arbeiten so. Beides sind sogenannte “Copy-on-Write”-Dateisysteme. Diese Arbeitsweise hat einige sehr handfeste Vorteile. Außer den beschriebenen Kopiertricks für einzelne Dateien ist es zum Beispiel sehr einfach und schnell möglich, “Schnappschüsse” einer Verzeichnishierarchie zu machen, etwa um eine Sicherheitskopie anzulegen, während gleichzeitig auf dem System weitergearbeitet wird, oder um einen kontrollierten “Rollback” einer komplizierten Softwareinstallation zu ermöglichen, die diverse Dateien anfasst. Beim Anlegen eines Schnappschusses muss nichts kopiert werden, weswegen das auch bei riesengroßen Dateibäumen in Sekundenbruchteilen geht. Tatsächlich machen die Dateisysteme eine “Deduplizierung” von Datenblöcken wahlweise auch über verschiedene Dateien hinweg, die eigentlich gar nichts miteinander zu tun haben. Wenn also zwei ansonsten voneinander völlig unabhängige Dateien Datenblöcke haben, die die gleichen Daten enthalten, kann das Dateisystem diese Datenblöcke (und nur diese) für die Zwecke der Speicherung zusammenwerfen. Das ist zum Beispiel dann nützlich, wenn man auf einem Rechner mehrere “virtuelle Maschinen” laufen läßt, die alle eine Installation des Basisbetriebssystems brauchen, die zum allergrößten Teil bei allen identisch ist, denn der dafür nötige Speicherplatz wird im Wesentlichen nur einmal belegt. Dazu kommen noch verschiedene andere nette Eigenschaften wie etwa, dass es möglich ist, mehrere physikalische Festplatten gemeinsam als eine große “logische” Platte zu behandeln, wobei das Dateisystem sich auf Wunsch darum kümmert, dass von allen Daten auf mehreren Platten eine Kopie liegt, nur falls mal eine Platte kaputtgeht. Natürlich kann man nachträglich Platten hinzufügen oder auch entfernen (etwa weil SMART einem sagt, dass eine Platte anfängt zu “schwächeln”). Prüfsummen über die Daten erlauben es, Fehler auf der Platte zu erkennen und gegebenenfalls sogar zu korrigieren. Daten können auf Wunsch transparent – also ohne dass der Anwender es sieht – komprimiert werden usw. usf. Wenn man von “klassischen” Unix- oder auch Windows-Dateisystemen kommt, wo alles ziemlich statisch ist, dann muss man sich erst mal umgewöhnen und so einiges über Bord werfen, was man lange für gegeben und unumstößlich gehalten hat. Aber es lohnt sich ;-) Viele Grüße – Anselm PS. Auf der Windows-Seite gibt es meines Wissens nach nichts Vergleichbares. Zwar hat NTFS unter anderem ein paar Copy-on-Write-Features bekommen (Stichwort “Volume Shadow Copy Service”), aber die reichen nicht an das heran, was ZFS und Btrfs zu bieten haben. Irgendwann vor Windows Vista hatte Microsoft große Pläne, die Plattenverwaltung unter dem Namen “WinFS” auf neue Füße zu stellen, aber das Projekt wurde still und leise beerdigt.

[anselm]

 AK77 said:

Ich kann's mir ehrlich gesagt nicht vorstellen, denn das würde das Ändern an einer zig-fach kopierten Datei ja total ineffizient machen.

Nicht wirklich. Wenn ein Datenblock in einer solchen Datei neu geschrieben wird, dann wird er für die neue Version kopiert (mit Änderungen) – die zig-fach kopierte Datei kann den originalen Datenblock behalten, über den das System ja weiß, dass er in zig Kopien benutzt wird. Mit anderen Worten: Wenn ich eine Datei habe und diese dann viermal kopiere, habe ich fünf Dateien, die sich hinter den Kulissen die Datenblöcke der ursprünglichen Datei teilen. (Von außen sehen sie aus wie fünf separate Dateien, aber das ist ja der gewollte Effekt. Man darf das auch nicht mit Hardlinks verwechseln – der Link-Zähler ist für jede dieser Dateien “1”.) Wenn ich jetzt die dritte Datei hernehme und das erste Zeichen des ersten Datenblocks ändere, besteht anschließend die dritte Datei aus einem neuen Datenblock am Anfang und den restlichen Datenblöcken der ersten Datei. Die anderen vier Dateien teilen sich nach wie vor alle Datenblöcke der ersten Datei. Es musste nur ein Datenblock neu geschrieben werden, nämlich der veränderte erste der dritten Datei. Das ist allemal effizienter, als wegen ein paar Bytes die komplette Datei zu kopieren (vor allem, wenn es eine große Datei war, etwa ein Hi-Res-RAW-Bild aus der Olympus E-M5 Mk II), und Plattenplatz spart es auch ganz beträchtlich. Viele Grüße – Anselm

[Jo_aus_SHG]

Um auf die Frage des TO zurückzukommen: Nimm ein kleines NAS oder einen kleinen Server mit einem RAID- Kontroller. Einfaches RAID 1 (Spiegelung) oder RAID 5 (Parity) beherrschen fast alle. Lass alle paar Wochen ein Parity-Check laufen und beobachte die SMART-Werte. Dann brauchst Du Dir keine Sorgen über kippende Bits oder defekte Sektoren machen. Gruß, Jo

[anselm]

 Jo_aus_SHG said:

Lass alle paar Wochen ein Parity-Check laufen und beobachte die SMART-Werte. Dann brauchst Du Dir keine Sorgen über kippende Bits oder defekte Sektoren machen.

Aber bitte darüber die regelmäßigen Sicherheitskopien nicht vergessen. Viele Leute denken, sie haben jetzt ein NAS mit RAID, wo alles doppelt oder dreifach abgesichert ist, und damit sind Sicherheitskopien überflüssig – aber „menschliches Versagen“ ist ein weitaus häufigerer Grund für Datenverlust als kaputte Hardware. Viele Grüße – Anselm

[Jo_aus_SHG]

 anselm said:

 Jo_aus_SHG said:

Lass alle paar Wochen ein Parity-Check laufen und beobachte die SMART-Werte. Dann brauchst Du Dir keine Sorgen über kippende Bits oder defekte Sektoren machen.

Aber bitte darüber die regelmäßigen Sicherheitskopien nicht vergessen. Viele Leute denken, sie haben jetzt ein NAS mit RAID, wo alles doppelt oder dreifach abgesichert ist, und damit sind Sicherheitskopien überflüssig – aber „menschliches Versagen“ ist ein weitaus häufigerer Grund für Datenverlust als kaputte Hardware. Viele Grüße – Anselm

Richtig! NAS verfügen in der Regel über eine vorhandene Backup-Lösung auf eine externe USB-Festplatte. Bei einem kleinen Server kann man zum Beispiel RSYNC einsetzen. Hier muss ein kleines Shell-Script erstellt und in die CRON-Tab eingetragen werden. Zu guter Letzt: Stichproben der externen Festplatte geben einem die Gewissheit, dass etwas "gesichert" wurde. ;-) Jo

[anselm]

 Jo_aus_SHG said:

Bei einem kleinen Server kann man zum Beispiel RSYNC einsetzen. Hier muss ein kleines Shell-Script erstellt und in die CRON-Tab eingetragen werden.

Automatisierung über cron ist oft eine gute Idee, gar kein Zweifel. In diesem Fall sollte man aber berücksichtigen, dass die externe Festplatte für die Sicherheitskopien nicht dauerhaft ans NAS/den Server angeschlossen sein sollte – wenn man nicht gerade eine Kopie anlegt, dann stöpselt man sie aus und hebt sie irgendwo anders auf, einfach um sicherzugehen, dass Original und Kopie gleichzeitig weder von computerbasierten Katastrophen (Verschlüsselungstrojaner oder übereifriger Lösch-Finger?) noch solchen in der wirklichen Welt (Überschwemmung, Wohnungsbrand?) in Mitleidenschaft gezogen werden können. Wer extra vorsichtig sein will, macht seine Sicherheitskopien abwechselnd auf zwei Platten und lagert immer eine davon ganz woanders (guter Freund, Eltern, Büro, Bankschließfach, …). Ein zeitgesteuerter Backup-Vorgang verbietet sich aber, wenn man vorher manuell sicherstellen muss, dass die richtige externe Platte angeschlossen ist, denn das wird leicht mal vergessen und dann können interessante und fremdartige Dinge passieren. Wo ein automatisiertes Anstoßen einer Sicherheitskopie sich eher lohnt, ist bei „Cloud-Backup“. Das macht man vermutlich am besten irgendwann tief in der Nacht, wenn die Internet-Verbindung nicht anderweitig benötigt wird, und dann ist es gut, wenn man nicht selber dran denken muss.

 Jo_aus_SHG said:

Zu guter Letzt: Stichproben der externen Festplatte geben einem die Gewissheit, dass etwas "gesichert" wurde.

What he said ;^) Wie heißt es so schön: „Keiner will Backup. Alle wollen Restore.“ Viele Grüße – Anselm

[pdi]

 zackenschaf said:

 photofan said:

[...] dass die digitalen Bilder regelmäßig auf den Festplatten bewegt werden müssen, damit keine Bildverluste entstehen.

Bei allem Respekt, aber das ist totaler Blödsinn. Man sollte Datenbackups anfertigen, ansonsten können die Daten aber gerne Jahrzehnte auf einem Dastenträger verbleiben, ohne dass es zu Verlusten kommt.

Bei allem Respekt, das ist totaler Blödsinn.Defekte Blöcke auf Festplatten sind völlig normal und eben weil Daten durch bloßes "auf der Platte liegen" beschädigt werden können gibt es viele Methoden um Daten zu rekonstruieren. Intelligente Dateisysteme wie WAFL, ZFS oder ReFS (ja, auch Windows kann das) können beim Lesen erkennen ob die Datei noch so ist wie sie einmal geschrieben wurde und sie dann beim Lesevorgang reparieren. Blockchecksumming ist eben etwas tolles. Backup hilft da auch genau nichts, weil im Zweifel kaputte Blöcke in die Datensicherung gehen. Dann ist zwar 1:1 das wiederherstellbar was auf der Platte liegt - nur was bringt es, wenn es kaputt ist? Etwas ausführlicher was alles schiefgehen kann wird es hier erklärt: An Analysis of Data Corruption in the Storage Stack Im Endeffekt ist das "immer mal wieder die Daten umkopieren" für den Hausgebrauch wohl die günstigste Alternative.

[zackenschaf]

 pdi said:

Defekte Blöcke auf Festplatten sind völlig normal und eben weil Daten durch bloßes "auf der Platte liegen" beschädigt werden können gibt es viele Methoden um Daten zu rekonstruieren.

Wow, dann muss ich eine besondere Ausnahme sein, denn in über 20 Jahren fast täglicher PC-Nutzung hatte ich - ganz ohne besondere Umkopiermaßnahmen - noch niemals ein Leseproblem bei meinen Daten. Und manche Daten schleppe ich schon seit den 90ern mit durch, von PC zu PC. :-)

 pdi said:

Backup hilft da auch genau nichts, weil im Zweifel kaputte Blöcke in die Datensicherung gehen. Dann ist zwar 1:1 das wiederherstellbar was auf der Platte liegt - nur was bringt es, wenn es kaputt ist?

Dass "kaputte Blöcke" in die Datensicherung gehen klingt absurd. Warum sollte beim Backup nicht das gesichert werden, was gelesen und ggf. korrigiert werden kann, so wie bei jedem anderen Lesevorgang auch?!

[pit-photography]

Kleiner Spaß, nicht ernst gemeint: Heute muss man eine neue Festplatte (extern) kaufen und die Bilder von der alten in die neue kopieren. Damals war das viel mühseliger: Man musste ein neues Album kaufen und die Bilder vom alten Album in das neue Album kleben. Es lebe das digitale Zeitalter ... ;-))) Gruß Pit

[Gast Olyver]

 zackenschaf said:

in über 20 Jahren fast täglicher PC-Nutzung hatte ich - ganz ohne besondere Umkopiermaßnahmen - noch niemals ein Leseproblem bei meinen Daten. Und manche Daten schleppe ich schon seit den 90ern mit durch, von PC zu PC. :-)

Äääh... - und wie genau hast Du Deine Daten dann jeweils auf einen neueren PC gebracht wenn nicht durch umkopieren? LG Olyver

[Jo_aus_SHG]

 photofan said:

[...] ... Backup hilft da auch genau nichts, weil im Zweifel kaputte Blöcke in die Datensicherung gehen. Dann ist zwar 1:1 das wiederherstellbar was auf der Platte liegt - nur was bringt es, wenn es kaputt ist?

Wir reden von Backup auf Dateiebene - Keine Kopie auf Disk-/Partitionsebene. Auf Dateiebene kann nichts defekt kopiert werden. Dafür sorgt die Festplatte unabhängig vom Filesystem. Hintergrund: Wenn eine Festplatte feststellt, dass sie mehrere Anläufe braucht, einen bestimmten Block fehlerfrei zu lesen, dann schiebt sie den Blockinhalt in einen neuen und markiert den problematischen als "Pending Sector". Erst, wenn der Block beim nächsten Schreibvorgang Zicken macht, wird er zum "Bad Sector". Bei aktuellen Festplattengrößen >1TB ist selbst ein "Bad Sector" kein Beinbruch. Wen es stört, der kann das eigenmächtige Handeln von SMART verhindern. Beispiel: Ein Stromausfall verursacht Pending Sectors. Man ermittelt deren Position und beschreibt sie mehrmals (dd, ddrescue ..). Wenn das gelingt, werden die Pending Sectors aus der SMART-Tabelle austragen. Hilfe gibt hier das Web, aber es wird sehr technisch. Wichtig ist also, das Festplatten regelmäßig gelesen werden und zwar auf üblich Art und Weise: Backup. Festplatten sind heute eher für den Dauerbetrieb 7x24h (NAS) ausgelegt als für Archivierung, wo sie dann mehrere Monate nicht ausgelesen werden. Gruß, Jo

[pdi]

 zackenschaf said:

 pdi said:

Backup hilft da auch genau nichts, weil im Zweifel kaputte Blöcke in die Datensicherung gehen. Dann ist zwar 1:1 das wiederherstellbar was auf der Platte liegt - nur was bringt es, wenn es kaputt ist?

Dass "kaputte Blöcke" in die Datensicherung gehen klingt absurd. Warum sollte beim Backup nicht das gesichert werden, was gelesen und ggf. korrigiert werden kann, so wie bei jedem anderen Lesevorgang auch?!

Nein, das ist das normalste überhaupt. "Kaputt" im Sinne von "ist nicht mehr das, was geschrieben wurde". Speichersystem-Hersteller wie EMC, NetApp, HP usw. betreiben nicht grundlos einen immensen Aufwand um Datenintegrität sicherstellen zu können - Festplatten können das nicht. In modernen Speichersystem werden Blockchecksummen genutzt um zu schauen ob die Daten noch immer die sind, die irgendwann einmal geschrieben wurden. Passt der Block nicht zur Checksumme ist er ungültig und muss neu erstellt werden aus Paritätsinformationen. Solche Überprüfungen laufen transparent, bei jedem Zugriff. Dazu bieten auf einem simpleren Level Raidcontroller auch die Möglichkeit "Patrol Reads"/"Scrubs" zu machen, d.h. Daten werden einfach in Massen gelesen und dabei auftretende Fehler aus Paritätsinformationen korrigiert. All das kann eine Festplatte allein nicht. Der verlinkte Artikel war durchaus ernst gemeint. Jeder kann Glück haben, aber sicher sind Daten die auf magnetische Medien geschrieben werden ohne zusätzlichen Schutz in Form einer intelligenten Schicht (VxVM, ReFS, WAFL, ZFS, ... gibt genug) nicht wirklich.

[pdi]

 Jo_aus_SHG said:

Wir reden von Backup auf Dateiebene - Keine Kopie auf Disk-/Partitionsebene. Auf Dateiebene kann nichts defekt kopiert werden. Dafür sorgt die Festplatte unabhängig vom Filesystem. Hintergrund: Wenn eine Festplatte feststellt, dass sie mehrere Anläufe braucht, einen bestimmten Block fehlerfrei zu lesen, dann schiebt sie den Blockinhalt in einen neuen und markiert den problematischen als "Pending Sector". Erst, wenn der Block beim nächsten Schreibvorgang Zicken macht, wird er zum "Bad Sector". Bei aktuellen Festplattengrößen >1TB ist selbst ein "Bad Sector" kein Beinbruch.

Das klingt ganz toll, aber wenn das allein helfen würde bräuchte man keine komplexen Ansätze wie ZFS o.ä. Was du beschreibst ist, dass ein Block umkopiert wird bevor er harte Fehler wirft. Das hilft aber nicht, wenn in dem Block nicht das steht was einmal geschrieben wurde. Hier wird es auch erläutert: An Analysis of Data Corruption in the Storage Stack (Präsentation) An Analysis of Data Corruption in the Storage Stack (Paper)

[anselm]

 Jo_aus_SHG said:

Bei aktuellen Festplattengrößen >1TB ist selbst ein "Bad Sector" kein Beinbruch.

Es ist schon sehr lange so (lange bevor Festplatten die Terabyte-Grenze durchbrochen haben), dass Festplatten in Wirklichkeit mehr Kapazität haben, als sie nach draußen signalisieren. Es gibt eine „Geheimreserve“, die dazu verwendet wird, „bad sectors“ auszugleichen: Erkennt die Platte einen Sektor als unbenutzbar, ersetzt sie ihn (selbständig und ohne das an die große Glocke zu hängen) durch einen Sektor aus der Geheimreserve. Das geht so lange gut, wie es verfügbare Sektoren in der Geheimreserve gibt. Ist diese aufgebraucht, ist die Platte im Wesentlichen reif für den Schrott. Mit SMART kann man abfragen, wie es um die Geheimreserve steht. Die modernen Dateisysteme (ZFS, Btrfs, …) machen selber Prüfsummen über die Daten und können auch ohne Hilfe der Festplatte erkennen, wenn ein Platten-Lesevorgang verkehrte Daten liefert. Das muss nicht unbedingt an einem Schaden der Platte liegen, sondern kann auch einfach so passieren (kosmische Strahlen, schadhafte Kabel und so).

 Jo_aus_SHG said:

Festplatten sind heute eher für den Dauerbetrieb 7x24h (NAS) ausgelegt als für Archivierung, wo sie dann mehrere Monate nicht ausgelesen werden.

Das kommt auf die konkrete Festplatte an. Festplatten-Hersteller bieten heutzutage vom selben grundsätzlichen Plattenmodell oft mehrere Baureihen an, die sich je nach Einsatzgebiet unterscheiden: für Desktop-PCs, für NAS und für professionelle RAID-Systeme. Mechanisch sind die mitunter nicht so arg verschieden, aber sie haben unterschiedliche Firmware – bei Desktop-PCs möchte man zum Beispiel empfindlicher auf Fehler reagieren als bei RAID-Systemen in Storage-Servern, wo übereifriges Melden von „fehlerartigen“ Situationen dazu führen kann, dass das RAID aufwendig neu synchronisiert werden muss, auch wenn das eigentlich gar nicht nötig wäre. Man sollte also Desktop-Platten nicht in RAIDs betreiben und umgekehrt. Viele Grüße – Anselm

[Jo_aus_SHG]

 anselm said:

 Jo_aus_SHG said:

Bei aktuellen Festplattengrößen >1TB ist selbst ein "Bad Sector" kein Beinbruch.

Es ist schon sehr lange so (lange bevor Festplatten die Terabyte-Grenze durchbrochen haben), dass Festplatten in Wirklichkeit mehr Kapazität haben, als sie nach draußen signalisieren. Es gibt eine „Geheimreserve“, die dazu verwendet wird, „bad sectors“ auszugleichen: Erkennt die Platte einen Sektor als unbenutzbar, ersetzt sie ihn (selbständig und ohne das an die große Glocke zu hängen) durch einen Sektor aus der Geheimreserve. Das geht so lange gut, wie es verfügbare Sektoren in der Geheimreserve gibt. Ist diese aufgebraucht, ist die Platte im Wesentlichen reif für den Schrott. Mit SMART kann man abfragen, wie es um die Geheimreserve steht. Die modernen Dateisysteme (ZFS, Btrfs, …) machen selber Prüfsummen über die Daten und können auch ohne Hilfe der Festplatte erkennen, wenn ein Platten-Lesevorgang verkehrte Daten liefert. Das muss nicht unbedingt an einem Schaden der Platte liegen, sondern kann auch einfach so passieren (kosmische Strahlen, schadhafte Kabel und so).

 Jo_aus_SHG said:

Festplatten sind heute eher für den Dauerbetrieb 7x24h (NAS) ausgelegt als für Archivierung, wo sie dann mehrere Monate nicht ausgelesen werden.

Das kommt auf die konkrete Festplatte an. Festplatten-Hersteller bieten heutzutage vom selben grundsätzlichen Plattenmodell oft mehrere Baureihen an, die sich je nach Einsatzgebiet unterscheiden: für Desktop-PCs, für NAS und für professionelle RAID-Systeme. Mechanisch sind die mitunter nicht so arg verschieden, aber sie haben unterschiedliche Firmware – bei Desktop-PCs möchte man zum Beispiel empfindlicher auf Fehler reagieren als bei RAID-Systemen in Storage-Servern, wo übereifriges Melden von „fehlerartigen“ Situationen dazu führen kann, dass das RAID aufwendig neu synchronisiert werden muss, auch wenn das eigentlich gar nicht nötig wäre. Man sollte also Desktop-Platten nicht in RAIDs betreiben und umgekehrt. Viele Grüße – Anselm

Ich gebe Dir ja recht. Aber das mit den Filesystemen spielt auf einer anderen Ebene (Snapshots etc.) Auch, dass es unterschiedliche Plattentypen gibt, stimme ich zu. NAS professionelle RAID-Systeme verstehe ich zwar nicht ganz ist aber auch egal. Dem TO mag es auch egal sein. Wichtig ist doch nur ein Grundverständnis für die Datenspeicherung: 1. Nutze die aktuelle Speichertechnologie (kleines NAS / Server) für wichtige Daten. 2. Es gibt SMART oder die entsprechenden Tools des NAS-Herstellers und schaue danach. 3. Mache so oft wie möglich und nötig ein Backup auf ein externes Medium. 4. Lege dieses woanders ab. 5. Probe den Wiederherstellung. So. Dabei ist es wurscht, ob es sich um ein ZFS oder btrfs handelt und ob es 15000 Upm Festplatten oder 2 Green WD im Server sind. Gruß, Jo

[stardealer]

 photofan said:

vor kurzem erzählte mir ein Fotograf und Grafiker, dass die digitalen Bilder regelmäßig auf den Festplatten bewegt werden müssen, damit keine Bildverluste entstehen. Er würde einmal im Jahr seine kompletten Mediatheken auf andere Festplatten kopieren. Dies sei zwar ein mehrere Tage füllendes Unterfangen, aber seit Jahren von ihm ohne Probleme praktiziert.

Der gute Mensch hat mal etwas zum Thema Langzeitarchivierung gelesen und dabei nur die Hälfte verstanden oder behalten. Während sich die meisten Posts hier auf dauerhaft aktive Festplatten und deren Dateisysteme, Fehlertoleranz, SMART und andere Frühwarnsysteme beziehen hat die Langzeitarchivierung ganz andere Herausforderungen. Dort stellt sich die Frage wie Datenbestände auch ohne aktive Nutzung über Jahrzehnte lesbar und interpretierbar (ein ganz anderes und herausfordernderes Thema) gehalten werden. Und bei Jahrzehnten spielt es schon eine Rolle, dass eine Magnetisierung sukzessive verloren geht, bis ein Lesekopf keinen eindeutigen Zustand mehr feststellen kann. Grundsätzliche Funktionsfähigkeit des Mediums mal vorausgesetzt. Deswegen werden Langzeitarchivdaten immer mal wieder "bewegt", damit Information neu geschrieben und so mit einer frischen Magnetisierung wieder x Jahre gut lesbar sind.

[ED]

Hallo,

 zackenschaf said:

... Wow, dann muss ich eine besondere Ausnahme sein, denn in über 20 Jahren fast täglicher PC-Nutzung hatte ich - ganz ohne besondere Umkopiermaßnahmen - noch niemals ein Leseproblem bei meinen Daten. Und manche Daten schleppe ich schon seit den 90ern mit durch, von PC zu PC. :-) ...

Interessante Sichtweise. Demnach müsste es dann wohl auch ein Beweis für die prinzipielle Ungefährlichkeit des Verfahrens sein, wenn immer wieder Leute an der Tankstelle eine rauchen, ohne dass diese (bisher) in die Luft geflogen ist. Gruß, ED

[ED]

Hallo Anselm,

 anselm said:

... ZFS bei Solaris, {Free,Net}BSD oder Linux und Btrfs bei Linux arbeiten so. Beides sind sogenannte “Copy-on-Write”-Dateisysteme. Diese Arbeitsweise hat einige sehr handfeste Vorteile. ...

Absolut korrekt und unbestritten! Diese Filesysteme hatte ich bei meiner Betrachtung komplett ausgeblendet, dies aber nicht kund getan. Deshalb hole ich das hiermit nach. Mea culpa. Der Grund für's Ausblenden: ZFS zielt auf Enterprise-Szenarien und ist ganz sicher nicht das, was die Mitglieder dieses Forums auf dem heimischen PC nutzen, und auch nicht auf deren NAS. -- Falls ich mich diesbezüglich irrte, würde mich das übrigens freuen. Ich selbst habe ZFS etwa 2010/2011 unter FreeBSD sehr schätzen gelernt, allerdings auf wirklich "großem Eisen". In meiner eigenen, deutlich kleineren Umgebung setze ich es hingegen nicht ein. Interessant wäre für mich zwar, ZFS auf dem QNAP TS-451 NAS zu haben, doch das läuft unter QNAP's eigener Linux-Distribution, was ich nicht ohne Not ändern will. BTRFS hat featuremäßig sehr ähnliche Ambitionen wie ZFS, weshalb ich es ähnlichen Einsatz-Szenarien zurechne wie ZFS. An meiner Sichtweise ändert auch der Umstand nichts, dass BTRFS in OpenSuse nicht nur enthalten ist, sondern, zumindest nach meiner Erinnerung, dort auf GUI-Ebene auch als Default-Filesystem angeboten wird. -- Möge diese Suse-Entscheidung weise sein. Daten, die bei der Datensicherung entstehen, würde ich jederzeit einem ZFS-Filesystem anvertrauen, was dessen Reife und Zuverlässigkeit betrifft. Nicht gemeint ist damit allerdings die "User Land" ZFS-Implementierung unter Linux. BTRFS hingegen kommt mir derzeit nicht auf meine Rechner. Auf keinen. [Edit, hier zu Posting #38]

 anselm said:

... What he said ;^) Wie heißt es so schön: „Keiner will Backup. Alle wollen Restore.“ ...

Wir alle machen Backups doch in der Hoffnung, dass ein Restore niemals notwendig sein wird. Schon derjenige, der mal eines im paar-hundert-GByte-Bereich gemacht hat, weiß, warum. Aber leider ziehen viele Leute dann daraus den falschen Schluss. Siehe auch in diesem Thread die (sinngemäße) Argumentation: "Bei mir ist bisher nie was passiert..." Gruß, ED