Bitrot bedroht meine Dateien!

[Dr. Lars Sahmströhm]

Ich habe gerade gelesen, dass es Bitrot gibt. Jetzt will ich handeln, hab aber keine Ahnung und auch keine lust ein NAS anzuschaffen. Wie kann ich Bitrot verhindern? :usad:

a) Teure Festplatte kaufen, die 1 zu 1015 Fehler hat und bei NTFS bleiben?
b) ZFS nutzen? (Geht nur mit Linix/unbuntu)
c) ReFS nutzen? (Geht nur mit Win10 Enterprise oder Pro Workstation)

Kann ich z.B. um ZFS in meiner normalen Windows Umgebung nutzen zu können, eine virtual machine mit unbuntu anlegen und von dort ganz normal auch in Windows damit arbeiten oder sind dann alle Daten, die aus der VM kommen für Windows unbrauchbar? Wahrscheinlich schon oder? Und ein RAID-1 verhindert allein auch kein Bitrot? ReFS soll viele Nachteile haben im vergleich zu NTFS, stimmt das? Also kann ich nur eine teure Festplatte mit 1 zu 1015 kaufen, wenn ich mit NTFS vor Bitrot sicher sein will?

[Mortalvision]

Über den Wolken, muss die Freiheit wohl grenzenlos sein...

Nutze eine Cloud!

[Corny]

Backups?

[fezie]

Ich weiß jetzt nicht wie es bei ReFS ist.
Aber bei ZFS und btrfs bräuchtest du mindestens 2 Festplatten. Und dann das integrierte RAIDZ bzw.btrfs RAID Modi nutzen. Kein mdadm RAID!
Und regelmäßiges Scrub machen.

Aber ja, wenn dir die Daten so extrem wichtig sind: backups!

Weiß jemand wie das bei LTO Bändern mit bitrot aussieht? Die lagern ja auch lange und kaum jemand prüft ob die Daten noch lesbar/korrekt sind.

[Tyrann]

Es gibt btrfs Treiber für Windows: https://github.com/maharmstone/btrfs

du machst dir damit ein RAID1 oder RAID5

[fezie]

Es gibt btrfs Treiber für Windows: https://github.com/maharmstone/btrfs

du machst dir damit ein RAID1 oder RAID5

WinBtrfs hat allerdings Bugs und ist damit nicht so ganz mit der Linux Variante kompatibel.

btrfs RAID 5 sollte nicht genutzt werden. Unter Linux hat das ziemliche Probleme, die seit Ewigkeiten nicht wirklich angegangen werden. Ich glaub kaum das WinBtrfs das besser hinbekommt.
Und ich mein nicht nur das ungelöste Problem des "write-hole":
Siehe https://lore.kernel.org/linux-btrfs/20200627032414.GX10769@hungrycats.org/

[Tyrann]

ok, dann nehme ich das RAID 5 raus.

zfs für Windows scheint ja noch jünger zu sein.

[Gliese]

Einfach nur Backup machen bringt nicht unbedingt Sicherheit, denn wenn die Fehler nicht bemerkt werden, landen die korrupten Daten irgendwann mit in den Backups, oder umgekehrt: die korrupten Daten aus dem Backup landen auf der Arbeitsplatte.

Jede Methode, die nicht mit Prüfsummen arbeitet ist daher prinzipiell ungeeignet.


Kann ich z.B. um ZFS in meiner normalen Windows Umgebung nutzen zu können, eine virtual machine mit unbuntu anlegen und von dort ganz normal auch in Windows damit arbeiten oder sind dann alle Daten, die aus der VM kommen für Windows unbrauchbar?
Sobald du eine Linux-VM mit ZFS am Start hast, könntest du in der VM ein Samba-Server aufsetzen und von Windows aus dann normal mit \\vmname\ zugreifen oder das Volume mit Windows-Boardmitteln als Laufwerksbuchstabe einbinden. Ganz so als wäre es ein anderer PC bzw. ein NAS.

Mir zum Beispiel würden sich allerdings ein paar Fragen ergeben, die vorher eine längere Recherche notwendig machen würden (oder jemand hier hat bereits Erfahrung):

1. Was passiert, wenn das ZFS denkt, er hat die Bytes tatsächlich auf der Festplatte geschrieben aber das Host-System der VM hat es tatsächlich noch nicht (Caches vs. "Atomic Writes" ...)? Ein System kann auch mal abstürzen.

2. Fehlersicherheit auf der Ebene des Netzwerkprotokolls (z.B. hier Samba)? Ist die Lösung gut genug und wenn nicht, welche Alternativen gäbe es?

3. Backup der ZFS-VM? Kopierst du einfach die ganze VM? Wenn ja, wird es jedes Mal sehr lange dauern, wenn viel Daten da sind. Das Backup-Medium sollte auch vor Bitrot sicher sein, sonst kann Bitrot das Backup befallen. Vorgehen?

4. Verschlüsselung? Soll verschlüsselt werden und wenn ja, auf welcher Ebene?

[Opprobrium]

Braucht man überhaupt so einen btrfs/md Treiber für Windows? Sollte das nicht durch das WSL (Windows Subsystem for Linux) geregelt werden?

[Trap]

Es gibt auch Tools um das manuell zu machen - z.B. https://github.com/Parchive/par2cmdline.

Im Dateisystem ist natürlich praktischer.

[myMind]

Ich habe gerade gelesen, dass es Bitrot gibt. Jetzt will ich handeln, hab aber keine Ahnung und auch keine lust ein NAS anzuschaffen. Wie kann ich Bitrot verhindern? :usad:

a) Teure Festplatte kaufen, die 1 zu 1015 Fehler hat und bei NTFS bleiben?

Das ist eine Möglichkeit. Relativ teuer.

b) ZFS nutzen? (Geht nur mit Linix/unbuntu)
c) ReFS nutzen? (Geht nur mit Win10 Enterprise oder Pro Workstation)

Beides kann man nutzen. Muss aber beides richtig konfiguriert werden. Also mit entsprechenden Redundanzen und dann leider auch mit entsprechendem Performanceverlust bei der Verarbeitung der redundant vorliegenden Informationen.

Kann ich z.B. um ZFS in meiner normalen Windows Umgebung nutzen zu können, eine virtual machine mit unbuntu anlegen und von dort ganz normal auch in Windows damit arbeiten oder sind dann alle Daten, die aus der VM kommen für Windows unbrauchbar?

Könntest Du theoretisch machen. Dazu benötigst Du dann z.B. mehrere virtuelle Volumes in einen raidz2. ZFS könnte die dann mit Mehrheitsentscheid im Falle eines Falles reparieren. Die Performance dürfte aber unterirdisch sein.

Wahrscheinlich schon oder? Und ein RAID-1 verhindert allein auch kein Bitrot?

Für ein RAID1 ist ein Bitrot eine Katastrophe. Fehler ist erkennbar (unterschiedlicher Wert), aber nicht behebbar (kein Mehrheitsentscheid aus Redundanz möglich). Von RAID1 mit großen HDDs würde ich daher abraten.

ReFS soll viele Nachteile haben im vergleich zu NTFS, stimmt das?

Es fehlen einige Features von NTFS, die in der Regel nicht benötigt werden. ReFS ist im Zusammenspiel mit Storage Spaces entstanden und soweit mir bekannt unterstützen sich beide Systeme gegenseitig. Beispielsweise hat ReFS zwar Reparaturmechanismen, aber die notwendige Redundanz für eine Reparatur muss in bestimmten Fällen aus dem darunterliegenden Speichersystem kommen. Einige Dinge hält aber auch ReFS redundant vor, um eine bessere Zuverlässigkeit zu gewährleisten.
Interessante Diskussion dazu: https://forums.veeam.com/veeam-backup-replication-f2/refs-data-corruption-detection-t53098.html
Besonders das Posting mit dem Powerhell-Skript ist interessant.
Das Stichwort ist hier "Integrity Streams".
Also kann ich nur eine teure Festplatte mit 1 zu 1015 kaufen, wenn ich mit NTFS vor Bitrot sicher sein will?
100% Sicherheit gibt es gar nicht. In gar keinem Fall. Die Auftrittswahrscheinlichkeit lässt sich durch Redundanzen drücken.

Ich würde mir die Frage stellen, ob ich überhaupt Daten habe, wo Bitrot für mich ein Problem darstellt. Also große Mengen von Daten, die keinesfalls beschädigt sein dürfen. Meiner Meinung nach hat man das häufig gar nicht. Mir fallen da zuerst die diversen Containerformate ein. Seien es Virutelle-Disks oder verschlüsselte Datencontainer. Besonders bei den verschlüsselten Containern, kann ich mir vorstellen, dass diese für Totalausfall anfällig sein könnten, wenn einzelne Bits umkippen.

Die Wahrscheinlichkeit, dass es ein einzelnes Familienfoto auf deiner gigantischen HDD mit NTFS Volumes trifft, ist extrem gering. Und wenn es passiert, ist es bei einem einzelnen Bild wirklich ein Weltuntergang?

Ein NTFS-Volume ist ggf. in den Verwaltungsstrukturen anfällig, aber auch da gibt es Redundanz. Ein Datenbackup sollte man sowieso haben.

Beispielsweise für eine Steam-Bibliothek, die über eigene Checksummernmechanismen abgesichert ist, ist Bitrot belanglos. Kann man immer wieder herunterladen.

Wo ich tatsächlich ein Problem sehe sind z.B. große Datastores für Virtualisierung. Da würde ich tatsächlich zu ZFS mit entsprechender Redundanz greifen oder zu Hardware RAID mit passendem RAID-Level. Spätestens bei 8TB HDDs würde ich nicht mehr unter RAID6 gehen. Mein Heim-ESX habe ich genau deshalb, beim letzten Upgrade von RAID5 auf RAID6 umgebaut.

Damit man Bitrot erkennen und reparieren kann, muss man die redundant vorliegenden Daten regelmässig lesen und schauen, ob die Prüfsummen stimmig sind (data scrubbing). Das können alle entsprechenden Systeme ZFS, btrfs und ReFS. Und auch bei namhaften RAID-Controllern ist ein Data-Scrubbing Standard.

Auf einem Client-PC sehe ich nicht, was man da groß machen sollte, außer wie schon vorgeschlagen gute Disks zu kaufen. Die Wahrscheinlichkeit, dass ich mit komplizierten RAID-Setups meine Daten ins Nirvana schicke ist meiner Meinung nach größer als potentielle Bitrot-Probleme. Lieber KISS.

Wenn ich im Heim-Bereich das Problem sehe, z.B. wegen Datenverschlüsselungscontainern o.ä., dann würde ich ein NAS kaufen und mit RAID6 betreiben. Das ist einigermaßen Handhabbar und bietet mehr Ausfallsicherheit in jeder Richtung.

Backups helfen leider nur dann, wenn man das Bitrot auch bemerkt. Stellt man nach 5 Jahren fest, das ein Bild kaputtgegangen ist, braucht man schon ein sehr gutes Langzeitbackup.

Mit der Cloud ist es auch so eine Sache. Da müsste man vom Betreiber schon entsprechende Zuverlässigkeitsaussagen zur Datenspeicherung bekommen, was in der Regel nicht der Fall sein wird. Die Cloud-Betreiber haben das Problem auch und ob und was sie dagegen tun ist idR nicht transparent.

[Dr. Lars Sahmströhm]

Ich würde mir die Frage stellen, ob ich überhaupt Daten habe, wo Bitrot für mich ein Problem darstellt. Also große Mengen von Daten, die keinesfalls beschädigt sein dürfen. Meiner Meinung nach hat man das häufig gar nicht. Mir fallen da zuerst die diversen Containerformate ein. Seien es Virutelle-Disks oder verschlüsselte Datencontainer. Besonders bei den verschlüsselten Containern, kann ich mir vorstellen, dass diese für Totalausfall anfällig sein könnten, wenn einzelne Bits umkippen.

Ich möchte gern eine 4TB Festplatte oder zwei im Raid-1 (dachte an WD Red, aber die haben alle nur 1014) auf der ich ein Backup (Fotos, Dokumente ect.) meiner persönlichen Daten ablege (zusätzlich mehrfach auf externen), aber auch etwa 2-3TB Videomaterial liegen habe in diversen Cointainerformaten wie Mp4, Mkv ect. und damit Videoschnitt betreibe. Die Files reichen hierbei von kurzen Clips mit ein paar Minuten bis hin zu 8-12GB großen 4K-Videos.


a) Wie schlimm ist Bitrot bei Videos überhaupt? Gibt das nicht höchstens ein paar defekte Frames, die von den Playern ausgeglichen werden (Bild zeigt kurzes Artefakt oder zuckelt kurz)?

b) Die günstigste 4TB-HDD mit 1015 ist die WD Ultrastar 310 (ehemals HGST) welche ca. 170 Euro kostet. Das ist auch die einzige in dem Preisbereich überhaupt. Alle WD Reds, sogar Gold haben das nicht. Auch alle IronWolf Seagates nicht, erst ab der 8GB Version (250€). Spricht etwas gegen die Ultrastar, außer, dass sie grauenhafte RMA-Werte bei mindfactory hat (4,27%) https://www.mindfactory.de/product_info.php/4000GB-WD-Ultrastar-DC-HC310-0B35950-256MB-3-5Zoll--8-9cm--SATA-6Gb-s_1247638.html?
c) Für jemandem mit wenig Ahnung von VMs/Linux ect. scheint mir ReFS noch am einfachsten zu sein.
Gibt es eine Möglichkeit ein Laufwerk mit ReFS zu formatieren, bzw. so einen storage pool anzulegen, ohne Win10 Enterprise benutzen zu müssen? (das hat z.B. kein DX12&HDR für Games)
d) Wenn die Steam-Bibliothek checksummengeprüft ist, gibt es dann nicht auch andere Software, die wie eine art Virenscanner durch meine Dateien pflügt und auf Checksummen prüft oder ist das per Definiton mit NTFS nicht möglich, auch nicht mit einer "Guard-App" oder sowas.

[PatkIllA]

Du machst dir viel zu viel Gedanken um Bitrot und der Rest kommt zu kurz.

Nur ein Backup? Am besten noch im gleichen Gebäude und dauerhaft angeschlossen. Da lieber auf mehr Redundanz statt diverser RAID Mode setzen.
Was ist mit Blitzschutz, Feuer, Diebstahl, Versehentlichem Löschen, Verschlüsselungstrojaner etc.

Du kannst jederzeit alle Dateien auf Platte einlesen. Wenn die noch eingelesen werden können, dann sind sie mit sehr hoher Wahrscheinlichkeit noch in Ordnung. Die Festplatte hat selbst auch Prüfsummen für Datenintegrität und das falsche Daten werden sehr zuverlässig erkannt. Aber halt nicht korrigiert.

[Loeschzwerg]

Für Langzeitarchivierung von Bildern und Dokumenten kann man auch einfach auf M-Disc setzen. Je nachdem mehrere Medien brennen und sauber getrennt lagern. Fertig bearbeitete Videos gehen damit auch, brauchst halt ein paar mehr Scheiben.

Für aktive verwendete Daten reicht ein NAS, da würde ich mir keine sonderlichen Gedanken über Bitrot machen.

[myMind]

Ich möchte gern eine 4TB Festplatte oder zwei im Raid-1 (dachte an WD Red, aber die haben alle nur 1014) auf der ich ein Backup (Fotos, Dokumente ect.) meiner persönlichen Daten ablege (zusätzlich mehrfach auf externen), aber auch etwa 2-3TB Videomaterial liegen habe in diversen Cointainerformaten wie Mp4, Mkv ect. und damit Videoschnitt betreibe. Die Files reichen hierbei von kurzen Clips mit ein paar Minuten bis hin zu 8-12GB großen 4K-Videos.

a) Wie schlimm ist Bitrot bei Videos überhaupt? Gibt das nicht höchstens ein paar defekte Frames, die von den Playern ausgeglichen werden (Bild zeigt kurzes Artefakt oder zuckelt kurz)?

Die Codierungsformate (mpeg) werden auf Discs und auch für Fernübertragungen genutzt und gelten als sehr robust. Da würde ich mir wenig sorgen machen. Es kann theoretisch natürlich auch eine Headerinformation treffen, die für den Container sehr wichtig ist, aber die Wahrscheinlichkeit ist extrem gering, da die Header klein gegenüber den Nutzdaten sind. Im Normalfall wird es bei Mediendateien vermutlich so ausgehen wie in diesem Test: Bitrot bei JPG-Dateien, wirklich so dramatisch? (https://linuxundich.de/gnu-linux/bitrot-bei-jpg-dateien-wirklich-dramatisch/)


b) Die günstigste 4TB-HDD mit 1015 ist die WD Ultrastar 310 (ehemals HGST) welche ca. 170 Euro kostet. Das ist auch die einzige in dem Preisbereich überhaupt. Alle WD Reds, sogar Gold haben das nicht. Auch alle IronWolf Seagates nicht, erst ab der 8GB Version (250€). Spricht etwas gegen die Ultrastar, außer, dass sie grauenhafte RMA-Werte bei mindfactory hat (4,27%) https://www.mindfactory.de/product_info.php/4000GB-WD-Ultrastar-DC-HC310-0B35950-256MB-3-5Zoll--8-9cm--SATA-6Gb-s_1247638.html?

https://www.backblaze.com/b2/hard-drive-test-data.html

c) Für jemandem mit wenig Ahnung von VMs/Linux ect. scheint mir ReFS noch am einfachsten zu sein.
Gibt es eine Möglichkeit ein Laufwerk mit ReFS zu formatieren, bzw. so einen storage pool anzulegen, ohne Win10 Enterprise benutzen zu müssen? (das hat z.B. kein DX12&HDR für Games)

Du benötigst einen Storage Pool mit mindestens dual-parity oder three-way mirror. Das willst Du auf deinem Client-PC nicht haben. Das führt nur zu komplizierten Dingen und in der Summe viel höheren Datenverlustwahrscheinlichkeiten, als es Bitrot bei deiner kleinen Datenmenge je bewirken könnte.

d) Wenn die Steam-Bibliothek checksummengeprüft ist, gibt es dann nicht auch andere Software, die wie eine art Virenscanner durch meine Dateien pflügt und auf Checksummen prüft oder ist das per Definiton mit NTFS nicht möglich, auch nicht mit einer "Guard-App" oder sowas.

Wenn Du ein Verzeichnis hast, wo stabile Mediendaten liegen, wäre es eine Möglichkeit da regelmäßig Checksummen zu berechnen. Bei Abweichung hättest Du einen Bitrot-Fall (oder ein wildgelaufenes Medienprogramm hat mal wieder ungefragt Daten geändert). Dann aus dem Backup wiederherstellen mit Prüfung gegen die als gültig bekannte Checksumme.

Bei 4TB würde ich persönlich mir noch keine Gedanken machen. Ich denke dass die realen Werte viel niedriger liegen als die Herstellerangaben. Das wird hier auch nahegelegt: The case of the 12TB URE: Explained and debunked (https://heremystuff.wordpress.com/2020/08/25/the-case-of-the-12tb-ure/). Ist ja nicht so, dass die Foren voll sind von Leuten, die irgendwelche Dateien nicht mehr lesen können.

[Dr. Lars Sahmströhm]

Update:
Wie das Leben so spielt, ist mir kurz nach Erstellung dieses Threads nun meine externe 2TB Festplatte (ohne Backup) dabei den Geist aufzugeben. Ich habe sie auch mißbraucht, sie lief jahrelang quasi als interne Platte dauerhaft eingesteckt.

Ich bin gerade damit beschäftigt mit "Roadkils unstoppable copier" meine Daten runter zu ziehen. Etwa jede 6-7. Datei ist so defekt, dass es eine Stunde oder länger dauern kann um sie zu rekonstruieren, aber es geht!
Wer das Programm nicht kennt, es ist ein Geheimtipp. Ich habe damit auch früher schon Daten von Festplatten gerettet, die in Windows nicht mal mehr eine Ordnerstruktur angezeigt haben. :up:

Dabei ist mir folgendes aufgefallen, auch in Bezug auf Bitrot.

a) Roadkils unstoppable copier schafft es teilweise Daten mit tausend(!) Lesefehlern zu vollenden und dabei eine Dateiintegrität von 100% herzustellen. Wie das möglich ist, bleibt mir ein Rätsel. Was passiert denn, wenn ich eine "Bitrot-angefressene" Datei mit Roadkils Programm kopiere, dann korrigiert doch Roadkil automatisch meine Bitrot-Datei oder nicht? :rolleyes:

b) Selbst Dateien mit mehreren tausend Fehlern kann Roadkil noch mit einer Dateiintegrität von ca. 98%+ kopieren. Ich habe in diesen Files (Videos) bisher auch noch keine Fehler gefunden. Sie lassen sich normal mit VLC anschauen, vor und zurückspulen, in Videobearbeitungssofware einlesen und bearbeiten. :eek:


Irgendwie macht mir Bitrot jetzt keine Angst mehr. Ich glaube ich werde 2x4TB WD Reds kaufen und die nicht im Raid-1 laufen lassen, wie ursprünglich geplant, sondern eine davon vom Strom abklemmen und nur ab und an anstecken und ein Komplettbackup der anderen darauf spielen (ich könnte auch eine externe 4TB als backup HDD nehmen, aber ich denke eine WD red ist haltbarer auf Sicht). Vor diesem Backup werde ich von allen Dateien mit "QuickSFV (https://www.quicksfv.org/)" eine .sfv anlegen, um eine CRC30 Prüfsumme gegen Dateiveränderung gegen Bitrot oder Hacker zu haben. So bin ich auch sicher, falls ein Blitzschlag meinen Rechner trifft, das bin ich mit Raid-1 nämlich nicht, wenn beide gleichzeitg kaputt gehen. Für die allerwichtigsten Daten werde ich eine externe 1TB-SSD kaufen, die als besonders lange haltbar gilt (Samsung T5 oder T7) und die bei einem Freund in der Wohnung aufbewahren. So sollte ich auch sicher sein, falls ein Brand ausbricht oder ein Dieb alles mitnimmt. Diese allerwichtigsten Daten wären dann auf mindestens 3 HDDs gesichert, alle zweitwichtigsten Daten auf mindestens 2 HDDs.

Einwände/Vorschläge?

[Rooter]

Ich habe hier nach 3 Jahren die intere Platte und die Backup-Platte getauscht. Das verteilt die Laufzeit.

Unter Linux gibt es übrigens die Tools ddrescue bzw. Gddrescue, die wohl dasselbe leisten wie Unstoppable Copier.

Wenn du neue Platten kaufst, vielleicht nicht unbedingt aktive und Backup zusammen kaufen. Im worst case liefen die binnen 2 Minuten vom selben Band und haben potentiell dieselbe Lebensdauer. Hatten wir in der Firma mal: Ein Platte des RAID fiel aus, man lies es dann mit der einen Platte weiter laufen bis der Ersatz geliefert wurde. Zwei Tage später fiel die andere auch aus, da gab es nur noch das Backup und die Firma stand für paar Tage quasi still. X-D

MfG
Rooter

[Dr. Lars Sahmströhm]

Ich habe hier nach 3 Jahren die intere Platte und die Backup-Platte getauscht. Das verteilt die Laufzeit.

Wenn du neue Platten kaufst, vielleicht nicht unbedingt aktive und Backup zusammen kaufen. Im worst case liefen die binnen 2 Minuten vom selben Band und haben potentiell dieselbe Lebensdauer. Hatten wir in der Firma mal

Danke, so werde ich es auch machen. Ich werde eine WD Red mit SMR Technik kaufen als Backup-Platte und eine WD Red Plus mit CMR Technik als Arbeitsplatte, weil dort auch mit gearbeitet wird (Videoschnitt) und CMR soll schnellere Schreibvorgänge haben, während SMR schneller einlesen kann und mehr Cache hat.

Oder ist es nicht eher so, dass für Videoschnitt das Einlesen wichtiger ist, als das Schreiben? Geschrieben/Gerendert wird ja am Ende auf die Betriebsystem-SSD. Dann wäre die SMR-Platte evtl. doch besser?


WD Red (SMR) : 256MB Cache, 200G max
WD Red Plus (CMR): 128MB Cache, 175G max


Die SMR Platten werden vorallem gemieden, weil sie schlecht für Raids sind (Wiederherstellung dauert 12x so lang wie CMR), aber als Singledisk könnten sie sogar Vorteile haben gegenüber CMR wegen des Mehr an Cache und Bandbreite. Ich weiß aber nicht, welches davon besser in Sachen Langzeithaltbarkeit ist. Gelesen habe ich, dass der Schreib/Lesekopf bei SMR kleiner ist und kleiner heißt für mich, dass es eher kaputt geht. Außerdem werden bei der SMR-Technik größere Bereiche der Disk gebündelt beschrieben, weswegen sie effizienter ist, aber heißt das nicht, dass bei einem Defekt der Platte auch mehr Daten gleichzeitig defekt werden und nicht mehr so viel gerettet werden kann?! :rolleyes:

Kennt sich jemand aus?

[Rooter]

SMR meide ich generell wie der Teufel das Weihwasser! Evt. für Backups, da muss man aber auch viel Zeit haben...

MfG
Rooter

[Dr. Lars Sahmströhm]

SMR meide ich generell wie der Teufel das Weihwasser! Evt. für Backups, da muss man aber auch viel Zeit haben...


Könntest du das etwas ausführen? Wegen der Raid-Problematik oder weil du sie generell für minderwertiger/weniger haltbar hälst?
Laut dem Chip.de Test hat die SMR eine Schreibgeschwindigkeit von 188, das ist mehr als die CMR Platte. Wieso sollte ein Beschreiben dann länger dauern?

[Rooter]

Lies das hier. Würde ich nicht haben wollen so ein Gedöns.

https://de.wikipedia.org/wiki/Shingled_Magnetic_Recording

MfG
Rooter

[jellyfish]

Also das mit den Festplatten und der Ausfallsicherheit ist einfach eine Glück- bzw. Pechsache. Ich hatte schon teure Festplatten, die den Geist aufgegeben haben und OEM-Platten, die nach 10 Jahren immer noch ohne einen einzigen Fehler liefen und nur aus Kapazitäts- oder Technologiegründen ausgemustert wurden.

Bei den ca. 30 Platten, die ich bisher hatte, konnte ich bisher noch nie Bitrot feststellen.
* 4-5 Festplatten bisher Totalausfall (sprangen nicht mehr an, man hörte nur ein Klacken), davon eine nach Stromausfall - Zufall kann das nicht gewesen sein. Ein klackte nur.
* 2 Festplatten, bei der die Anzahl der defekten Sektoren allmählich zunahm.
* 1 Festplatte, wo diese zwar defekte Sektoren nach "Reparatur" durch Überschreiben wieder als gut meldete, diese aber nach kurzer Zeit und nochmaliger Überprüfung wieder defekt waren.
* 2-3 Festplatten, welche defekte Sektoren hatten, die sich nicht reparieren ließen. Ich habe diese sogar noch im Einsatz, die Anzahl der defekten Sektoren hat nicht zugenommen.

Mein persönliches Fazit:
* Duplikate der Backups sind wichtig.
* Plötzlicher Totalschaden tritt öfter auf als graduelle Verschlechterungen.
* Defekte Sektoren heißt nicht unbedingt, dass man die Festplatte gleich in die Tonne werfen muss. Die Anzahl kann über eine lange Zeit unverändert bleiben.
* Regelmäßiges Prüfen/Neuschreiben ist zeitaufwändig, aber sehr empfehlenswert.
* Backup auf Remote-Rechner ist wahrscheinlich keine schlechte Idee. Ich mach das mit den wichtigsten Daten, die landen alle alle paar Monate auf einem Zweitrechner an meinem Nebenwohnsitz. Kann ja mal brennen oder Flut kommen oder jemand einbrechen und alles kaputt machen. Dafür benutze ich aber keine Cloud. Die kann genau so plötzlich und unverhofft weg sein, und ein Upload würde mir sowieso zu lange dauern.

Ich habe es mir angewöhnt, die Backup-Festplatten mit den wichtigsten Daten einmal im Jahr oder alle zwei Jahre neu schreiben zu lassen. badblocks is your friend. Dabei werden Fehler festgestellt, aufgezeigt und im Bedarfsfall repariert. Ich hab dann eine Reserveplatte zum Vergleichen.

[Badesalz]

Ich habe gerade gelesen, dass es Bitrot gibt. Jetzt will ich handeln, hab aber keine Ahnung und auch keine lust ein NAS anzuschaffen. Wie kann ich Bitrot verhindern? :usad:

a) Teure Festplatte kaufen, die 1 zu 1015 Fehler hat und bei NTFS bleiben?
b) ZFS nutzen? (Geht nur mit Linix/unbuntu)
c) ReFS nutzen? (Geht nur mit Win10 Enterprise oder Pro Workstation)b wäre mir neu. An sich ist das bisher eher die Domäne von FreeBSD und OpenSolaris forks.

[Benutzername]

b wäre mir neu. An sich ist das bisher eher die Domäne von FreeBSD und OpenSolaris forks.


ZFS läuft mittelrweile gut genug auf Linux, daß man damit schon einen Server aufsetzen kann. QNAP bietet da zum Beispiel was fertig an. Würden die nciht tun, wenn es einem dauernd um die Ohren flöge: https://www.qnap.com/quts-hero/de-de/


Aber natürlich läuft es imernoch besser mit BSD und Solaris. Um die Lizenzierung herumzuprogrammieren oder ZFS in einen selbstgebauten Linux Kernel zu patchen ist auch nicht so dolle.

[fezie]

https://www.proxmox.com/de/proxmox-ve/funktionen

Proxmox nutzt auch ZFS. Und das basiert auf Debian

[Badesalz]

QuTS hab ich ja schon gehört, aber nicht weiter verfolgt. Interessant... da QES (Qnap Enterprise Storage) ja auch mit ZFS kommt und auf FreeBSD basiert ;) Als ich dann "Mit dem intuitiven QTS-Betriebssystem bietet QES [...]" gelesen habe, war mir das mal zu verschwurbelt um mir das durchzulesen (da ich QuTS nicht brauche).

Das Wort nativ nimmt man bisher aber eher nur bei FreeBSD und "Solarish"/Illumos. Wobei ich glaub nicht, daß man das auch einfach so auf einem Desktop ala Workstation fahren will. Oder einem NUC oder sowas :tongue:
Von daher ist das alles nicht so signifikant wichtig, IMHO. Wenn ich ein "storage" bauen will und das nicht Unraid sein sollte, dann ist das XigmaNAS oder TrueNAS. Ich glaub nicht, daß es da wichtig ist was für ein MS-unverseuchter Kernel (OS) da waltet, da sich FreeBSD auch an keiner Stelle verstecken muss. Vor allem nicht was Stabilität angeht.

Wenn was aber nicht Windows ist, dann sollte alles irgendwie Linux sein, findet man wohl =) und davon kommt das wohl auch. Bei Proxmox für Replicas ist das halt auch nicht verkehrt. Schon ok.

BITROTS =) Gab es da nicht eine Reihe, eine zugegeben recht kurze, an Tools, welche Dateien in place gelesen und wieder schrieben? Wenn das 1x durch ist, hat man wieder 6 Jahre Ruhe...

Auf HDDs ist das Problem übrigens recht einfach zu 99% zu lösen: Man defragmentiert wenigstens 1x im Jahr.
Auf SSDs ist das größtenteils ein Problem mit TLC und steigt mit höheren Betriebstemperaturen. Das konnte man angeblich auch gut mit den 840er Evos lernen (?) die Fw Updates wohl nur wegen dem Handling von Bitrot bekamen (?)

[jellyfish]

BITROTS =) Gab es da nicht eine Reihe, eine zugegeben recht kurze, an Tools, welche Dateien in place gelesen und wieder schrieben? Wenn das 1x durch ist, hat man wieder 6 Jahre Ruhe...
6 Jahre sicher nicht, außer du hast sie ständig online. Länger als 2 Jahre würde ich die nicht wo rumstehen lassen, und das könnte schon zu lange sein. Besser einmal im Jahr neu beschreiben, das dauert je nach Größe eben einen Tag oder etwas mehr. Geeignete Tools sind z.B. badblocks unter Linux mit seinem nicht-zerstörenden Lese-/Schreibtest. Das reicht als Auffrischung. Für Windows gab es sowas ähnliches, ich glaub es hieß diskfresh.

S.M.A.R.T. Extended Tests tun es auch und sind natürlich schneller, aber wenn es Fehler gibt dann hört der Test sofort auf und man muss es nach Beheben von vorne machen. Wenn der Test 6h läuft und dann wieder von vorn begonnen werden muss ist das nicht lustig.

Oder der Test bleibt hängen bei 90% und wird nicht fertig bei Fehlern. Also nur bedingt zu gebrauchen.
Die meisten Festplatten melden aber, wenn sie einen schwachen Sektor nicht mehr garantiert fehlerfrei auslesen kann. Das sieht man dann im S.M.A.R.T. Error Log.

Auf HDDs ist das Problem übrigens recht einfach zu 99% zu lösen: Man defragmentiert wenigstens 1x im Jahr.
Beim Defragmentieren werden nicht alle Daten neu geschrieben.

Auf SSDs ist das größtenteils ein Problem mit TLC und steigt mit höheren Betriebstemperaturen. Das konnte man angeblich auch gut mit den 840er Evos lernen (?) die Fw Updates wohl nur wegen dem Handling von Bitrot bekamen (?)
Abgesehen von den 840er Evos wurde das Problem mit Bitrot aber übertrieben. Die halten auch länger als ein Jahr ohne Strom. Es gibt im Internet irgendwo Artikel, dass die Behauptung mit dem Bitrot eine Fehlinterpretation war. Oder nur bei extrem hohen Temperaturen (Transport in der Wüste oder so, wer macht sowas schon). Kann sie jetzt nicht mehr finden.

Es gibt einfach nichts zuverlässigeres als Backups auf mehrere Platten zu verteilen. Tritt auf einer ein Fehler auf, hat man immer noch eine weitere zum Vergleichen und Korrigieren.

[Acid-Beatz]

@jellyfish: Full Ack - bevor man sich Gedanken über Bitrot machen sollte, sehe ich 10000 wahrscheinlichere Möglichkeiten, dass die Daten auf andere Art und Weise zerstört werden, egal ob die SSD/HDD plötzlich den Geist aufgibt oder man die Daten durch eine falsche Regex löscht - um ein Backup kommt man so oder so nicht rum ^^

[Dr. Lars Sahmströhm]

Ganz so einfach ist es nicht. Ich hab z.B. einige alte Familienfotos, die schon bestimmt 6x die HDD gewechselt haben im Verlauf der letzten 15-20 Jahre und dort sind einige Bilder teils defekt geworden und ich konnte mir nie erklären woran das lag. Sowas kannte ich eigtl. immer nur von zerkratzen CDs/DVDs, bis ich auf das Thema Bitrot gekommen bin.

Deswegen lege ich jetzt vor jedem Backup mit Quicksfv eine .sfv Datei an wo ich Prüfsummen aller Dateien vergleiche. Das geht mit einem Klick. Sobald eine defekte auftaucht, wird sie vom Backup auf der Main ersetzt und anschließend der Gesamtinhalt wieder von der Main aufs Backup geschrieben.

[Badesalz]

Ganz so einfach ist es nicht. Ich hab z.B. einige alte Familienfotos, die schon bestimmt 6x die HDD gewechselt haben im Verlauf der letzten 15-20 Jahre und dort sind einige Bilder teils defekt geworden und ich konnte mir nie erklären woran das lag.So in etwa? https://en.wikipedia.org/wiki/Data_degradation

Auch in diesem Thread lernen wir, daß wenn Leute eine klare Meinung haben und sie gar omnipotent darlegen, das keinerlei Indiz dafür sein sollte, daß sie Ahnung haben...
Full Acks z.B., taugen ausschliesslich dafür um als Muster auf Toilettenpapier gedruckt zu werden.

[Acid-Beatz]

Dann wünsche ich viel Spaß dabei, wenn Ihr irgendeine halbfertige ZFS Lösung einsetzt weil der böse Bitrot bedroht ja alle Daten und am Schluss ist dann alles weg, weil ZFS macht das schon - dachte man zumindest :tongue:

[ChaosTM]

Hab ein paar alte HDDs mittlerweile seit 12 Jahren herumstehen und die sind auch noch problemlos lesbar. Ist aber außer Pr0n und ein paar alter Serien nix wichtiges drauf.

Persönlich wirklich essentielle Dingen liegen auf mindestens 2 HDDs. Raid Verbunden traue ich sein einem 12TB Totalausfall von vor ein paar Jahren auch nicht mehr wirklich.

Die ganze wichtigen Sachen kommen zusätzlich alle paar Monate auf DVDS - das sind runde Uraltmedien im Scheibenform die man beschreiben kann ;)

[Badesalz]

Dann wünsche ich viel Spaß dabei, wenn Ihr irgendeine halbfertige ZFS Lösung einsetzt weil der böse Bitrot bedroht ja alle Daten und am Schluss ist dann alles weg, weil ZFS macht das schon - dachte man zumindest :tongue:Woher willst DU denn wissen welche ZFS-Lösung halbfertig ist? Weißt du da mehr als ich?
Ok, Linux und ZFS, nein. Was aber überhaupt keine Notwendigkeit hat. Und sonst?

Und was ist, wenn man vom ZFS-Pools Backups macht, und nicht von NTFS oder Ext3? Macht das irgendwas schlimmer/gefährlicher?

[Backbone]

Wenn das wirklich ein Thema ist kann man ein NAS nutzen das ein passendes FileSystem mitbringt. Das ist bei Synology der Fall: https://www.synology.com/de-de/dsm/Btrfs
Diese NAS können dann auch noch vollautomatisch in die Cloud replizieren, etwa zu AWA oder OneDrive. Damit sollte es dann keine Probleme mehr geben.

[Badesalz]

Das ist genau das was man unbedingt machen will. Seine Daten vollautomatisch von einem closed FertigNAS in eine Cloud schieben :uup: Das Thema war übrigens nicht, Backups. Backups haben damit nichts zu tun, da sie die Bitflips wortlos multiplizieren. Backups schützen nicht gegen kaputte Daten, sondern kaputte Datenträger.

Btrfs bei Synology läuft weiterhin so, daß man dann zwar eine gesicherte Datenintegrität haben kann, aber weniger eine Hardwaresicherheit. Bzw. ist sie teuerer erkauft (nur Soft Raid1?) Wenns um Btrfs und Raid geht, auf DSM, füllt das etliche Wikiseiten komplett...
Und ohne einer USV sollte man Synology und Btrfs auch niemals betreiben (!)

Einerseits. Andererseits, und da merkt man sofort wohin die Reise geht, entsteht bei Google ein Bitflip auf 8% der Speichermodule pro Jahr und ist damit 8x öfters detektierbar als auf Datenträgern. HDs sind da schon relativ weit mit der Selbstkontrolle (mal nach WD und Reed-Salomon suchen).
Wenn die Bits dagegen im non-ECC Speicher kippen, merkt das Dateisubsystem nichts davon.

ZFS wie auch den Btrfs-Clon auf einer Kiste ohne ECC-RAM zu betreiben ist also Marketing für ahnungslose Laien. Auf Gutdeutsch, eine Verarsche.
Das ist sowas wie einen C180 Benz, für Bremsscheiben vom C63s umbauen, aber die Bremssattel vom C180 behalten.

Die Entscheidung von Qnap mit so einem Schwachsinn nicht rumhausieren und ZFS nur auf den Boxen anzubieten die auch die Hardware dafür haben, ist richtig.

[Acid-Beatz]

Woher willst DU denn wissen welche ZFS-Lösung halbfertig ist? Weißt du da mehr als ich?
Ich denke nicht aber im Eingangspost ist schon mal von ZFS und Ubuntu die Rede, was meines Wissens nach immer noch nicht für den produktiven Einsatz freigegeben ist. Und selbst wenn dem so sein sollte, wird es nicht in der breiten Masse eingesetzt, womit die Gefahr unerkannter Fehler eben doch höher ist, als bei Dateisystemen, die auf Millionen von Servern laufen.

Versteh mich nicht falsch, ZFS ist auf Solaris Maschinen eine absolut geile Sache, vor allem im Zusammenspiel mit SAM-QFS aber speziell für diese Hardware wurde es entwickelt und ausgiebig getestet und es kam eben ALLES von Sun.

Und wie Du dann auch selber schreibst, kommen noch andere Faktoren dazu, die man haben MUSS, weil man sich den Spaß sonst auch sparen kann:

ZFS wie auch den Btrfs-Clon auf einer Kiste ohne ECC-RAM zu betreiben ist also Marketing für ahnungslose Laien. Auf Gutdeutsch, eine Verarsche.
Das ist sowas wie einen C180 Benz, für Bremsscheiben vom C63s umbauen, aber die Bremssattel vom C180 behalten.


Konkret korrigiere ich meine Aussage somit zu: "ZFS schützt vor Bitrot, wenn man es in einer zertifizierten Umgebung betreibt, am besten auf SUN/Solaris oder zur Not FreeBSD"

[Badesalz]

Ich denke nicht aber im Eingangspost ist schon mal von ZFS und Ubuntu die Rede, was meines Wissens nach immer noch nicht für den produktiven Einsatz freigegeben ist.Dem hab ich dachte ich, direkt gegengearbeitet (?) Der Kollege hat noch keinen nötigen Infoschatz. Er schriebt ja sogar: geht NUR mit Linux/Ubuntu.
Wobei seine Schreibweise gignatisch cooler ist. Wortwörtlich "Linix/unbuntu"
:biggrin:

Suns/Solaris ist nicht mehr. Es gibt das umgangssprachlig benannt Solarish bzw. Illuminos und es gibt FreeBSD.
Was das Storage selbst angeht, hinkt FreeBSD dem mit nichts nach, was man DAHEIM ausfahren könnte.

Man braucht natürlich keine ZFS-zertifizierte ECC Speicherriegel. Normale ECC Module reichen :usweet:

[PatkIllA]

So in etwa? https://en.wikipedia.org/wiki/Data_degradation

Auch in diesem Thread lernen wir, daß wenn Leute eine klare Meinung haben und sie gar omnipotent darlegen, das keinerlei Indiz dafür sein sollte, daß sie Ahnung haben...
Full Acks z.B., taugen ausschliesslich dafür um als Muster auf Toilettenpapier gedruckt zu werden.Und gibt es da Zahlen wie oft sowas auftritt? Das klingt doch eher nach dem dass vor dem Schreiben ein Bit im Arbeitsspeicher umgekippt ist. Festplatten haben sehr aufwändige Korrekturen, die das unbemerkte Umkippen von ein paar Bits fast unmöglich machen. Nicht mehr lesbare Sektoren sind mir schon öfters untergekommen. Umgekippte Bits bei Dateien, die schon mal gingen noch nie.

ZFS wie auch den Btrfs-Clon auf einer Kiste ohne ECC-RAM zu betreiben ist also Marketing für ahnungslose Laien. Auf Gutdeutsch, eine Verarsche.
Was ist denn aus Sicht der Datenintegration bei ZFS ohne ECC schlechter als bei "normalem" Dateisystem ohne ECC?
Die Prüfsummen und Korrekturmöglichkeiten gehen doch weiterhin.

[Badesalz]

Und gibt es da Zahlen wie oft sowas auftritt?Laut dem ersten Gesetz der Stochastik:
Extrem selten und immer nur dann, wenn du es am wenigstens gebrauchen kannst und immer nur bei der Datei von der du
a) kein Backup hast
b) nur ein Backup hast wo der Bitflip schon dabei ist.

Handfest genug?

Zum Rest, hast du fast soweit Recht. Daher gibt es auch das Erste Threadgesetzt:
Wenigstens die Seite zu Ende lesen bevor man auf irgendeinen Beitrag aus der Mitte antwortet.

Was du da zum Besten geben wolltest wurde nämlich schon geklärt...
Was ist denn aus Sicht der Datenintegration bei ZFS ohne ECC schlechter als bei "normalem" Dateisystem ohne ECC?Nichts. Daher könnte bzw. sollte man in dem Fall auch "normale" Dateisysteme nehmen, da man sonst in Versuchung kommen kommt sich auf einige Eigenschaften von ZFS zu verlassen, die ohne ECC-Speicher eine Lotterie sein können.

[PatkIllA]

Handfest genug?Ehrlich gesagt nein. Du kannst auch nach dem Sechser im Lotto vom Blitz getroffen werden.

Für die einfachen fehler erkennenden/korrigierenden Algorithmen habe ich sowas früher als Übung mal durchgerechnet und das war praktisch ausgeschlossen.

Nichts. Daher könnte bzw. sollte man in dem Fall auch "normale" Dateisysteme nehmen, da man sonst in Versuchung kommen kommt sich auf einige Eigenschaften von ZFS zu verlassen, die ohne ECC-Speicher eine Lotterie sein können.Ohne ECC-Speicher ist alles eine Lotterie und verlassen kann man sich eh auf nichts.
Man kriegt das was der TE mit den sfv Dateien händisch macht geschenkt und Korrekturmöglichkeiten gibt es gratis dazu. Schon außerhalb vom Dateisystem, wird der RAM um Größenordnungen öfter geschrieben und geschrieben und bietet Möglichkeiten von Fehler, die ohne ECC komplett untergehen.

[jellyfish]

Das ist genau das was man unbedingt machen will. Seine Daten vollautomatisch von einem closed FertigNAS in eine Cloud schieben :uup: Das Thema war übrigens nicht, Backups. Backups haben damit nichts zu tun, da sie die Bitflips wortlos multiplizieren. Backups schützen nicht gegen kaputte Daten, sondern kaputte Datenträger.


Diese Behauptung ist pauschal sicher nicht haltbar. Selbst wenn ich rsync mache von einer Backup-Platte auf die andere, werden nur neue bzw. veränderte Dateien kopiert. Bei den alten kann nach deinen Überlegungen ein Bitflip passiert sein, aber die werden als nicht verändert behandelt und somit nicht mit kopiert. Eventuell macht man aber gar kein rsync von Backup-Platten. Vielleicht macht man jeweils ein rsync von der Quelle auf die Backup-Platten. Es kommt also sehr auf die Art des Backups an, ob hier was "multipliziert" werden kann oder nicht.

[Acid-Beatz]

Dem hab ich dachte ich, direkt gegengearbeitet (?) Der Kollege hat noch keinen nötigen Infoschatz. Er schriebt ja sogar: geht NUR mit Linux/Ubuntu.
Wobei seine Schreibweise gignatisch cooler ist. Wortwörtlich "Linix/unbuntu"
:biggrin:
Gignatisch :naughty:
Sorry aber der musste bei dieser Vorlage raus :D

Ich kann Dir meine genauen Gedankengänge leider nicht mehr schildern und habe Dich einfach missverstanden aber ich dachte der Thread geht in die Richtung "Nimm ZFS und selbst wenn es noch Alpha Status hat, ist es 1000x besser wie NTFS/whatever und schützt Deine Daten auch vor Atombombenexplosionen"

War wohl mein Fehler, sorry ;)



Suns/Solaris ist nicht mehr. Es gibt das umgangssprachlig benannt Solarish bzw. Illuminos und es gibt FreeBSD.
Was das Storage selbst angeht, hinkt FreeBSD dem mit nichts nach, was man DAHEIM ausfahren könnte.

Man braucht natürlich keine ZFS-zertifizierte ECC Speicherriegel. Normale ECC Module reichen :usweet:

Auch hier Fehler meinerseits, mir war nicht bewusst, dass ZFS auf FreeBSD mittlerweile so ausgereift ist ;)

Ich habe halt nur noch in (sehr, sehr guter!) Erinnerung, wie mich damals ein echter Profi an unseren Großrechner herangeführt hat, das waren 2 komplette Racks Compute-Nodes und ein Rack Storage-Only mit Infini-Band, letzterer mit ZFS und SAM/QFS, der letztlich ein Modell zu einem 2 PB Endprodukt durchgerechnet hat!
Was ich sagen würde, dass ich von Ihm damals mitgenommen habe: ZFS ist richtig konfiguriert kaum zu schlagen, hat aber genauso seine Tücken, die man eben wissen sollte, weil es ansonsten genauso zum Datenverlust kommen kann ... egal wie gut und ausgereift ZFS auch ist ;)

[Badesalz]

@Holt (Gott steh uns bei...)
Ich sehe in deinem Szenario NICHTS was verhindert, daß ein Bitflip mal im Backup landet. Wie auch immer du "pauschal" definierst und was auch immer rsync damit zu tun haben soll.
Wichtig ist natürlich, wie immer, den ersten Satz damit anzufangen, daß es so nicht richtig sein kann :uup:

Ehrlich gesagt nein.Dann andersrum. Eine ungefähre Idee, warum ich dich unbedingt von irgendetwas überzeugen muss, was alle anderen eben aus diesen und nicht anderen Gründen nutzen? Verstehe ich nicht.
Ohne ECC-Speicher ist alles eine Lotterie und verlassen kann man sich eh auf nichts.Falls dir das alles zu schnell ging: Es ging (mir) darum, daß irgendeine Kasperbude Btrfs auf Plasteboxen ausrollt, die sie mit non-ECC Speicher verkaufen. Und das dann noch extrem anfällig ist, wenn es nicht an einer USV hängt.

@Acid-Beatz
Du hast den Joke gefunden. Freut mich :smile: Und nein, nicht alles ist sofort eine Verkaufsveranstaltung.

[Gast]

@Holt (Gott steh uns bei...)
Ich sehe in deinem Szenario NICHTS was verhindert, daß ein Bitflip mal im Backup landet. Wie auch immer du "pauschal" definierst und was auch immer rsync damit zu tun haben soll.
Wichtig ist natürlich, wie immer, den ersten Satz damit anzufangen, daß es so nicht richtig sein kann :uup:

Ich denke es ging hier darum, wie das Backup gemacht wird und um den Zeitpunkt des Kopierens und von wo kopiert wurde. Du scheinst wiederholt den falschen User zu zitieren. Wer ist Holt? Hat der oder die hier gepostet? Das heißt, du liest die Postings der anderen nicht mal sinnerfassend. Wie jemand sein Posting beginnt ist ja wohl nebensächlich, und so nebenbei gesagt lesen sich deine Postings hier ziemlich arrogant. Ich denke du bist ein Troll.

[jellyfish]

Danke, so werde ich es auch machen. Ich werde eine WD Red mit SMR Technik kaufen als Backup-Platte und eine WD Red Plus mit CMR Technik als Arbeitsplatte, weil dort auch mit gearbeitet wird (Videoschnitt) und CMR soll schnellere Schreibvorgänge haben, während SMR schneller einlesen kann und mehr Cache hat.

Oder ist es nicht eher so, dass für Videoschnitt das Einlesen wichtiger ist, als das Schreiben? Geschrieben/Gerendert wird ja am Ende auf die Betriebsystem-SSD. Dann wäre die SMR-Platte evtl. doch besser?
[...]
Kennt sich jemand aus?
Es kommt auf den Workflow an, aber im Grunde ist das Lesen wichtiger als das Schreiben. Wenn in eine kodierte Datei gerendert wird, ist die Geschwindigkeit unwichtig, es bremst schließlich die CPU. Wenn unkomprimiert gespeichert wird, würde es sich vielleicht auswirken, aber insgesamt wird wohl trotzdem öfter gelesen als geschrieben (wegen der getätigten Arbeitsschritte). Das finale Rendern macht man meistens nur einmal. Daher würde ich es eher umgekehrt machen: Die Video-Datei auf die SSD kopieren, bearbeiten und zum Schluss auf eine HDD rendern. Da ist die Geschwindigkeit der HDD dann auch nebensächlich.

[jellyfish]

@Holt (Gott steh uns bei...)
Ich sehe in deinem Szenario NICHTS was verhindert, daß ein Bitflip mal im Backup landet. Wie auch immer du "pauschal" definierst und was auch immer rsync damit zu tun haben soll.
Wichtig ist natürlich, wie immer, den ersten Satz damit anzufangen, daß es so nicht richtig sein kann :uup:

Wer ist @Holt? Und wo soll Gott dir beistehen?
Du kannst nicht mal richtig zitieren.

Pauschal weil es auf den Zeitpunkt ankommt, wann das Bitflip passiert. Wenn die Daten auf meiner Arbeitsplatte liegen, gehe ich davon aus, dass damit alles in Ordnung ist und korrekt auf die Zielplatte übertragen werden. Wie schon mehrmals erwähnt, verfügen die heutigen Festplatten alle über ausreichend technologische Maßnahmen (unter anderem S.M.A.R.T.), um Bitflips zu erkennen und entweder zu melden oder auszugleichen und zu beheben (der Sektor wird bei Problemen neu geschrieben oder woanders hinverlegt oder sonst als fehlerhaft gemeldet => Lesefehler).

Mit rsync werden nur Dateien übertragen, die sich geändert haben. Wenn ich alle Dateien komplett nochmals übertrage, werden diese auch komplett neu geschrieben und Bitrot kann wohl kaum zuschlagen. Wie gesagt ist Bitrot aber bei heutigen Festplatten kein Thema. Entweder es passiert und du hast einen Lesefehler oder eine Warnung, oder alles ist gut.

[PatkIllA]

Dann andersrum. Eine ungefähre Idee, warum ich dich unbedingt von irgendetwas überzeugen muss, was alle anderen eben aus diesen und nicht anderen Gründen nutzen? Verstehe ich nicht. Dann sag doch einfach du hast auch keine Ahnung wie oft sowas auftritt.
Unbemerkte Bitflips auf der Platte sind praktisch ausgeschlossen. Da ist gleich der ganze Sektor fehlerhaft.
Ein Bitflip im Speicher ist nicht so unwahrscheinlich und wird ohne ECC nicht erkannt. Da ist das Dateisystem aber nur ein winziger Teil im ganzen Workflow. Warum dann so einen Wert auf ECC beim NAS legen? Der ist auf dem Arbeitsrechner mindestens genauso wichtig.

Falls dir das alles zu schnell ging: Es ging (mir) darum, daß irgendeine Kasperbude Btrfs auf Plasteboxen ausrollt, die sie mit non-ECC Speicher verkaufen. Und das dann noch extrem anfällig ist, wenn es nicht an einer USV hängt.Alles auch nicht schlechter als mit anderen Dateisystemen und ebenfalls ohne ECC.

Deine beleidigenden Unterton kannst du dir auch sparen.

[Badesalz]

Du kannst nicht mal richtig zitieren.Hast du ein Glaukom? Ich hab dich oben garnicht zitiert (wegen Mangel an Inhalten). Hauptsache du fängst erstmal direkt wieder mit einer rein negativen These an. Was bist du nur für ein begnadeter Redner... :uup:

Pauschal weil es auf den Zeitpunkt ankommt, wann das Bitflip passiert.Das hab ich PatkIllA schon erklärt, wann das passiert. War dir das zu genau?

Wie schon mehrmals erwähnt, verfügen die heutigen Festplatten […]Was genau verhindert, daß du beim Thema bleiben kannst? Smart hat mit Bitflips nichts zu tun (wie schön du das auch immer ausschreibst, diese Sheldonitis kenn ich wie gesagt ;)). Mal wieder kiloweise Text als Nebelwand. Versuchst du mich kaputtzuquatschen?

Mit rsync werden nur Dateien übertragen, die sich geändert haben. Wenn ich alle Dateien komplett nochmals übertrage, werden diese auch komplett neu geschrieben und Bitrot kann wohl kaum zuschlagen.Ok. Jetzt hast du mich. Was hat der erste Satz mit dem zweiten zu tun?
Und warum sollten Bitflips beim komplett Neuschreiben "kaum" zuschlagen? Ist das die These, daß Bitrots nur das Ziel betreffen?

Wie gesagt ist Bitrot aber bei heutigen Festplatten kein Thema. Entweder es passiert und du hast einen Lesefehler oder eine Warnung, oder alles ist gut.Was ist die primäre Quelle für deine Theorie? Das ist hoffentlich nicht nur zusammengereimt oder?

@PatkIllA
Dann sag doch einfach du hast auch keine Ahnung wie oft sowas auftritt.Ich kenn nur die Studie von Google. Weißt du wann mir sowas wichtig ist? Wenn ich Industrie mache und "critical business data" mache. Dann muss ich einen Aufwand treiben um das zu verhindern und das kostet mich. Dann schau ich mir auch die Schwerpunkte in der Methodik an, um u.a. die Kosten dafür auszubalancieren.
Daheim, ist mir das shiceegal. Daheim kenn ich nur Murphy und Zeitverschwendung, wenn eingetretenen Disaster gemanagt werden müssen. Ich schaue da nicht nach Wahrscheinlichkeiten, wenn die technisch bestmöglichen Lösung nicht mehr oder gar weniger kostet als ein simples PlasteNAS.

Unbemerkte Bitflips auf der Platte sind praktisch ausgeschlossen. Da ist gleich der ganze Sektor fehlerhaft.1: Du träumst. 2: Ah? Für dich wäre das wichtig, daß wenn die Daten nicht brauchbar sind, das nicht an einer heilen Datei mit veränderten Dateninhalt liegt, sondern wenn denn, dann an einer defekten Datei?
Mir ist das überhaupt nicht wichtig.

Alles auch nicht schlechter als mit anderen Dateisystemen und ebenfalls ohne ECC.GENAU. Darum ging es auch, zu verstehen, daß da nichts besseres bei ist (bei genau dieser Lösung).
Wobei, wenn du SoftRAID1 mit Btrfs auf Synology fährst, und die Mikrowelle am gleichen Stromkreis den FI raushaut, dann hast du zu 95% ein großes Problem, wenn das nicht an der USV hängt. Es ist also nicht "pauschal" ;) gleich ok, sondern das kann auch massiv schlechter sein.

[PatkIllA]

Ich kenn nur die Studie von Google. Weißt du wann mir sowas wichtig ist? Wenn ich Industrie mache und "critical business data" mache. Dann muss ich einen Aufwand treiben um das zu verhindern und das kostet mich. Dann schau ich mir auch die Schwerpunkte in der Methodik an, um u.a. die Kosten dafür auszubalancieren.Auch da ist das eine Balance. Es gibt auch extra gehärte Hardware wie sie z.B. bei Weltraumtechnik üblich ist. Das ist nochmal ein vielfaches teurer und langsamer dafür zuverlässiger als der beste Server den du kaufen kannst. Man verhindert auch nichts sondern reduziert Wahrscheinlichkeiten.
Daheim, ist mir das shiceegal. Daheim kenn ich nur Murphy und Zeitverschwendung, wenn eingetretenen Disaster gemanagt werden müssen. Ich schaue da nicht nach Wahrscheinlichkeiten, wenn die technisch bestmöglichen Lösung nicht mehr oder gar weniger kostet als ein simples PlasteNAS.Ich schaue da schon nach Wahrscheinleichkeiten, um Aufwand zu priorisieren. Was wägst du denn da ab? Ein PlattenNas auch mit ECC schützt dich nicht vor Bitfehlern auf dem Client ohne ECC.
1: Du träumst.Du hast keine Zahlen aber ich träume aha
2: Ah? Für dich wäre das wichtig, daß wenn die Daten nicht brauchbar sind, das nicht an einer heilen Datei mit veränderten Dateninhalt liegt, sondern wenn denn, dann an einer defekten Datei?
Mir ist das überhaupt nicht wichtig.Das ist mir verdammt wichtig. Die kaputte Datei wird wahrscheinlich irgendwann mal unbemerkt kopiert und das Backup überschrieben. Bei defekten Daten kann ich aufs Backup zurückgreifen. Das ist bei deinem critival Businessfall auch so. Immer noch besser einen Fehler als korrupte Daten.
GENAU. Darum ging es auch, zu verstehen, daß da nichts besseres bei ist (bei genau dieser Lösung).
Wobei, wenn du SoftRAID1 mit Btrfs auf Synology fährst, und die Mikrowelle am gleichen Stromkreis den FI raushaut, dann hast du zu 95% ein großes Problem, wenn das nicht an der USV hängt. Es ist also nicht "pauschal" ;) gleich ok, sondern das kann auch massiv schlechter sein.Da solltest du mal den Elektriker kommen lassen.
Selbst beim abrupten abbrechen ist in der Regel nur der gerade in bearbeitete Teil defekt. Stromausfall kommt zwar mal vor aber das ganze Dateisystem gehimmelt hat es bei mir noch nie. Du hast jetzt eine Zahl genannt und die ist absurd falsch.
Mit den im Dateisystem eingebauten Fehlerkorrekturen können mehr Fehler erkannt werden. Korrektur/Duplizieren ist mit den Dateisystemen auch flexibler als einfaches spiegeln mit RAID 1. Selbst wenn es gesichert ist habe ich da evtl noch Zeit gespart. Die einzeln umgekippten Bits auf der Platte würden auch erkannt/behoben falls die wirklich durch die Fehlererkennung der Platte kommen.
Für mich sind das Vorteile, dass es immer noch Fälle gibt bei denen das nicht hilft nehme ich in Kauf.

[myMind]

Wie schon mehrmals erwähnt, verfügen die heutigen Festplatten alle über ausreichend technologische Maßnahmen (unter anderem S.M.A.R.T.), um Bitflips zu erkennen und entweder zu melden oder auszugleichen und zu beheben (der Sektor wird bei Problemen neu geschrieben oder woanders hinverlegt oder sonst als fehlerhaft gemeldet => Lesefehler).
Das sind die Fehler um die es nicht geht. Das sind korrigierbare Fehler.

Bei Bitrot geht es um die nicht korrigierbaren Fehler (uncorrectable read error, URE). Also die Wahrscheinlichkeit eines Fehlerhaften Bits nachdem die Festplattenphysik, die Festplattenelektronik und die Festplattenfirmware alles erdenkliche getan haben, um die Daten korrekt zu erhalten.

Wie gesagt ist Bitrot aber bei heutigen Festplatten kein Thema. Entweder es passiert und du hast einen Lesefehler oder eine Warnung, oder alles ist gut.
Dann wäre die URE = 0, was sie nicht ist.

[jellyfish]

Das sind die Fehler um die es nicht geht. Das sind korrigierbare Fehler.

Bei Bitrot geht es um die nicht korrigierbaren Fehler (uncorrectable read error, URE). Also die Wahrscheinlichkeit eines Fehlerhaften Bits nachdem die Festplattenphysik, die Festplattenelektronik und die Festplattenfirmware alles erdenkliche getan haben, um die Daten korrekt zu erhalten.

Bitrot sind auch korrigierbare Fehler. Aber nicht genug für einen Lesefehler. Nur wenn zuviel Bitrot passiert dann hast du einen nicht korrigierbaren Lesefehler. Worauf ich hinweisen wollte ist dass es keinen unentdeckten Bitrot bei heutigen Festplatten gibt. Entweder ein Fehler ist korrigierbar und die Daten dann korrekt, oder eben nicht => Lesefehler. Wenn der Fehler korrigierbar ist, hast du eventuell total pending sectors > 0.

Dann wäre die URE = 0, was sie nicht ist.
Ist sie ja nicht. Siehe oben.

[jellyfish]

Falls unentdeckte Fehler doch auftreten, wurde ich jedenfalls noch nie Opfer davon. Ich vergleiche die Daten meiner Backup-Platten eigentlich regelmäßig (jährlich) miteinander. Es gab zwar schon mal Lesefehler bzw. Probleme beim Lesen, aber unentdeckte Fehler sind mir noch nie untergekommen. Vielleicht hatte ich aber auch nur Glück.

[Badesalz]

Ich schaue da schon nach Wahrscheinleichkeiten, um Aufwand zu priorisieren. Was wägst du denn da ab? Ein PlattenNas auch mit ECC schützt dich nicht vor Bitfehlern auf dem Client ohne ECC.Korrekt. Clients schieben hier aber entweder ihr Media hin und her oder nutzen den ECC NAS als Datensilo und Backupziel. Wovon ich wiederum BackupA mach, mit einem System mit ECC. Und wovon auch BackupB gemacht wird, mit einem PlasteNAS (Ext4, kein ECC) über rsync, auf Raid5.

Man muss irgendwann einsehen, daß dem Genüge getan wurde. Sonst fällt man in ein psychodelisches Paranoia.

Da solltest du mal den Elektriker kommen lassen.Natürlich. Der verdrahtet die Kreise um und dann haut deine Holde den zweiten FI mit dem Bügeleisen raus. Oder hast du für jeden Raum einen extra FI bei dir? Oder, überhaupt, haben alle mit einem NAS ein eigenes Haus? Das sit vielleicht auf Melmac so, aber auf der Erde gilt nur die harte Realität.

Du hast jetzt eine Zahl genannt und die ist absurd falsch.Alleine reddit spricht da eine andere Sprache. Warte mal... Du fährst nicht zufällig eine PlasteNAs von Syno mit Btrfs?? Weil das hörte ich diesmal klarer heraus. Mir fehlte bisher eine Idee für soviel Gegenwind deinerseits. So wäre aber einiges klarer...

Und nein. Leider ist das nicht so, daß beim Bitrot der Sektor von Dateisystem als Defekt erkannt wird. Wenn das so wäre, wäre das Thema nicht SO groß wie es ist.

[myMind]

Worauf ich hinweisen wollte ist dass es keinen unentdeckten Bitrot bei heutigen Festplatten gibt. Entweder ein Fehler ist korrigierbar und die Daten dann korrekt, oder eben nicht => Lesefehler. Wenn der Fehler korrigierbar ist, hast du eventuell total pending sectors > 0.
Beispiel: Nimm zwei Bit plus einem dritten Bit als Checksumme für die beiden anderen. Ich schreibe zwei Nullen. Das Datenwort ist mit Checksumme 000.
a) Gutfall: 000
b) Erkennbare aber nicht korrigierbarer Fehler: 100, 010, 001, 111
c) Nicht erkennbare Fehler: 011, 101, 110

b) Ein Bitkipper wird erkannt. c) Wenn zwei Bits kippen, kann ich den Fehler nicht mehr erkennen. Unwahrscheinlicher aber nicht unmöglich.

Ich wüsste jetzt auch nicht, wie man sich von diesem Problem vollständig befreien kann.

Falls unentdeckte Fehler doch auftreten, wurde ich jedenfalls noch nie Opfer davon. Ich vergleiche die Daten meiner Backup-Platten eigentlich regelmäßig (jährlich) miteinander. Es gab zwar schon mal Lesefehler bzw. Probleme beim Lesen, aber unentdeckte Fehler sind mir noch nie untergekommen. Vielleicht hatte ich aber auch nur Glück.
Das würde ich prinzipiell als korrektes Verfahren ansehen die URE zu messen. Also von außen vergleichen. Ich denke, dass die Festplattenhersteller das mit ihren Testautomaten auch so machen. Der Endanwender kann das so nicht machen. Er kann nur Werte für Fall b) sehen. Das ist für sowas wie S.M.A.R.T., also eine grundsätzliche Einschätzung der Qualität, auch genau genug.

[PatkIllA]

Alleine reddit spricht da eine andere Sprache. Mist. Wieder auf einen Troll reingefallen...
So wäre aber einiges klarer...Ne. Ich habe wohl anscheinend nur genug mathematischen und informatiostechnischen Background.
Ich habe nur zwei externe Platten im Wechsel. Bei nicht so wichtigen Daten synce ich das einfach per Robocopy. Gelegentlich wird mal die Checksumme verglichen. Bei den wichtigeren Sachen werden die alten Daten nicht überschrieben, sondern es gibt jedesmal einen neuen Ordner und die gleichgebliebenen werden per Hardlink genutzt. Alternativ habe ich Zeugs in git.
Und nein. Leider ist das nicht so, daß beim Bitrot der Sektor von Dateisystem als Defekt erkannt wird. Wenn das so wäre, wäre das Thema nicht SO groß wie es ist.Genau das ist bei btrfs und ZFS der Fall. Von den mathematischen Wahrscheinlichkeiten, dass nicht jeder Fehler erkannt werden kann mal abgesehen.
Beispiel: Nimm zwei Bit plus einem dritten Bit als Checksumme für die beiden anderen.Die Codes bei Festplatten sind etwas ausgeklügelter. Mit den großen Sektoren ist das sogar noch effizienter.

[myMind]

Die Codes bei Festplatten sind etwas ausgeklügelter. Mit den großen Sektoren ist das sogar noch effizienter.
Man kann da gar nicht soviel machen. Es gibt immer einen Tradeoff. Entweder Du reicherst die Daten mit Redundanz an, dann verschieben sich die Verhältnisse hin zu mehr Korrketurmöglichkeiten und besserer Erkennung. Der Preis dafür ist der Platz, den man für die redundanten Daten benötigt. Dünnst Du die Redundanzen aus, kannst Du mehr Nutzdaten speichern, aber die Fehlerkorrektur und Fehlererkennungsmöglichkeiten sinken. Ggf. hast Du auch größere Blöcke, so dass im Falle eines Falles mehr Daten defekt sind.

Was sich jedenfalls nicht ändert sind die Fehlerklassen sowie oben am einfachen Beispiel dargestellt. a) Gutfall, b) erkennbare Fehler und c) nicht erkennbare Fehler.
Mit genügend Redundanz können erkennbare Fehler auch korrigierbar sein.

[Badesalz]

Ich wüsste jetzt mal gerne warum meine Antwort auf #55 hier verschwunden ist.

[Acid-Beatz]

Ich wüsste jetzt mal gerne warum meine Antwort auf #55 hier verschwunden ist.

Bitrot ?

[Badesalz]

Wahrscheinlich :D Scheint wohl auch Gehirne zu betreffen...