Festplatten für Backups ungeeignet?

[Maxxon2k]

Hallo zusammen,

ich bin eigentlich sicher dass meine Frage schonmal behandelt worden sein müsste, kann aber keinen Thread finden:

Taugen große Platten angesichts URE als Backup?

Auf der Suche für einer 4TB Backup Platte für meinen HomeServer (im Moment 2x 2TB, ohne RAID) bin ich über die SpecSheets von WD Festplatten gestolpert. Diese weisen einen URE (nichtkorrigierbaren Lesefehler) <1*10^14 Bits aus.

Ich möchte hier keinen Flamewar auslösen ob die Gefahr real ist oder nicht. Ich halte sie für real, da wohl sonst die HDD Hersteller nichts dergleichen in ihre SpecSheets schreiben würden. Ich möchte daher wissen, wie ihr damit umgeht.

Als sinnvollste Lösung betrachte ich im Moment wirklich wichtigen Daten (wie Dokumente) auf ein paar Datenträger zu sichern, vielleicht sogar in die Cloud zu laden und Bitfehler bei seinen MultiMedia-Daten wie Urlaubsfotos einfach in Kauf zu nehmen, da ein wirklich potenter Schutz gegen Bitfehler meinem Kenntnisstand nach ziemlich ins Geld geht (erfordert bei der Plattengröße zwei RAID6 Systeme oder ein Bandlaufwerk). Bei meinen 4TB hätte ich dann bei komplettem Datenverlust durch z.B. Blitzschlag eine Chance von 32% auf ein defektes Foto. Wäre OK für mich (zumal mir der Server jetzt auch falsche Daten liefern dürfte, ohne dass ich es überhaupt merke).

Wie sieht eure Lösung aus, oder ignoriert ihr das Thema?

 

[DragonTear]

Also ich denke Backup-programme müssten per Checksumme eigentlich prüfen ob das Backup korekt erstellt wurde.
Acronis True Image z.B. hat eine Funktion "backup überprüfen". Bin mir allerdinggs nicht sicher was die tut.
Zip programme wie Winrar und 7z tun das ebenfalls.

Eine Checksummen-generation kann man auch manuell mittels Programm nachträglich durchführen. D.h. wenn du ein Backup unter Windows erstellst und einfach nur Dateien kopiert hast.
Bei Backups des gesammten OS, musst du dich auf das Programm verlassen.

Allgemein gilt übrigens dass man immer zwei Backups anlegen sollte - das Backupmedium kann ja jederzeit plötzlich kaputt gehen (das ist statistisch wohl auch wahrscheinlicher als eine relevanter Schreibfehler).
Damit umgeht man auch das Schreibfehler-Problem.

Ebenso wie die manuelle Checksum-Prüfung macht der Ottonormalverbraucher das aber natürlich eher nicht...

 

[Cobrion]

Taugen große Platten angesichts URE als Backup?

Kurze Antwort: Ja.

Lange Antwort: Die URE von anderen Speichermedien ist meist genauso schlecht oder sogar schlechter als die von billigen Consumer-Festplatten (also <1*10^14 - sauteure Datacenter-Platten mit bis zu 900GB liegen bei <1*10^16).
Nagelneue Optische Medien haben URE-Angaben im Bereich von <1*10^9 bis <1*10^12, LTO liegt bei <1*10^14, SSDs tummeln sind im Bereich von <1*10^14 bis <1*10^16. Allerdings altern die verschiedenen Medien unterschiedlich schnell. Bei optischen Sicherungsmedien ist schon nach einem Jahr eine deutliche Steigerung der Fehlerraten zu verzeichnen. Magnetbänder leiden massiv bei Mehrfachverwendung (sprich simples überschreiben) und bei SSDs weiss eigentlich niemand so wirklich, wie lange die ihre Daten wirklich intakt halten können.

Einen 100%igen Schutz gegen Bitfehler gibt es natürlich nicht, obwohl man z.B. per Raid 2 die URE deutlich senken kann.

Für den Alltagsbetrieb ist das aber meist absolut übertrieben. Da reicht es, wenn man seine Daten nicht direkt auf eine Backup-Platte kopiert, sondern sie erst mit einem Packer bearbeitet. Je nach verwendetem Packer erhält man dadurch mindestens CRCs für die Daten und kann somit Fehler wenigstens erkennen (). Einige Packer betten sogar wahlweise zusätzliche ECC oder Reed-Solomon-Codes ein, um fehlerhafte Daten nachträglich zu korrigieren.

Jenseits der Windowswelt, die ja leider ohne Checksummen im Dateisystem auskommen muss, gibt es z.B. unter Linux durchaus auch Dateisysteme, die mindestens CRC auf Dateiebene bieten. Allerdings geht dies natürlich auch zu Lasten der Geschwindigkeit beim Datenzugriff.

Eine im selben Server verbaute Festplatte ist davon unabhängig kein wirkliches Backup, da gerade Probleme im Energiebereich (Überspannungen, Netzteil geht kaputt usw.) tendenziell alle angeschlossenen Komponenten zerstören können.
Sicherer ist es, eine Backupfestplatte per eSata oder USB3.0 nur während des Backup-Vorgangs anzuschliessen.

 

[Holt]

SSDs tummeln sind im Bereich von <1*10^14 bis <1*10^16.
Das stimmt so nicht! Leider geben nur die wenigsten Hersteller für ihre SSDs auch die UBER an, aber die JEDEC verlangt in der JESD 218A 10^15 für Consumer (Cleint) SSDs und 10^16 für Enterprise SSDs und diese Werte müssen bis zum Erreichen der spzifizierten P/E Zyklen eingehalten werden!

Es gibt auch welche die mit 10^17 angegeben sind:

Uncorrectable Bit Error Rate (UBER): 1 sector per 10^17 bits read

Das lässt sich auch einfach erklären, denn die UBER verhält sich bei SSDs ganz anders als bei HDDS, neue SSDs haben praktisch keine Bitfehler (gute jedenfalls) und mit dem Alter (verbrauchten P/E Zyklen) steigt die Fehlerraten dann an:



Hier sieht man dann, wie zumindest Intel die Angaben ermittelt, also an welchem Punkt der Kurve man dort die Werte abnimmt:



(Quelle)

Allerdings altern die verschiedenen Medien unterschiedlich schnell. Bei optischen Sicherungsmedien ist schon nach einem Jahr eine deutliche Steigerung der Fehlerraten zu verzeichnen. Magnetbänder leiden massiv bei Mehrfachverwendung (sprich simples überschreiben) und bei SSDs weiss eigentlich niemand so wirklich, wie lange die ihre Daten wirklich intakt halten können.

Die Data Retention Time hängt gerade bei SSDs sehr von der Temperatur ab, da sieht die Norm für Consumer SSDs 12 Monate bei 30°C vor, bei kälteren Temperaturen sollten sie die Daten länger halten können, aber wer kauft schon SSDs für Backups?


Zum Thema: Wenn Du zwei getrennte Backups auf einzelnen Platten hast, dann ist das Risiko den Unkorrigierbaren Fehler bei beiden Platte auf der gleichen Datei oder bei sehr wichtigen Verwaltungsdaten zu haben, schon mal extrem klein! Das spricht auf gegen diese Methode mit dem Packer, da das Risiko mir der Große der Dateien (Archive) natürlich steigt um bei einer einzelnen Datei über die ganze Kapazität dann bei 1 anzukommen. Was man hier nicht in einen Top werfen sollte ist die Uncorrectable Bit Error Rate und die Undetectable Bit Error Rate, letztere führt zu schlechender Korroption der Daten.

 

[Cobrion]

Die Data Retention Time hängt gerade bei SSDs sehr von der Temperatur ab, da sieht die Norm für Consumer SSDs 12 Monate bei 30°C vor, bei kälteren Temperaturen sollten sie die Daten länger halten können, aber wer kauft schon SSDs für Backups?

12 Monate bei 30°C klingt aber schon mehr als übel. Da kann man ja gerade bei Mobilgeräten nur beten, dass die oft bzw. lange genug an sind, dass die Controller still und heimlich einen regelmäßig Datenrefresh hinbekommen (der dann natürlich netterweise die TBW erhöht).

Zum Thema: Wenn Du zwei getrennte Backups auf einzelnen Platten hast, dann ist das Risiko den Unkorrigierbaren Fehler bei beiden Platte auf der gleichen Datei oder bei sehr wichtigen Verwaltungsdaten zu haben, schon mal extrem klein! Das spricht auf gegen diese Methode mit dem Packer, da das Risiko mir der Große der Dateien (Archive) natürlich steigt um bei einer einzelnen Datei über die ganze Kapazität dann bei 1 anzukommen. Was man hier nicht in einen Top werfen sollte ist die Uncorrectable Bit Error Rate und die Undetectable Bit Error Rate, letztere führt zu schlechender Korroption der Daten.

Die Archivmethode setzt auf Archive mit zusätzlichen Redundanzinformationen zur Fehlerkorrektur. Die potentiell höhere Datei-Größe erhöht zwar die Wahrscheinlicheit, dass die Datei von einem Fehler betroffen ist, aber die Fehlerkorrekturdaten sollten das mehr als ausgleichen. Bei getrennten Backups auf 2 Platten ist natürlich die Wahrscheinlichkeit, dass beide an der selben Stelle einen Fehler aufweisen, äußerst gering, aber im Endeffekt hat man dadurch mehr Platz verschenkt.
Im Zweifelsfall ist der sinnvollste Weg sowieso, beide Varianten zu kombinieren (also gepackte Daten mit CRC und ECC/FEC auf 2 oder mehr unterschiedliche Sicherungsmedien kopieren).

Uncorrectable Bit Error Rate (UBER): 1 sector per 10^17 bits read

1 Sektor ist aber erheblich mehr als 1 Bit.

 

[Holt]

Die Archivmethode setzt auf Archive mit zusätzlichen Redundanzinformationen zur Fehlerkorrektur. Die potentiell höhere Datei-Größe erhöht zwar die Wahrscheinlicheit, dass die Datei von einem Fehler betroffen ist, aber die Fehlerkorrekturdaten sollten das mehr als ausgleichen.

Sorry, aber Du hast den Unterschied zwischen den Uncorrectable Bit Errors und den Undetectable Bit Errors noch nicht verstanden. Ein Undetectable Bit Error bedeutet, dass zufällig mehrere Bits so gekippt sind, dass die ECC stimmt und damit der Fehler nicht erkannt wird, die Daten also als korrekt gelesen übermittelt werden, was dann zur Silent Korruption führt. Diese kommt aber ungleich seltener als die 10^14 bis 10^17 mit denen HDDs und SSDs angegeben werden, dort geht es um die Uncorrectable Bit Error Rate (steht meist auch extra dabei, weil beide zuweilen gleich mit UBER abgekürzt werden!) und die enthält natürlich auch die extrem seltenen Undetectable Bit Errors (logisch, denn Fehler die nicht erkannt werden, könne auch nicht korrigiert werden), aber wenn es kein solcher ist (also fast immer, ich die unerkannte liegen bei <1:10^10 aller unkorrigierbaren Bitfehler), dann gibt es einen Read Error und das Lesen der Daten schlägt gewöhnlich komplett fehl. Daher ist der Ansatz statt vieler kleiner Dateien ein großes Archiv zu verwenden um sich gegen diese ganz wenige unerkannten Bitfehler zu schützen auch total unsinnig!

Außerdem muss man dann auch mindestens ECC RAM und wirklich Mission Critical Enterprise HW verwenden, damit man eine End-to-End Data Path Protection auch innerhalb der Datenpfade der Controller auf dem Host und der Platte hat. Das ist dann eine andere Hausnummer, auch finanziell und ob Du das mit den SW Alternativen hin bekommst, da wäre ich mir auch nicht so sicher. Große Archiven sind jedenfalls gegenüber kleinen Dateien keine gute Wahl, weil Du dann beim Lesen das Risiko erhöhst diese gar nicht gelesen zu bekommen.

Zu mal als Beispiel, so sieht es bei Micron / Crucial in den Consumer SSDs aus:



Da wird immerhin schon ECC im Cache RAM verwendet, ob das bei den normalen HDDs auch der Fall ist?

So sieht es bei einer Enterprise SSD von Micron aus:



Das ist dann der Unterschied:



(Quelle

Bei den Consumer HDDs hat meines Wissens nur die WD VelociRaptor so eine End-toEnd Protection implementiert.

Bei getrennten Backups auf 2 Platten ist natürlich die Wahrscheinlichkeit, dass beide an der selben Stelle einen Fehler aufweisen, äußerst gering, aber im Endeffekt hat man dadurch mehr Platz verschenkt.

Eine UBER von 1:10^14 besagt im Prinzip, dass man alle 12TB mit einem nicht korrigierbaren aber erkannten Bitfehler rechnen muss. Bei einem RAID5 bedeutet das, dass das Rebuild dann abbrechen würde und damit fehlschlägt. Beim Backup der Dateien eines solche RAIDs auf 3 einzelnen HDDs würde es bedeuten, dass man sehr wahrscheinlich eine der Dateien nicht lesen kann, mit ganz viel Pech auch deutlich mehr, wenn Metadaten des Filesystems betroffen sind. Dagegen würden Deine SW-Lösungen dann übrigens auch nicht helfen!

Der billigste Weg dieses Risiko zu minimieren ist es ein zweites Backup zu haben, also die 3x Kapazität vorzuhalten und die Backupplatten im Wechsel zu verwenden. Das sichert auch gegen den Fall des Verlustes einer Backupplatte (sollte man sie in der Streßsituation z.B. fallen lassen) oder falls es gerade dann zur Katastrophe kommt, wenn man mal wieder ein neues Vollbackup zieht und die Backupplatte dafür gerade gelöscht hat.

Im Zweifelsfall ist der sinnvollste Weg sowieso, beide Varianten zu kombinieren (also gepackte Daten mit CRC und ECC/FEC auf 2 oder mehr unterschiedliche Sicherungsmedien kopieren).

Das ist immer eine Frage des Aufwandes den man treiben möchte, aber wenn man zwei Sicherungsmedien verwendet, und auf gepackte Daten setzt, würde ich die Archive nicht zu groß werden lassen. Besser eine Prüfsumme über jede Datei einzeln verwenden, wenn man sich gegen das sehr viel geringere Risiko von Unerkannte (Undetectable) Bitfehler auch noch absichern will, aber das macht eigentlich nur Sinn, wenn auch der Rest der HW entsprechend ausgelegt ist und man sich dann nicht doch wieder einen Bitfehler bei der Übertragung der Backupdaten einzufangen droht.

Wenn man solche Datenkorruptionen wirklich möglichst 100%ig verhindern will, muss man einen Mainframe kaufen, da wird alles bis zur Funktion der CPU genauestens überwacht und deshalb werden die Steinzeitmonster z.B. bei Banken und Versicherungen, also da wo ein gekipptest Bit oder ein Rechenfehler nun wirklich gewaltigen Schaden anrichten können, ja auch immer noch verwendet.

Uncorrectable Bit Error Rate (UBER): 1 sector per 10^17 bits read

1 Sektor ist aber erheblich mehr als 1 Bit.

Lies doch bitte noch mal genau, das steht 1 Sektor pro 10^17 gelesene Bits (bits read)! Wohlgemerkt, gelesen Bits und nicht Bytes und wie vielen TB z.B. 10^14 Bits entsprechen, kannst Du wohl selbst ausrechnen, bei 10^17 dann die gleiche Zahl in PB. Warum ein Sektor und nicht Bytes oder Bit pro 10^17 gelesener Bits? Einfach weil die Platten (egal ob HDD oder SSD) dann einen Lesefehler melden, wenn man versucht den betroffenen Sektor zu lesen, außer es ist einer der ganz seltenen unerkannten Bitfehler. Wie hoch deren Wahrscheinlichkeit genau ist, hängt immer vom ECC Algorithmus ab und halt von den Sicherungen auf dem Datenweg, aber den Wert gibt normalerweise kein Hersteller an.

 

[Maxxon2k]

Erstmal vorweg vielen Dank für eure Antworten!

Die Archivmethode setzt auf Archive mit zusätzlichen Redundanzinformationen zur Fehlerkorrektur. Die potentiell höhere Datei-Größe erhöht zwar die Wahrscheinlicheit, dass die Datei von einem Fehler betroffen ist, aber die Fehlerkorrekturdaten sollten das mehr als ausgleichen. Bei getrennten Backups auf 2 Platten ist natürlich die Wahrscheinlichkeit, dass beide an der selben Stelle einen Fehler aufweisen, äußerst gering, aber im Endeffekt hat man dadurch mehr Platz verschenkt.
Im Zweifelsfall ist der sinnvollste Weg sowieso, beide Varianten zu kombinieren (also gepackte Daten mit CRC und ECC/FEC auf 2 oder mehr unterschiedliche Sicherungsmedien kopieren).

Auf eine Abwandlung dieser Methode bin ich in der Zwischenzeit auch gestoßen: Ich möchte meine Dateien mit einem Programm wie PAR2 mit zusätzlichen Redundanzinformationen versehen. Dies kann auch für ganze Verzeichnisse geschehen, so dass man die Daten nicht zusätzlich packen müsste (und sie blieben somit durch einfaches Anstöpseln der Platte an einen Rechner ohne zusätzlichen Packer lesbar). Bei Bedarf kann mit PAR2 auch die Integrität der Daten geprüft werden.
Dabei bleibt jetzt aber wieder eine Frage übrig: Gibt es Dateisysteme, die einem das abnehmen? Ich habe bei meiner Recherche bisher nur Dateisysteme gefunden, die mit Prüfsummen Bitfehler erkennen aber nicht automatisch reparieren können. Beispielsweise kann das ZFS. ZFS könnte die Daten auch direkt korrigieren, aber dazu benötigt ZFS wenigstens ein RAID - also mehrere Festplatten. Ich suche aber eine Dateisystem, das die Wiederherstellungsinformationen direkt mit der Datei abspeichert, beim Lesen eine Prüfsummenprüfung wie ZFS durchführt und die Datei mit den Wiederherstellungsinformationen ggf. direkt online korrigiert. Kennt da jemand was?