Langzeit-Datensicherheit Setup (mit Windows)?

[Merlin-.-]

Hi Leute,

angeregt durch den Thread "jpg Dateien gehen kaputt" habe ich den dort verlinkten Artikel über "Bit Rot" durchgelesen (danke Chief Gewickelt für den Hinweis!) und micht gefragt, wie ich so ein neues Dateisystem (btrfs/ReFS) für Langzeit-Datensicherheit nutzen kann.

Nun sind mir kaputte .jpg-Dateien leider auch schon untergekommen, weshalb ich mich direkt wiedererkennen konnte in dem Artikel. Leider helfen die üblichen Strategien ("immer schön Backup machen!") nicht gegen den Bit Rot; es helfen nur ständiges Prüfsummen-Berechnen und -Vergleichen.

Ich will bei Windows bleiben und würde dafür ggf. auf Windows 10 wechseln wegen ReFS (von Windows 7 aus).


1. Wer hat schon Erfahrungen mit btrfs/ReFS? Kann ReFS bzgl. Datensicherheit mit btrfs mithalten? Ist die Performance inzwischen passabel?

2. Was würdet ihr allgemein raten als Strategie? Ein RAID1 mit btrfs/ReFS wäre wohl sinnvoll, wenn ich ArsTechnica folge, weil dann ständig die Prüfsummen korrigiert werden?

3. Ein Backup des Datenarrays müsste dann auch auf ReFS erfolgen? Wenn das Format des externen Backups NTFS ist, ist die Gefahr des Bit Rot wieder erhöht?

4. Lieber ein NAS als Datenspeicher bzw. Backup? Oder ist das Geschmackssache?

5. Sonstige Ideen?


Das Ganze sollte möglichst mit Windows, und damit ReFS, laufen, weil ich nicht extra das experimentelle btrfs (work in progress) und Linux nutzen will. Oder bin ich da auf dem Holzweg?...


Gespannt auf eure Ideen,
Merlin

 

[xxMuahdibxx]

Wie wäre es nicht in JPG zu speichern um diese Lücke zu umgehen ?

RAW wäre da wohl besser aber halt bei ca 4-5 Facherm Speicherbedarf.

 

[Necareor]

Reicht da nicht schon ZFS unter FreeNAS? Meines Wissens verhindert ZFS bereits ebenfalls Bit Rot.

Und ReFS läuft doch auch schon unter Windows 8.1.

Ein Backup muss auf jeden Fall auch wieder auf ReFS bzw. ZFS oder ähnlich erfolgen. Wenn du wieder auf NTFS schwenkst, ist die Gefahrt natürlich wieder da. Auch wenn die Dateizugriffe auf ein Backup eher gering sind, aber manchmal ist ja auch der Controller Schuld.

Unter Windows 8.1 kann man auf diesem Weg bereits Volumes mit ReFS erstellen:
http://winaero.com/blog/how-to-format-any-drive-in-windows-8-1-with-refs/

 

[RED-Bit]

der Thread "jpg Dateien gehen kaputt" stammt von mir und mich würde diese Frage natürlich auch interessieren

 

[KillerCow]

Wie wäre es nicht in JPG zu speichern um diese Lücke zu umgehen ?

Was für eine Lücke? In dem Artikel geht es um ein generelles Problem, dass am Beispiel eines Fotos demonstriert wurde (weil es da so schön gezeigt werden kann). Egal, in welcher Datei ein Bit "umkippt", es führt letztlich zur ungewollten Veränderung der Daten. Veränder doch mal in einem ZIP Archiv ein Bit und entpack das Archiv anschließend

ZFS arbeitet auch mit Checksummen und kann Bitrot verlässlich erkennen und korrigieren. Letzteres allerdings auch nur, sofern redudante Daten vorhanden sind.

 

[Necareor]

Bei einer RAW-Datei würde sich das umgekippte Bit natürlich weit weniger schlimm bemerkbar machen, da es pro Information einfach viel mehr Bits gibt bzw. es gibt keine Abhängigkeiten durch die Komprimierung. Aber das generelle Problem hättest du trotzdem noch, nur eben weitaus langsamer.

 

[MORPEUS]

Irgendwie habe ich jetzt Angst um meine Daten. Meine Englischkenntnisse sind auch nicht die besten. Kann mir mal jemand in einfachen Worten sagen was BitRot ist, wie es dazu kommt (Beispiel) und wie ich es vermeiden kann.

 

[RED-Bit]

ganz einfach: der Inhalt einer Datei (bits) wird mit der Zeit korrupt. Bitzustände verändern sich. Dabei kann es passieren, dass man die Datei nicht mehr öffnen kann. Hast du viele mp3 Dateien in Verzeichnissen abgelegt, auch ältere? Dann lass mal mp3test drüber laufen.
Ich habe jede Menge mp3s die mitten drin einen Teil von einer anderen mp3 Datei haben:
Metallica Song und plötzlich cut: Heino singt dazwischen ;-) und wieder cut zurück zu Metallica usw.

Das ist mir bisher nur bei jpgs und mp3 aufgefallen.
leider gibts sowas wie mp3test nicht für jpgs, daher fallen die Fehler in jpgs seltener oder viel zu spät auf.

 

[Necareor]

Ouh okay, so heftige Veränderungen sind mir bisher auch nicht untergekommen. Hatte bisher nur einzelne Pixelfehler, selten größere Bildfehler in alten JPEGs, bei mp3s ist mir nichts aufgefallen.

 

[Holt]

Wenn man Probleme mit korrupten Dateien hat, dann liegt es zu 99% am RAM, wenn es keine Lesefehler gab. Wenn man einen Rechner bekommt, zusammenbaut oder auch nur irgendwas am RAM ändert, dann ist es unerlässlich das RAM mit Memtest86+ zu testen! Dazu muss die iso oder img von CD oder USB-Stick gebootet werden, denn man kann nicht unter Windows sinnvoll das RAM testen. Es sollten mindestens 6 PASS abgewartet werden und es darf dabei kein einziger Fehler auftreten, man lässt es also am Besten über Nacht laufen. RAM-Fehler können die unmöglichsten Probleme erzeugen und müssen sich längst nicht immer durch Bluescreens verraten!

Wer also gehen schlechenden Datenverlust angehen will, der braucht erst mal ECC-RAM, was auch die Voraussetzung für ZFS ist, sonst werden Bitfehler im RAM beim Scrubbing die Daten Stück für Stück kompromitieren und wie ein Krebs zerfessen. Das Scrubbing ist aber bei einem RAID (RAID 0 ist kein RAID) unvermeidlich, damit schlechtender Datenverlust auf den Platten vermieden wird, dazu ein Backup oder zwei und dann sollte man als Heimwender schon ausreichend und mit überschaubaren Mitteln sicher sein. 100%ig sicher sind allenfalls Mainframes, weshalb diese bei Banken und Versicherungen ja auch immer noch unersetzlich sind, da dort selbst ein einzelner Bitfehler den Ruin bedeuten kann.

 

[Rumo]

Leider helfen die üblichen Strategien ("immer schön Backup machen!") nicht gegen den Bit Rot; es helfen nur ständiges Prüfsummen-Berechnen und -Vergleichen.

Hm. Es ist ein bißchen von allem. Du musst zum einen merken daß die Datei kaputt ist und zum anderen eine Kopie der Datei haben.

Wenn man Backups hat und zwar solche die nicht immer alles überschreiben [also: die keine alten Backups löschen sondern nur neue hinzufügen, inkrementell], dann hat man normalerweise schon gute Chancen daß in einem der Backups die intakte Datei liegt, nämlich dann wenn sie erst nach dem Backup defekt geworden ist.

Die Prüfsumme kann dir sagen daß die Datei falsch ist aber nicht die intakte Datei herbeizaubern. Dazu brauchst du irgendeine Form von Redundanz und diese ist halt irgendwann weg (wenn es ein Dateisystem auf einer Platte ist und die Platte geht ein).

Bei Fotos [statische Daten überschaubarer Größe] bieten sich auch immer noch optische Datenträger an. Ein paar Cent und du hast eine weitere read-only-Kopie. Sicher sie verfault mit der Zeit [vor allem in der Sonne bzw. an der frischen Luft, also wegsperren], aber wenn in deine Festplattensammlung beim Backupmachen der Blitz einschlägt oder das Netzteil abraucht und die Hardware mitnimmt, dann bist du froh drum, noch irgendwas im Schrank zu haben.

 

[Merlin-.-]

Danke schon mal für die bisherigen Beiträge!


Erkenntnisse bisher:

1. ECC RAM verwenden und Arbeitsspecher validieren. Ersteres ist nicht sonderlich praxistauglich mit einem Standard-Desktop. :-/
Den RAM mit Memtest86+ validieren, damit er nicht ständig Bits flippt, ist ne praxistaugliche Idee. Werde ich direkt mal machen.

2. Gelegentlich read-only-Kopien ziehen ("CDs brennen"), da sich auf der CD (hoffentlich) keine Bits verändern. Wobei es da wieder "CD Rot" gibt; aber das ist eine andere Geschichte. Einfach die CDs neu brennen regelmäßig; und sowieso lichtscheu lagern.




Um das mal in ne Strategie umzusetzen / Fragen an euch:

a) ReFS scheint noch nicht bootbar zu sein. Was haltet ihr von einem RAID1 am H97-Controller mit ReFS-Formatierung? Alle "Mediendateien" würden dann original vom RAM direkt dort hinkommen (lässt sich wegen Windows-Benutzung von c:/users/merlin/appdata/... wohl nicht 100% garantieren, aber meistens!).

b) Hin und wieder ein read-only-Backup à la "CDs brennen" mit den wichtigsten Dateien.

c) Wenn read-write-Backup dann wieder auf ein ReFS-RAID1? (ob NAS ist dann eher unerheblich für die Datensicherheit)

d) Zwei mal WD Red/Green gewünschter Größe ins RAID1 mit meinem H97? Wäre dann die direkte Umsetzung. Das in ReFS formatieren. Später dann externes Gehäuse/NAS wieder mit RAID1 und ReFS... gibt es dann ne Möglichkeit, die Checksummen auf dem Backup (NAS) mit dem Original (Desktop) zu vergleichen?



Versteht mich nicht falsch, ich bin kein Sicherheitsfanatiker. Gerade deshalb würde ich das Thema gerne einmal ordentlich durchkauen und zu ner guten und relativ einfachen Lösung kommen; also mit wenig Arbeitsaufwand nach der Einrichtung - und Windows-basiert.
Und nicht Backup nach Backup machen und es bringt nix. ^^

 

[xxMuahdibxx]

Und nochmal über die Kompression nachdenken ... JPG Komprimiert halt stark und da fällt ein Fehler schneller ins gewicht.

 

[Rumo]

Und nochmal über die Kompression nachdenken ... JPG Komprimiert halt stark und da fällt ein Fehler schneller ins gewicht.

Bitmap ist keine Lösung... wenns ums Fehler vermeiden geht, ist es egal, ob der Fehler einen Pixel oder ein ganzes Bild betrifft. Zumal du für Bitmaps viel mehr Speichermedien brauchst (Platzbedarf explodiert) und mehr Medien haben auch wieder eine höhere Ausfallwahrscheinlichkeit.

Zumal man die Bilder meistens nicht in BMP braucht sondern doch wieder JPG und dann hast du nach JPG->BMP->JPG richtige Qualitätsverluste.

Wenn man gleich in der Kamera als RAW fotografiert ist es vielleicht was anderes, aber das machen ja nur "Profis"

 

[Holt]

1. ECC RAM verwenden und Arbeitsspecher validieren. Ersteres ist nicht sonderlich praxistauglich mit einem Standard-Desktop. :-/

Du hast doch einen Xeon 1231V3, dann hättest Du eben ein Board mit einem passenden Chipsatz nehmen müssen, wenn das Thema Silent-Data Corruptuion für Dich ein Thema ist.

Den RAM mit Memtest86+ validieren, damit er nicht ständig Bits flippt, ist ne praxistaugliche Idee. Werde ich direkt mal machen.

NEIN, gegen gefippte Bits hilft nur ECC, Memtest86+ ist nur dazu um bestimmte, fertigungsbedingte Fehler zu finden, etwa wenn bei bestimmten Bitkombinationen Übersprechen zu Botefehlern führt, dass sagt aber nicht, dass ein Bit nicht doch zur Laufzeit spontan kippen kann. Dafür sowas zu finden ist die Zeit zwischen dem Schreiben und Lesen der Daten bei RAM Tests zu kurz. Dagegen hilft einzig und alleine nur ECC RAM!

Versteht mich nicht falsch, ich bin kein Sicherheitsfanatiker. Gerade deshalb würde ich das Thema gerne einmal ordentlich durchkauen und zu ner guten und relativ einfachen Lösung kommen; also mit wenig Arbeitsaufwand nach der Einrichtung - und Windows-basiert.

Einfach, günstig und ohne Aufwand ist das nicht möglich! Der erste Schritt ist ECC, dann Redundanz bzw. Prüfsummen mit Fehlerkorrekturpotential.

Es gibt drei Quellen für Datenverlust bzw. -korruption: RAM, Übertragungen und Platten! Beim RAM ist nur ECC wirklich sicher, am Besten Enhanced ECC wie Killchip, aber einfaches ECC reduziert die Fehlerraten schon mal gewaltig. Wenigstens sollte das RAM gut geprüft sein, damit nicht systematische Fehler vorhanden sind. Die Übertagung ist eher selten die Fehlerursache, selbst SATA hat bei jeder Übertragung eine CRC für maximal 8k Daten, aber auch da haben Enterprise Platten und Enterprise Controller mehr Absicherungen der internen Datenpfade gegen Bitfehler als Consumerplatten. Die Platten sind eher ein Problem, gerade bei HDDs kann ein Stoß oder Vibrationen schon reichen um den Kopf aus der Spur zu bringen und schon sind die Daten der Nachbarspur überschrieben und ein(ige) Sektor(en) nicht mehr lesbar, also schwebend. Das ist dann keine Silent Data Corruption da es einen Lesefehler geben wird, aber ohne Backup sind die Daten trotzdem weg. Um das bei einem RAID zu vermeiden macht man regelmäßigs Prüfungen (scrubbing) ehen das Risiko steigt, dass so viele Sektoren bei den Daten und der Partity betroffen sind, dass eine Wiederherstellung nicht mehr möglich ist. Wirklich unerkannte Bitfehler sind aber bei Platten selten, außer dem Übertragungsfehlern auf deren internen Datenpfaden, gegen die meist nur Enterprise Platten effektiv geschützt sind. Dann gibt es noch Adressierungsfehler, es wird also versehentlich der falsche Sektor gelesen ohne einen Fehler, die sind aber auch sehr, sehr selten.

 

[xxMuahdibxx]

Wenn man gleich in der Kamera als RAW fotografiert ist es vielleicht was anderes, aber das machen ja nur "Profis"

Aber darum gings ja bei mir im 1. Post schon ich hab nicht von BMP geredet das dort das Konvertieren blöd ist weis ich auch.

 

[Merlin-.-]

Herzlichen Dank, Holt, für die genauen Erklärungen!

Ich habe mir jetzt mental ein Setup zusammengestellt, um die verschiedenen Fehlerquellen zu minimieren:
- ECC-RAM + Board + CPU (Server-Hardware)
- nur SSDs wegen Vibration / mechanischer Fehlerquelle
- transparentes Pseudo-RAID1* mit resilientem Filesystem (z.B. ReFS) wegen "Autoreparatur" (bei ReFS: Mirror Space)
- gleiches auch als Backup, um Persistenz des Backups sicherzustellen
- direkt nach Backup das Backup validieren (ggf. selbst checksums per Skript vergleichen)

Da ich gerade erst neue Hardware gekauft habe, steht das aber erst in der Zukunft ins Haus.

 

[xxMuahdibxx]

Jup nur SSD´s wenn da mal was hops geht ist meist der ganze Datenträger futsch ...

 

[Merlin-.-]

Damit sagst Du mir nichts Neues (falls Du jetzt was schlaues, neues sagen wolltest). Du musst es schon im Kontext der anderen Maßnahmen sehen - zwei RAID1, die synchronisiert sind. Da müssten schon mindestens 4 SSDs gleichzeitig ausfallen... von daher, unnötiges Zitat aus dem Kontext reißen bzw. Kontext nicht verstanden.

 

[Holt]

So ein spontaner Komplettausfall ohne Chance auf Datenrettung bzw. allenfalls durch einen Profi, kann einem mit einer HDD genauso passieren, nur ist es dort die Ausnahme, weil meist Fehler am Medium auftreten und diese lassen sich eben gut vorher erkennen. Ohne Datensicherung gibt es aber sowieso keine Datensicherheit.