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

[Sieghard Schicktanz]

Hallo Peter,

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

Kennt jemand einen z.B. USB-Stick, der mit interner Elektronik
kryptographische Prüfsummen des Inhalts bildet und diesen

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

Prüfsummenwert auf Knopfdruck abspeichert. Stimmt die Prüfsumme nicht
mehr, soll der Stick blinken und quitschen, um Aufmerksamkeit zu
erzeugen.

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?

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

Dazu müßte sowas reichen.

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

 

[Sieghard Schicktanz]

Hallo Michael,

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

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
....
Wieso sollta man die doppelte Datenmenge lesen und dann 50%
wegwerfen, wenn man auf Lesegeschwindigkeit optimieren will?

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.

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.

Von \"Lesetest\" war ja auch nicht die Rede.

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

 

[Hanno Foest]

On 05.11.22 20:49, Sieghard Schicktanz wrote:

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.

Das machen die aber intern, dazu muß man nicht selber Hand anlegen.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Michael Schwingen]

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

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

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?

Das macht die Platte selber. Wenn ich erst Block 0-99 anfordere und dann
200-299, seekt die halt passend - das ist jedenfalls nicht langsamer, als
die unbenutzten Blöcke 100-199 ebenfalls zu lesen, ins RAM zu transferieren
und dann wegzuwerfen, und die Daten liegen ohne umkopieren da, wo sie
gebraucht werden.

Der Datentransfer per SATA incl. Bufferhandling, Interrupts etc. ist nicht
gratis, also lohnt es, von jeder Platte nur die Daten zu lesen, die man
wirklich braucht.

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.

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.

Von \"Lesetest\" war ja auch nicht die Rede.

Doch, es wurde argumentiert, daß durch das doppelte Lesen sichergestellt
sei, daß die Daten lesbar & OK seien - das ist nicht der Fall, ein
Lesefehler auf einem der Blöcke wird mit 50% Wahrscheinlichkeit beim
einmaligen Lesen des RAID-Devices nicht bemerkt.

cu
Michael

 

[Helmut Schellong]

On 11/03/2022 18:04, Helmut Schellong wrote:

|On 03/17/2021 12:11, Helmut Schellong wrote:

On 03/17/2021 10:16, Hanno Foest wrote:
Am 17.03.21 um 00:52 schrieb Helmut Schellong:



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

Nun ist auch die zweite alte Festplatte defekt gegangen.
Mit etwa 13 Monaten zeitlichem Abstand.

Es ist folglich extrem unwahrscheinlich, daß zwei Festplatten gleichzeitig defekt gehen,
so daß sie ab sofort keinen Datenverkehr mehr erlauben.

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

Ich habe die neue Festplatte in Betrieb genommen.
Es sind nun zwei gleiche aktuelle mit 2TB in Verwendung.
Die Transfergeschwindigkeit stieg von 65 MB/s auf 160 MB/s.


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

 

[Alexander Schreiber]

Rolf Bombach <rolfnospambombach@invalid.invalid> wrote:

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.

Eh, Sorgen um den Ausfall einzelner Platten macht man sich nur
bei kleinen Installationen, wo alles in maximal ein/zwei Racks passt.

Bei grossen Installation ist alles so ausgelegt, dass man fest davon
ausgeht, dass:
- jede Einzelkomponente (Platte, Maschine, ...) wird irgendwann ausfallen
- es ist genug Redundanz vorhanden, das einfach abzufangen

Dabei reicht die Redundanz je nach System über die ganze Skala:
- Festplatte/SSD
- Maschine
- Rack
- Datacenter
- Datacenter Campus
- Stadtbereich
- Kontinentweites Rechennetz

Man liest sich,
Alex.
--
\"Opportunity is missed by most people because it is dressed in overalls and
looks like work.\" -- Thomas A. Edison

 

[Sieghard Schicktanz]

Hallo Hanno,

Du schriebst am Mon, 7 Nov 2022 22:02:14 +0100:

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.

Das machen die aber intern, dazu muß man nicht selber Hand anlegen.

Ja, das ist schon richtig. Aber damit sie das machen können, müssen sie
halt in Betrieb sein und nicht stromlos rumstehen oder (z.B. im Schrank)
-liegen

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

 

[Volker Bartheld]

On Sat, 5 Nov 2022 20:49:39 +0100, Sieghard Schicktanz wrote:

Du schriebst am Sat, 5 Nov 2022 07:48:11 +0100:
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.

Da soll sich bitte die Firmware der SSD selbst drum kümmern.

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

Genau. ;-)

Volker

 

[Volker Bartheld]

On Tue, 8 Nov 2022 21:49:45 +0100, Sieghard Schicktanz wrote:

Du schriebst am Mon, 7 Nov 2022 22:02:14 +0100:
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.
Das machen die aber intern, dazu muß man nicht selber Hand anlegen.
Ja, das ist schon richtig. Aber damit sie das machen können, müssen sie
halt in Betrieb sein und nicht stromlos rumstehen oder (z.B. im Schrank)
-liegen

Und HDDs als RAID-Verbund würden einen scrub machen, während sie
stromlos im NAS liegen? Datenfehler schleichen sich auch auf HDDs nicht
nur im laufenden Betrieb ein.

Vol\"Die Flüchtigkeit von Daten auf unbenutzten SSD wird deutlich
überbewertet, zumindest insofern man die Dinger nicht monate- und
jahrelang verstauben läßt.\"ker

 

[Volker Bartheld]

On Sat, 5 Nov 2022 21:19:52 -0000 (UTC), Peter Heirich wrote:

Volker Bartheld wrote:
[Virenscan auf externem Speicher] Welche Relevanz hätte die Existenz
von Virensignaturen z. B. auf einem NAS, das Dateien zwar schreibt
und liest, aber nie ausführt?
Es geht nicht darum, das NAS selbst zu schützen.

Auch mein PC muß nicht vor Virensignaturen geschützt werden, die sich
rein zufällig in einer Videodatei befinden.

Oder schmeißt Dein Newsreader im Ernst eine Warnung bei diesem QR-Code?

▄▄▄▄▄▄▄ ▄ ▄▄ ▄ ▄▄▄ ▄▄▄▄▄▄▄
█ ▄▄▄ █ ▄▀ ▄ ▀ █ ▀ ▀▀▀█▀▀ █ ▄▄▄ █
█ ███ █ █ ███▀ ██▄▄▀█▄▀ █ ███ █
█▄▄▄▄▄█ ▄ █▀█▀█▀█ █▀▄▀█▀█ █▄▄▄▄▄█
▄▄▄ ▄▄▄▄█ ▀▄▀ ██▀ ▀█▀▀ ▀▄▄ ▄
▀▀▀ ▄▀▄▀▄██▀ ▄▀▀▀█ ▄ ▄█▀▄▀▄▄▄
█ ▀▄▄█▄▀▀▀█▄▀██▀▀▀ ▀▀█▄ ▄██▀ ▄
▄ ▄▄▀█▄ █▀▀ ▀▄▀▀ ▄▀▀█▄ ▄█ ▄▄▀█
███▀ ▄ █▄█▀▄██ ▀▀▀▄▀▀ ▄▀▄██ ▄▄▀
▀ ▀▄▀█▄█▄ ███▀ ▀▀█▀▀█▀▄▀▀▀▀ ▄▀▄█▄
▀ ▀▄▄▄▀▄▄▄▄▀▀ ▀█▀ ▀█▀▀ ▄█▄█▄ ▄▄▄
▄ █▀█▀▄▄▄ ▀▀ ▄▀█ ▄▀███▀▀ ▄ ▄█▄ █
▄▀ ██▀▄▄ ▀▄█▄▀▀▀▀▄██▄ ██▄▄█▄▄▀
▄▄▄▄▄▄▄ ██ ██▄▄▀▀██▀▀ ▄█ ▄ █▀▄▄▄
█ ▄▄▄ █ █ ▀▄█▀▀██▀ ▀▄▀▀▀█▄▄▄█▄▄█▄
█ ███ █ ▄█ ▀▄ ▄ ▀▀▀███ ▄▄▄▄█▀█▄
█▄▄▄▄▄█ █▄ ▄▄█▄ ▀▀▀▀▀▀▀█ ▀█▄█ █▄

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.

Nicht erkannt von wem? Auf dem PC, der auf das NAS schreibt? Sollte der
nicht einen On-the-Fly-Virenscanner haben, der ihm verbietet,
virenhaltige Dateien überhaupt anzufassen?

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.

Totalschaden, weil irgendein Client diese Datei vom NAS liest und
unreflektiert ausführt? Je nun. Hört man in der Windowswelt öfter, daß
es eine schlechte Idee ist, einfach irgendwelche .exe zu starten.

Ja, zugegeben, es traten schon Fälle auf, wo eine \"Mediendatei\" (also
Dokumente bis hin zu simplen Bildern) so instrumentiert wurden, daß sie
einen Fehler im Dateibetrachter ausnutzten, um Schadcode auszuführen.

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.

Dazu ist kein Rootkit notwendig, außer Du verwendest eine sehr lockere
Definition. Administratorrechte (\"root\") benötigst Du zum Verschlüsseln
der Benutzerdateien nicht. Es reicht, die entsprechende Software im
Userkontext auszuführen.

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

Dem Stichwort \"Linux\" entnehme ich, daß Du ohnehin schon die
wesentlichen Vorkehrungsmaßnahmen zu Virenabwehr getroffen hast.

Volker

 

[Volker Bartheld]

On Sat, 5 Nov 2022 22:44:55 +0100, Gerrit Heitsch wrote:

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.
BTW: Folgendes würde mich von BORG Abstand halten lassen:
A chunk is considered duplicate if its id_hash value is identical.
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/

Ups.

> Ich bleibe für meine Backups lieber bei rsync

Halte ich genauso. Ein mächtiger Befehl, der bislang alles leisten
konnte, was ich in puncto Backup verlangte. Der Sinn am Backup ist ja
auch, daß es leicht und sicher von der Hand geht, ohne potentielle
Fallstricke, nervtötdende Softwareinstalliererei und sonstiges Gehampel.

Volker

 

[Gerrit Heitsch]

On 11/9/22 16:55, Volker Bartheld wrote:

On Sat, 5 Nov 2022 22:44:55 +0100, Gerrit Heitsch wrote:
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.
BTW: Folgendes würde mich von BORG Abstand halten lassen:
A chunk is considered duplicate if its id_hash value is identical.
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/

Ups.

Ich bleibe für meine Backups lieber bei rsync

Halte ich genauso. Ein mächtiger Befehl, der bislang alles leisten
konnte, was ich in puncto Backup verlangte. Der Sinn am Backup ist ja
auch, daß es leicht und sicher von der Hand geht, ohne potentielle
Fallstricke, nervtötdende Softwareinstalliererei und sonstiges Gehampel.

Ja, einmal hingesetzt und ein brauchbares Script geschrieben und schon
ist das Backup schmerzfrei. Da Backup ein Abbild des Filesystems ist ist
der Restore einfach, den mache ich im Falle eines Falles mit passenden
\'cp -a\' Kommandos.

Gerrit

 

[Gregor Szaktilla]

Am 09.11.22 um 16:55 schrieb Volker Bartheld:

[...] Der Sinn am Backup ist ja
auch, daß es leicht und sicher von der Hand geht, ohne potentielle
Fallstricke, nervtötdende Softwareinstalliererei und sonstiges Gehampel.

Deshalb fahre ich mittlerweile mein „brutalstmögliches Deppen-Backup“:
Da Plattenplatz mittlerweile kein Problem mehr darstellt, kopiere ich
meine wichtigsten Daten (das komplette home-Verzeichnis) unkomprimiert
per \'cp -ar /home /media/backup\'.

Gruß

Gregor



--
Sehrsehr! Vielviel!

Jaja.

 

[Gerrit Heitsch]

On 11/9/22 17:34, Gregor Szaktilla wrote:

Am 09.11.22 um 16:55 schrieb Volker Bartheld:
[...] Der Sinn am Backup ist ja
auch, daß es leicht und sicher von der Hand geht, ohne potentielle
Fallstricke, nervtötdende Softwareinstalliererei und sonstiges Gehampel.

Deshalb fahre ich mittlerweile mein „brutalstmögliches Deppen-Backup“:
Da Plattenplatz mittlerweile kein Problem mehr darstellt, kopiere ich
meine wichtigsten Daten (das komplette home-Verzeichnis) unkomprimiert
per \'cp -ar /home /media/backup\'.

Kann man tun. Es ist aber eine gute Idee sich in rsync kurz mal
einzuarbeiten. Dann geht das Backup schneller.

BTW: Das \'r\' kannst du weglassen, \'cp -a\' reicht.

Gerrit

 

[Sieghard Schicktanz]

Hallo Volker,

Du schriebst am Wed, 9 Nov 2022 16:39:49 +0100:

Und HDDs als RAID-Verbund würden einen scrub machen, während sie
stromlos im NAS liegen? Datenfehler schleichen sich auch auf HDDs
nicht nur im laufenden Betrieb ein.

Vergleich mal ein paar Zeitkonstanten für die Zerfallsraten.

Vol\"Die Flüchtigkeit von Daten auf unbenutzten SSD wird deutlich
überbewertet, zumindest insofern man die Dinger nicht monate- und
jahrelang verstauben läßt.\"ker

Eben, \"monate- und jahrelang\", nicht jahrzehntelang. \"Durchkopieren\"
wie bei Bändern gibt\'s bei Magnetplatten schließlich nicht,

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

 

[Sieghard Schicktanz]

Hallo Volker,

Du schriebst am Wed, 9 Nov 2022 16:35:10 +0100:

\"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.

Da soll sich bitte die Firmware der SSD selbst drum kümmern.

Tut sie ja auch - wenn Du sie läßt und genug Reserve da ist und Du
immer schön brav Dein \"Trim\" gemacht hast. (Sonst behält sie auch
den ältesten Müll und kann irgendwann garnichts mehr schreiben.)

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

 

[Peter Heirich]

Am Wed, 9 Nov 2022 16:52:22 +0100 schrieb Volker Bartheld:

Nicht erkannt von wem? Auf dem PC, der auf das NAS schreibt? Sollte der
nicht einen On-the-Fly-Virenscanner haben, der ihm verbietet,
virenhaltige Dateien überhaupt anzufassen?

Diese \"On-the-Fly\" sind auch vorhanden. Sophos für Windows und Clamav +
Dr.Web für Linuxsysteme. Wobei Clamav nicht über Files fliegt, sondern
email checkt und terminliche Scans macht. Für Android auch Dr.Web.

Es ist leider zu erwarten, dass Ransom-ware über Wochen unerkannt wirkt
und bereits verschlüsselte Daten in entschlüsselter Form anbietet.

Hätte man einen Detektor, der das merkt, könnte man vermutlich noch
rechtzeitig ein Backup fertigen, welches \"entseucht\" werden kann.

Peter

 

[Gerrit Heitsch]

On 11/9/22 22:00, Sieghard Schicktanz wrote:

Hallo Volker,

Du schriebst am Wed, 9 Nov 2022 16:35:10 +0100:

\"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.

Da soll sich bitte die Firmware der SSD selbst drum kümmern.

Tut sie ja auch - wenn Du sie läßt und genug Reserve da ist und Du
immer schön brav Dein \"Trim\" gemacht hast. (Sonst behält sie auch
den ältesten Müll und kann irgendwann garnichts mehr schreiben.)

TRIM braucht man nicht, underprovisioning tut es auch, also einen
Bereich der SSD bei der Partitionierung ausnehmen und nie direkt benutzen.

Gerrit

 

[Volker Bartheld]

On Wed, 9 Nov 2022 21:58:17 +0100, Sieghard Schicktanz wrote:

Du schriebst am Wed, 9 Nov 2022 16:39:49 +0100:
Und HDDs als RAID-Verbund würden einen scrub machen, während sie
stromlos im NAS liegen? Datenfehler schleichen sich auch auf HDDs
nicht nur im laufenden Betrieb ein.
Vergleich mal ein paar Zeitkonstanten für die Zerfallsraten.

Die Zeitkonstante für \"Runterfallen\" liegt bei HDDs im Bereich weniger
Millisekunden. Wie ich hörte, vertragen magnetische Datenträger auch
einen Wohnungsbrand nicht so gut. Klar, das ist ein Mißbrauchsszenario
und auch durch regelmäßigen scrub nicht zu antizipieren. Ich hatte aber
durchaus schon Platten, bei denen nach ein paar Jahren des Müßiggangs
der Spindelmotor nicht mehr anlaufen wollte. Und was moderne
heliumgefüllte Exemplare machen, wenn sich das Helium mal verpißt hat,
weiß man auch nicht so genau.

https://www.nidec.com/en/technology/casestudy/helium_hdd/

Backblaze scheint bislang keine Auffälligkeiten entdeckt zu haben:

https://www.backblaze.com/blog/helium-filled-hard-drive-failure-rates/

Nur darauf verlassen, daß die vernachlässigbare Verbreiterung der
magnetischen Domänen deutlich unterhalb der Curie-Temperatur der
einzige Effekt ist, der zum Datenverlust führt, würde ich mich
jedenfalls nicht.

Auch ein nettes Video: https://www.youtube.com/watch?v=AaZ_RSt0KP8

Vol\"Die Flüchtigkeit von Daten auf unbenutzten SSD wird deutlich
überbewertet, zumindest insofern man die Dinger nicht monate- und
jahrelang verstauben läßt.\"ker

Eben, \"monate- und jahrelang\", nicht jahrzehntelang. \"Durchkopieren\"
wie bei Bändern gibt\'s bei Magnetplatten schließlich nicht,

Wer magnetische Speicher nicht regelmäßig umkopiert (mit \"regelmäßig\"
wie in \"spätestens alle paar Jahre\"), sollte seine Hand für die Daten
jedenfalls nicht ins Feuer legen. YMMV.

Volker

 

[Sieghard Schicktanz]

Hallo Volker,

Du schriebst am Thu, 10 Nov 2022 11:18:52 +0100:

[elektronische vs. magnetische Speicherung]

Vergleich mal ein paar Zeitkonstanten für die Zerfallsraten.

Die Zeitkonstante für \"Runterfallen\" liegt bei HDDs im Bereich weniger
Millisekunden. Wie ich hörte, vertragen magnetische Datenträger auch
einen Wohnungsbrand nicht so gut. Klar, das ist ein Mißbrauchsszenario
und auch durch regelmäßigen scrub nicht zu antizipieren. Ich hatte
aber durchaus schon Platten, bei denen nach ein paar Jahren des
Müßiggangs der Spindelmotor nicht mehr anlaufen wollte. Und was
moderne heliumgefüllte Exemplare machen, wenn sich das Helium mal
verpißt hat, weiß man auch nicht so genau.

Jasicher. Auch einen (N)EMP werden Magnetplatten nicht ganz schadlos
überstehen, und nach einem Vulkanausbruch mit drüberfließender Lava
dürften sie auch nicht mehr gut funktionieren.
Katastrophenszenarien sind als Vergleichsgrundlage für die Haltbarkeit
vieler Dinge meist schlecht brauchbar, wenn es sich um die Angaben bei
ordentlicher Handhabung dreht. Aber wenn immer gleich wer durchdreht,
sind halt solche Abschätzungen meist \"für\'d Katz\'\".

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