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

[Peter Heirich]

Gerrit Heitsch wrote:

Noch schöner ist, daß die zweite HD schon defekt sein kann, es aber
bisher noch
nicht aufgefallen ist weil der defekte Bereich schon länger nicht mehr
gelesen
wurde. Beim Resync wird aber alles gelesen und dann fällt es auf.

M.E. eher unwahrscheinlich. In einem ordentlich designten Sytem sollte
minimal 1x die Woche der Virenscanner alles mal prüfen.

Peter

 

[Volker Bartheld]

Gerrit Heitsch wrote:
Noch schöner ist, daß die zweite HD schon defekt sein kann, es aber
bisher noch nicht aufgefallen ist weil der defekte Bereich schon
länger nicht mehr gelesen wurde. Beim Resync wird aber alles gelesen
und dann fällt es auf.

On Sat, 5 Nov 2022 00:01:47 -0000 (UTC), Peter Heirich wrote:

M.E. eher unwahrscheinlich. In einem ordentlich designten Sytem sollte
minimal 1x die Woche der Virenscanner alles mal prüfen.

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] https://de.wikipedia.org/wiki/RAID#RAID_1:_Mirroring_%E2%80%93_Spiegelung

 

[Rolf Bombach]

Helmut Schellong schrieb:

Man stelle sich vor, 10 Millionen Festplatten werden mit sehr hoher Wahrscheinlichkeit
innerhalb des kommenden halben Jahres defekt gehen.
Ein halbes Jahr hat etwa 15 Millionen Sekunden.
Es kann gut sein, daß dabei gar keine >1 Festplatten in derselben Sekunde defekt gehen.

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.

> Wie verhält sich das, wenn nur 2 statt 10000000 Festplatten betrachtet werden?

Dann passiert das seltener.

Es gibt hier eine Ähnlichkeit zu dem Spiel, wo Kugeln vertikal durch ein Feld aus Nägeln
und abschließend in Aufbewahrungs-Röhren fallen.

Damit hat das exakt gar nichts zu tun.

--
mfg Rolf Bombach

 

[Helmut Schellong]

On 11/04/2022 22:16, Sieghard Schicktanz wrote:

Hallo Helmut,

Du schriebst am Fri, 4 Nov 2022 15:32:18 +0100:

Man stelle sich vor, 10 Millionen Festplatten werden mit sehr hoher
Wahrscheinlichkeit innerhalb des kommenden halben Jahres defekt gehen.
Ein halbes Jahr hat etwa 15 Millionen Sekunden.
Es kann gut sein, daß dabei gar keine >1 Festplatten in derselben
Sekunde defekt gehen.

Wie verhält sich das, wenn nur 2 statt 10000000 Festplatten
betrachtet werden?

Das verhält sich halt so, daß Statistik recht zufällig individuelle
Ergebnisse liefert.

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.)


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html

 

[Rolf Bombach]

Helmut Schellong schrieb:

Ich beachte _nur_ eigene konkrete Erfahrungen und _solche_ aus meinem Umfeld.
Betreffend Festplatten und PC-Netzteile.

Diese sagen mir ganz klar, daß es extrem unwahrscheinlich ist, daß zwei Festplatten
zum gleichen Zeitpunkt defekt gehen und sofort keinen Datenverkehr mehr zulassen.

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).

Ich verwende seit Jahrzehnten ausnahmslos Festplatten WD Gold Enterprise 24/7.
IBM produziert seit Jahrzehnten keine mehr - und ist damit irrelevant.

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.

--
mfg Rolf Bombach

 

[Michael Schwingen]

On 2022-11-05, Rolf Bombach <rolfnospambombach@invalid.invalid> wrote:

Diese sagen mir ganz klar, daß es extrem unwahrscheinlich ist, daß zwei Festplatten
zum gleichen Zeitpunkt defekt gehen und sofort keinen Datenverkehr mehr zulassen.

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).

+ 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

 

[Helmut Schellong]

On 11/05/2022 11:43, Rolf Bombach wrote:

Helmut Schellong schrieb:

Man stelle sich vor, 10 Millionen Festplatten werden mit sehr hoher Wahrscheinlichkeit
innerhalb des kommenden halben Jahres defekt gehen.
Ein halbes Jahr hat etwa 15 Millionen Sekunden.
Es kann gut sein, daß dabei gar keine >1 Festplatten in derselben Sekunde defekt gehen.

Die Platten gehen aber unabhängig voneinander spontan kaputt.

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

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.

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

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.

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.

Wie verhält sich das, wenn nur 2 statt 10000000 Festplatten betrachtet werden?

Dann passiert das seltener.

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 gibt hier eine Ähnlichkeit zu dem Spiel, wo Kugeln vertikal durch ein Feld aus Nägeln
und abschließend in Aufbewahrungs-Röhren fallen.

Damit hat das exakt gar nichts zu tun.

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.

http://www.schellong.de/htm/defekt.htm#zweite


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html

 

[Helmut Schellong]

On 11/05/2022 12:53, Rolf Bombach wrote:

Helmut Schellong schrieb:

Ich beachte _nur_ eigene konkrete Erfahrungen und _solche_ aus meinem Umfeld.
Betreffend Festplatten und PC-Netzteile.

Diese sagen mir ganz klar, daß es extrem unwahrscheinlich ist, daß zwei Festplatten
zum gleichen Zeitpunkt defekt gehen und sofort keinen Datenverkehr mehr zulassen.

Kommt doch auf den Ausfallmechanismus an. Jede Platte für sich, ja.

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

> Allerdings gibt es auch gemeinsame Ursachen: Netzteil explodiert (BDTD),

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.

Decke stürzt auf PC, Blitzschlag, Brand, Hochwasser (etwa 4 PCs hab
ich bei Feuerwehreinsätzen aus dem Wasser gezogen).

Ich kopiere auch in meine Cloud.

Ich verwende seit Jahrzehnten ausnahmslos Festplatten WD Gold Enterprise 24/7.
IBM produziert seit Jahrzehnten keine mehr - und ist damit irrelevant.

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.

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.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html

 

[Rolf Bombach]

Michael Schwingen schrieb:

+ 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.

Materialbeschaffer/Bewirtschafter einer Serverfarm dürfte
ein Albtraumberuf sein. Aber sicher interessant.

--
mfg Rolf Bombach

 

[Gerrit Heitsch]

On 11/4/22 17:04, Guido Grohmann wrote:

Gerrit Heitsch schrieb:
On 11/4/22 07:33, Guido Grohmann wrote:

Es ist tatsächich nie der Fall eingetreten, daß 2 HDDs eines RAID1
gleichzeitig kaputtgegangen sind.

Dann hast du Glück gehabt. Ich hatte das und es waren nicht einmal die
erwähnten IBM. Da es das Boot-RAID1 war, war danach der komplette
Server offline und man musste erst einmal ein Minimal-OS installieren
bevor man das Backup zurückspielen konnte. War kein schöner Tag.

Wenn mir das passiert wäre, hätte ich zwei neue HDDs reingesteckt, die
Kiste von CD gebootet (Linux) und das Windows von einem Imageserver
wieder eingespielt.

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

 

[Gerrit Heitsch]

On 11/5/22 01:01, Peter Heirich wrote:

Gerrit Heitsch wrote:

Noch schöner ist, daß die zweite HD schon defekt sein kann, es aber
bisher noch
nicht aufgefallen ist weil der defekte Bereich schon länger nicht mehr
gelesen
wurde. Beim Resync wird aber alles gelesen und dann fällt es auf.

M.E. eher unwahrscheinlich. In einem ordentlich designten Sytem sollte
minimal 1x die Woche der Virenscanner alles mal prüfen.

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

Gerrit

 

[Michael Schwingen]

On 2022-11-05, Peter Heirich <talk.usenet@info21.heirich.name> wrote:

M.E. eher unwahrscheinlich. In einem ordentlich designten Sytem sollte
minimal 1x die Woche der Virenscanner alles mal prüfen.

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

cu
Michael

 

[Sieghard Schicktanz]

Hallo Volker,

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

ausführt? Ich würde mich außerdem schönstens bedanken, wenn irgendein
\"ordentlich designtes System\" 1x/Woche meine 4TB an Mediendaten
durchschrabbelt.

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.

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?

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.)

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Peter Heirich]

Volker Bartheld wrote:

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.

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

 

[Gerrit Heitsch]

On 11/5/22 22:19, Peter Heirich wrote:

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

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: https://borgbackup.readthedocs.io/en/stable/

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

 

[Peter Heirich]

Gerrit Heitsch wrote:

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

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

 

[Gerrit Heitsch]

On 11/6/22 01:00, Peter Heirich wrote:

Gerrit Heitsch wrote:

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

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.

Der Teufel ist ein Eichhörnchen...

Gerrit

 

[Gerrit Heitsch]

On 11/6/22 01:00, Peter Heirich wrote:

Gerrit Heitsch wrote:

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

Gutes Argument, möglicherweise ist das sogar so.

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

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

 

[Michael Schwingen]

On 2022-11-05, Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote:

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.)

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

 

[Laurenz Trossel]

On 2022-11-05, Rolf Bombach <rolfnospambombach@invalid.invalid> wrote:

Materialbeschaffer/Bewirtschafter einer Serverfarm dürfte
ein Albtraumberuf sein. Aber sicher interessant.

https://www.backblaze.com/blog/backblaze-drive-stats-for-q3-2022/