Re: [OT-Frage] Sicherer Speicher für wichtige Daten

Warum? Welche Relevanz hätte die Existenz von Virensignaturen z. B. auf einem NAS, das Dateien zwar schreibt und liest, aber nie ausführt? Ich würde mich außerdem schönstens bedanken, wenn irgendein "ordentlich designtes System" 1x/Woche meine 4TB an Mediendaten durchschrabbelt.

Und selbst wenn das passierte: Bist Du sicher, daß z. B. in einer RAID-1-Architektur tatsächlich beide Kopien gelesen werden und nicht etwa nur die, die grad am opportunsten ist?

"Zur Erhöhung der Sicherheit kann ein RAID-1-System beim Lesen stets auf mehr als eine Festplatte zugreifen. Dabei werden die Antwortdatenströme der Festplatten verglichen. Bei Unstimmigkeiten wird eine Fehlermeldung ausgegeben, da die Spiegelung nicht länger besteht. Diese Funktion bieten nur wenige Controller an, auch reduziert sie die Geschwindigkeit des Systems geringfügig." [1]

liest sich nicht so, als sei das ein Feature, auf das man sich verlassen könnte.

Volker

[1]

Helmut Schellong schrieb:

Die Platten gehen aber unabhängig voneinander spontan kaputt.

Es gibt zwei Grenzfälle:

- Eine Uhr tickt ein mal pro Sekunde.

- Ein Geigerzähler tickt ein mal pro Sekunde.

Wir sind nahe an Grenzfall 2. Also Stochastik. Die sagt, dass die Wahrscheinlichkeit eines Plattenausfalls am grössten ist unmittelbar nach einem andern Plattenausfall. Danach nimmt sie exponentiell ab. Wahrscheinlich werden zumindest phasenweise¹ mehr Platten innerhalb einer Sekunde kaputt gehen als ausserhalb. Ja, psychologisch ist das schwer fassbar, aber leicht statistisch erfassbar.

¹Sobald sehr viele weg sind, werden natürlich immer weniger kaputt gehen.

Dann passiert das seltener.

Damit hat das exakt gar nichts zu tun.

Es geht um Wahrscheinlichkeiten und Wahrscheinlichkeitsrechnung.

Die Wahrscheinlichkeit sinkt (auf den ersten Blick) auf ein 5000000-stel der ersten Wahrscheinlichkeit: w2 = w1 / (10000000/2)

(Die mathematische Darstellung einer Wahrscheinlichkeit ist hier undefiniert.)

Helmut Schellong schrieb:

Kommt doch auf den Ausfallmechanismus an. Jede Platte für sich, ja. Allerdings gibt es auch gemeinsame Ursachen: Netzteil explodiert (BDTD), Decke stürzt auf PC, Blitzschlag, Brand, Hochwasser (etwa 4 PCs hab ich bei Feuerwehreinsätzen aus dem Wasser gezogen).

Die Kurven wurden hier gezeigt; fast alle Hersteller hatten ihre Höhen und Tiefen. So schlecht wie WDC im Sommer 18 war eigentlich kein anderer Hersteller. IBM ist jetzt wohl HGST, die haben eigentlich sehr tiefe Ausfallraten.

• Fertigungsfehler und Firmware-Bugs. Es gab da welche, die durchaus zum Ausfall von 2 Platten kurz nacheinander (oder nach der gleichen Anzahl von Einschaltvorgängen) führte, ich habe da mal bei einem RAID aus baugleichen Seagate-Platten Daten retten dürfen.

Seitdem versuche ich, unterschiedliche Platten einzusetzen.

cu Michael

Ja, bei dieser Betrachtung sind die Abhängigkeiten voneinander vernachlässigbar.

Ja, entsprechende Punktewolken enthalten fast immer stoßweise Häufungen.

Ich hatte mir 1978 einen TI59 mit mehreren Zusatzmodulen gekauft und mich sehr intensiv damit beschäftigt. Ich bin hinsichtlich der Themen Wahrscheinlichkeitsrechnung, Statistik, Verteilungen, Lineare Regression, Kombinatorik, etc., ein kleiner Experte. Psychologie spielt bei meinen solchen Betrachtungen nie eine Rolle.

Ja, sehr sehr sehr sehr sehr sehr viel seltener. Es geht auch hier um eine Wahrscheinlichkeit.

Gegenüberstellung:

Bei wievielen Testläufen von 1 Million kommt es statistisch vor, daß diese jew. beiden Festplatten innerhalb derselben Sekunde (von 15 Mio. Sek.) kaputt gehen? Höchstwahrscheinlich in gar keinem Testlauf dieser 1 Mio. Testläufe! Es ist auch unwahrscheinlich, daß die erste Festplatte in Sekunde x und die zweite Festplatte in Sekunde x+1 kaputt geht.

Jedoch bei 10 Mio. statt zwei Festplatten ist es wahrscheinlicher, daß es nicht wenige Sekunden gibt, während denen jeweils so 2..7 Festplatten kaputt gehen.

Es geht mir hier von Anfang an immer nur um einen jeweiligen Endzustand, nicht um einen inneren Verlauf. Und dabei gibt es zweifellos eine Ähnlichkeit, wie ich schrieb: Die Anzahl Kugeln entsprechen der Anzahl Festplatten. Die Anzahl Aufbewahrungs-Röhren entsprechen der Anzahl Sekunden.

Genau so meine ich das, und genau so schreibe ich das überall. Ich meine stets meinen Festplatten-Mirror in meinem PC.

Kenne ich; wurde vor Jahren schon hier besprochen. Meine eigene Erfahrung zeigte mir bisher _nur_ Spannungen, die fehlerhaft klein waren. Also z.B. 1,6V statt 12V, und vergleichbar. Auch 5Vstb war mal plötzlich bei 0,8V.

Ich kopiere auch in meine Cloud.

Es kommt auch darauf an, aus welcher HDD-Familie gekauft wird.

Ich kenne grob die Historie von WDC. Ganz früh, als Conner noch gängig war, war WDC gut. Dann hatte WDC eine lange kritische Phase. Danach, bis heute, habe ich keinen Grund zur Klage. Seagate und WDC sind seit Jahrzehnten führend. WDC hat Hitachi-HDD und Sandisk geschluckt.

Eine neue HD hatte ich... Eine zweite musste erst geliefert werden. Es war ein Solaris-Server. Backup war vorhanden, aber damit man das zurückspielen kann braucht man natürlich erst einmal ein Minimalsystem.

Die Daten selbst waren auf FCAL angebundenen LUNs.

Gerrit

Virenscanner? Wir reden hier von Servern, nicht von Desktopsystemen und Windows ist da schon gar nicht im Spiel.

Gerrit

Virenscanner lesen nicht die ganze Datei ein, sondern nur die Teile, die zur Untersuchung nötig sind.

cu Michael

Hallo Volker,

Du schriebst am Sat, 5 Nov 2022 07:48:11 +0100:

Wird Dir aber nicht erspart bleiben - wenn auch evtl. mit anderen Abständen - wenn das Zeugs auf SSDs liegt. Die brauchen "gelegentlich" mal eine Auffrischung, bevor die Fehlerkorrektur die Daten nicht mehr wiederherstellen kann.

Nee, da werden schon beide gelesen, wenn der Controller gut ist, und zwar so ineinander verschachtelt (aka "interleaved"), daß die Daten möglichst schneller komplett gelesen sind, als das eine einzelne Platte schaffen könnte. (Relativiert sich aber wohl derzeit wegen der SSDs.)

Ich war etwas verkürzt.

Es geht nicht darum, das NAS selbst zu schützen.

Deshalb läuft auf meiner QNAP der QNAP-übliche Malware-Remover, der eigentlich ein Clamav ist.

Sinn ist ein Zeitvorsprung in folgendem Szenario:

Eine nicht erkannte Ransom-ware wird u.a. auf dem NAS abgelegt. Da sie dort nicht ausgeführt wurde, installiert sie auch nicht ihre "Tarnkappe".

Das entspricht etwa der "Ausschaltung" von Rootkits durch Boot von einem frischen, geprüften Datenträger.

Wenn jetzt später diese Ransom-ware irgendwo auffällt und deshalb Eingang in die Virensignaturen erhält, besteht die Chance, eine Ransom-ware zu erkennen, bevor diese Totalschaden anrichtet.

Der Trick bei Ransom-ware ist ja, dass ein Rootkit installiert wird, über längere Zeit die Dateien verschlüsselt und transparent entschlüsselt werden. Ist das umfassend erledigt, wird der lokale Schlüssel weggeworfen und man kann, wenn überhaupt, die Backupkopie des Schlüssels "käuflich erwerben".

Aber: Ich hatte schon Sekunden nach dem Post die Erkenntnis, das notwendige Backup nicht erwähnt zu haben. RAID ersetzt kein Backup, denn sowohl Verschlüsselung durch Ransom-ware, als auch simples Löschen oder Üerschreiben durch Viren bis Bedienfehler, werden auf RAID-Systemen getreulich auf allen Platten ausgeführt.

Schon durch das Backup werden alle Dateien üblicherweise angefasst. Klar, es gibt incrementelle oder differenzielle Backups, da dehnt sich die Zeit der Erkennung bis zum Vollbackup.

Ich persönlich habe auf tägliches deduplizierendes Backup ( Borg ) für Linux umgestellt. Da werden alle Dateien täglich komplett gelesen.

Um aber wieder etwas On-Topic zu werden:

Kennt jemand einen z.B. USB-Stick, der mit interner Elektronik kryptographische Prüfsummen des Inhalts bildet und diesen Prüfsummenwert auf Knopfdruck abspeichert. Stimmt die Prüfsumme nicht mehr, soll der Stick blinken und quitschen, um Aufmerksamkeit zu erzeugen.

Sinn: Honey-pot für Ransom-ware.

Peter

Das möchte ich bezweifeln. Schon bei einstelligen TB würde es mehr als

24h dauern alle Daten zu lesen. Es gibt dazu auch einen Hinweis:

quick detection of unmodified files

deutet auf den üblichen Check von Filesize und Modification date hin. Dazu braucht man die Datei selbst nicht zu lesen.

BTW: Folgendes würde mich von BORG Abstand halten lassen:

A chunk is considered duplicate if its id_hash value is identical.

Wenn der Hash kürzer ist als der Chunk ist das zwangsläufig nicht 100% sicher.

Und:

EXPECT THAT WE WILL BREAK COMPATIBILITY REPEATEDLY WHEN MAJOR RELEASE NUMBER CHANGES (like when going from 0.x.y to 1.0.0 or from 1.x.y to 2.0.0).

Alles von:

Ich bleibe für meine Backups lieber bei rsync, Quelle und Ziel sind Filesysteme und wenn man will kann man damit versionierte Backups erstellen die an Timemaschine von MacOS erinnern. Wer wissen will wie lese nach wie man die Option '--link-dest=<dir>' benutzt.

Gerrit

Gutes Argument, möglicherweise ist das sogar so.

Demnächst mal im Quellcode lesen und prüfen ob man das umgehen kann.

Und klar, sind Hash-Kollisionen eine Gefahr.

Ich denke aber, die Gefahr, dass ich selbst getötet werde und kein Backup mehr brauche ist weit höher.

Peter

Der Teufel ist ein Eichhörnchen...

Gerrit

Bei 'rsync' kann man es mit der Option '-c'. Und ja, es macht einen gigantischen Unterschied in der für ein Backup benötigten Zeit. Es dauert dann immer gleich lang und zwar im Bereich wie das erste Vollbackup.

Gerrit

Wieso sollta man die doppelte Datenmenge lesen und dann 50% wegwerfen, wenn man auf Lesegeschwindigkeit optimieren will?

Will sagen: es wird 50% vom einen und die anderen 50% vom anderen Laufwerk gelesen (ja, interleaved). Das gibt doppeltes Tempo, aber keinen

100%-Lesetest.

Bei Linux-md-RAID gibt es eine check-Funktion, die periodisch ausgeführt das tut, was man wirklich braucht (man 4 md):

As storage devices can develop bad blocks at any time it is valuable to regularly read all blocks on all devices in an array so as to catch such bad blocks early. This process is called scrubbing.

md arrays can be scrubbed by writing either check or repair to the file md/sync_action in the sysfs directory for the device.

Requesting a scrub will cause md to read every block on every device in the array, and check that the data is consistent. For RAID1 and RAID10, this means checking that the copies are identical. For RAID4, RAID5, RAID6 this means checking that the parity block is (or blocks are) correct.

If a read error is detected during this process, the normal read-error handling causes correct data to be found from other devices and to be written back to the faulty device. In many case this will effectively fix the bad block.

Debian macht das per Default 1* im Monat.

Wie man das bei anderen Raid-Systemen macht, bleibt dem Leser als Rechercheaufgabe überlassen.

cu Michael

Hallo Michael,

Du schriebst am 6 Nov 2022 13:18:06 GMT:

Wie machst Du das dann, wenn Du nicht verhindern kannst, daß die Daten ständig unter dem Lesekopf durchrauschen und Du zudem sicherstellen mußt, daß auch die richtigen Daten jeweils den Weg zur Anwendung finden? Klar, wenn das letzte Byte von Platte X im Buffer gelandet ist, kann man Platte Y ignorieren. Weiterlaufen wird die trotzdem. Ja, wie ja geschrieben: das relativiert sich wohl aktuell mit der Verbreitung der SSDs, aber sogar die haben Geschwindigkeitsgrenzen.

Von "Lesetest" war ja auch nicht die Rede.

Hallo Peter,

Du schriebst am Sat, 5 Nov 2022 21:19:52 -0000 (UTC):

Soll das dateiweise sein oder nach sonst einer Aufteilung? Für dateiweise müßte der Stick selber sein Dateisystem kennen und bearbeiten können - sowas gibt es AFAIK nicht. (Allerdings habe ich schon einen Stick, nicht mal gehabt, der _nur_ mit FAT richtig funktioniert. Ext4 mochte er garnicht, da gab's Fehler, langsame Übertragung, sogar Hänger. Re(!)formatierung mit FAT machte das wieder "gut", damit läuft er bisher ohne Auffälligkeit. Sachen gibt's...)

Dafür brauchte er eine recht umfängliche Elektronik, wie ie in den üblichen Controllern sicher nicht vorhanden ist. Und die Signalisierung braucht noch weitere Elemente - sehr handlich wird das Ding wohl nicht. Aber ein kleines Platinchen (Raspberry Pico?) mit so 'nem Ding könnte einfach gehen und nicht allzu umfangreich ausfallen?

Dazu müßte sowas reichen.