SD-Karte nicht mehr beschreibbar

[Ralph A. Schmid, dk5ras]

Eric Bruecklmeier <usenet@nerdcraft.de> wrote:

Das ist nicht mein Punkt. Es geht mir um das Problembewußtsein - viele
Anwender sehen gar nicht, daß es da überhaupt ein Problem geben könnte.
Sie nehmen an, die Daten seien irgendwie magisch für die Ewigkeit auf
dem Kärtchen eingebrannt...

Klar, das ist definitiv ein Problem. Genauso aber wie mit allen
Datenträgern, Festplatten usw. usf. - ohne Datenpflege rottet das Zeug
irgendwann weg.


-ras

--
Ralph A. Schmid +49-171-3631223 +49-911-21650056
http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/ http://www.kabuliyan.de/

 

[Eric Bruecklmeier]

Am 30.01.2019 um 10:30 schrieb Ralph A. Schmid, dk5ras:

Eric Bruecklmeier <usenet@nerdcraft.de> wrote:

Das ist nicht mein Punkt. Es geht mir um das Problembewußtsein - viele
Anwender sehen gar nicht, daß es da überhaupt ein Problem geben könnte.
Sie nehmen an, die Daten seien irgendwie magisch fĂźr die Ewigkeit auf
dem Kärtchen eingebrannt...

Klar, das ist definitiv ein Problem. Genauso aber wie mit allen
Datenträgern, Festplatten usw. usf. - ohne Datenpflege rottet das Zeug
irgendwann weg.

Richtig und bei den modernen Flashzellen ist irgendwann ziemlich bald...


--
Werbung:
https://www.amazon.de/Bier-brauen-Grundlagen-Rohstoffe-Brauprozess/dp/3800109271

 

[Edzard Egberts]

Gerrit Heitsch wrote:

Aber ansonsten bevorzuge ich generell Festplatten dafĂźr. Die haben zwar
auch Flash fßr ihre Firmware, der ist aber längst nicht so hochoptimiert
wie der fĂźr den Datenbereich in SSDs. Mir ist bisher noch keine HD durch
Lagerung kaputtgegangem.

Da stieg die Kapazität auch immer so schnell, dass man die alten Sachen
in irgend eine Ecke der neuen HDD kopieren konnte. Ich habe drei
Generationen Festplatten im Schrank stehen, die alle zu klein geworden
sind. In den letzten Jahren habe ich mir fĂźr das Backup sowieso immer
ein Paar gleicher Festplatten gekauft, da sind die alten immer mit einem
Schlag ĂźberflĂźssig geworden.

 

[Hanno Foest]

On 30.01.19 09:06, Gerrit Heitsch wrote:

Mir ist bisher noch keine HD durch
Lagerung kaputtgegangem.

Mir schon...

Hanno

 

[Gerrit Heitsch]

On 1/30/19 1:15 PM, Volker Bartheld wrote:

On Wed, 30 Jan 2019 12:55:01 +0100, Gerrit Heitsch wrote:
das einzige was du [gegen schleichenden Ladungsverlust von SSD und
ähnlichen Speichermedien] tun kannst ist die Daten in einer
Endlosschleife zu lesen und immer die Schwellwerte zu checken. Sobald
die den spezifizierten Bereich verlassen wird der fragliche Block
umkopiert und gelĂśscht damit er wieder neu beschrieben werden kann.

"Du" als User kannst nur in regelmäßigen Intervallen ein Backup fahren und
vergleichen, daß Quelle und Ziel noch binäridentisch sind. Und Du kannst
darauf vertrauen, daß der Hersteller in Sachen Datenretention in Sachen
Fehlerkorrektur, Datenerhaltung, Wear-Leveling usw. seine Hausaufgaben
gemacht hat.

Ja, das muss man leider so sehen. FĂźr meine wichtigen Daten (also das,
was man wirklich nicht mehr bekommt wenn es weg ist) benutze ich
versionierte Backups mit 'rsync --link-dest='. Da habe ich eine bessere
Chance wenn ich den Bitrot etwas zu spät bemerke.

Die bei mir vergesslich gewordene SSD hat allerdings brav fehlerhafte
Daten geliefert.

Schrott gibts leider immer wieder zu kaufen.

Weiss man nur eben vorher nicht.

Wie wäre denn die Handlungsempfehlung eine Datei mit gleichem Datum
(Erstellung, Modifikation, usw.), Länge, ... aber unterschiedlichem Inhalt
entweder der Kategorie "User hat die Datei willentlich verändert" oder der
Kategorie "durch Alterung/Lagerung sind Bits gekippt und der Controller
der SSD hats nicht gemerkt" zu differenzieren?

Gleiches Modifikationsdatum aber unterschiedlicher Inhalt kann nicht der
User gewesen sein, denn dann wäre das Datum unterschiedlich.

Das Problem ist in diesem Falle automatisiert rauszufinden welche Datei
jetzt die korrekte ist und welche die kaputte. Üblicherweise wäre die
korrekte die auf dem Backup, wenn das nicht auch auf einer SSD liegt.

Gerrit

 

[Volker Bartheld]

[sup: Copy&Paste-Prob]

On Wed, 30 Jan 2019 12:55:01 +0100, Gerrit Heitsch wrote:

das einzige was du [gegen schleichenden Ladungsverlust von SSD und
ähnlichen Speichermedien] tun kannst ist die Daten in einer
Endlosschleife zu lesen und immer die Schwellwerte zu checken. Sobald
die den spezifizierten Bereich verlassen wird der fragliche Block
umkopiert und gelöscht damit er wieder neu beschrieben werden kann.

"Du" als User kannst nur in regelmäßigen Intervallen ein Backup fahren und
vergleichen, daß Quelle und Ziel noch binäridentisch sind. Und Du kannst
darauf vertrauen, daß der Hersteller in Sachen Fehlerkorrektur,
Datenerhaltung, Wear-Leveling, usw. seine Hausaufgaben gemacht hat.

"Du" als Hersteller hast genügend Möglichkeiten, im laufenden Betrieb
Problemzellen zu refreshen oder umzukopieren und ggfs. entsprechende
Fehlermeldungen zu generieren.

Informativ in diesem Zusammenhang sind
https://www.heise.de/newsticker/meldung/SSD-Lagerung-und-Temperaturen-2639898.html
http://www.jedec.org/sites/default/files/Alvin_Cox%20%5BCompatibility%20Mode%5D_0.pdf
https://www.heise.de/newsticker/meldung/SSDs-in-der-Praxis-nicht-zuverlaessiger-als-Festplatten-2560979.html

Bleibt das Fazit, das SSDs (und ähnliche Technologien) keine Archivmedien
sind, allein schon deswegen nicht, weil sie stromlose Lagerung deutlich
schlechter vertragen.

Die bei mir vergesslich gewordene SSD hat allerdings brav fehlerhafte
Daten geliefert.

Schrott gibts leider immer wieder zu kaufen.

Sah man sehr gut bei Bildern. Ein Filesystem mit Checksummen wäre da gut
gewesen.

Mein NAS hat Btrfs. Wenn allerdings die lokale SSD beim Backup fehlerhafte
Daten ausliefert und man das nicht vorher prüft, nutzt das herzlich wenig.

Wie wäre denn die Handlungsempfehlung eine Datei mit gleichem Datum
(Erstellung, Modifikation, usw.), Länge, ... aber unterschiedlichem Inhalt
entweder der Kategorie "User hat die Datei willentlich verändert" oder der
Kategorie "durch Alterung/Lagerung sind Bits gekippt und der Controller
der SSD hats nicht gemerkt" zu differenzieren?

Automatismen versagen da m. M. n. komplett.

Volker

 

[Volker Bartheld]

On Wed, 30 Jan 2019 13:15:12 +0100, Gerrit Heitsch wrote:

ein Hinweis darauf, daß eine SSD neue Fehlermodi bringt wie wir sie von
HDs nicht kennen.

Definitiv. Wie wir schon diskutiert hatten, grenzt es an ein Wunder oder
ist mir zumindest ein Rätsel, wie man bei üblicher Hardware für den
Heimgebrauch etlich TB an Daten fehlerfrei von A nach B kopieren kann.

Ging schon vor etlichen Jahren mit einem AMD-Athlon-Motherboard los, wo der
eingebaute Festplattencontroller bei großen, zusammenhängenden
Datenübertragungen Mist gebaut hatte. Irgendwie fühlte sich damals niemand
für irgendwas zuständig. Die Seagate "Deathstar" waren hinlänglich bekannt,
von einem guten dutzend Exemplaren im Einsatz hate keine länger als 3 Jahre
gehalten. Auch der Ersatz nicht. Über DVD-Rs und untrschiedliche Dyes sowie
DVD-RAMs usw. hatten wir ja auch schon diskutiert.

Heutige Infrastruktur ist so heterogen und volatil, daß man sich vom
Begriff "Ewig" in Sachen Archivfestigkeit komplett verabschieden darf.

Volker

 

[Volker Bartheld]

On Wed, 30 Jan 2019 12:55:01 +0100, Gerrit Heitsch wrote:

das einzige was du [gegen schleichenden Ladungsverlust von SSD und
ähnlichen Speichermedien] tun kannst ist die Daten in einer
Endlosschleife zu lesen und immer die Schwellwerte zu checken. Sobald
die den spezifizierten Bereich verlassen wird der fragliche Block
umkopiert und gelöscht damit er wieder neu beschrieben werden kann.

"Du" als User kannst nur in regelmäßigen Intervallen ein Backup fahren und
vergleichen, daß Quelle und Ziel noch binäridentisch sind. Und Du kannst
darauf vertrauen, daß der Hersteller in Sachen Datenretention in Sachen
Fehlerkorrektur, Datenerhaltung, Wear-Leveling usw. seine Hausaufgaben
gemacht hat.

"Du" als Hersteller hast genügend Möglichkeiten, im laufenden Betrieb
Problemzellen zu refreshen oder umzukopieren und ggfs. entsprechende
Fehlermeldungen zu generieren.

Informativ in diesem Zusammenhang sind
https://www.heise.de/newsticker/meldung/SSD-Lagerung-und-Temperaturen-2639898.html
http://www.jedec.org/sites/default/files/Alvin_Cox%20%5BCompatibility%20Mode%5D_0.pdf
https://www.heise.de/newsticker/meldung/SSDs-in-der-Praxis-nicht-zuverlaessiger-als-Festplatten-2560979.html

Bleibt das Fazit, das SSDs (und ähnliche Technologien) keine Archivmedien
sind, allein schon deswegen nicht, weil sie stromlose Lagerung deutlich
schlechter vertragen.

Die bei mir vergesslich gewordene SSD hat allerdings brav fehlerhafte
Daten geliefert.

Schrott gibts leider immer wieder zu kaufen.

Sah man sehr gut bei Bildern. Ein Filesystem mit Checksummen wäre da gut
gewesen.

Mein NAS hat Btrfs. Wenn allerdings die lokale SSD beim Backup fehlerhafte
Daten ausliefert und man das nicht vorher prüft, nutzt das herzlich wenig.

Wie wäre denn die Handlungsempfehlung eine Datei mit gleichem Datum
(Erstellung, Modifikation, usw.), Länge, ... aber unterschiedlichem Inhalt
entweder der Kategorie "User hat die Datei willentlich verändert" oder der
Kategorie "durch Alterung/Lagerung sind Bits gekippt und der Controller
der SSD hats nicht gemerkt" zu differenzieren?

Automatismen versagen da m. M. n. komplett.

Volker

 

[Gerrit Heitsch]

On 1/30/19 12:55 PM, Volker Bartheld wrote:

On Wed, 30 Jan 2019 12:46:03 +0100, Gerrit Heitsch wrote:
On 1/30/19 12:41 PM, Hanno Foest wrote:
On 30.01.19 09:06, Gerrit Heitsch wrote:
Mir ist bisher noch keine HD durch Lagerung kaputtgegangem.
Mir schon...
-v bitte.

Gut 20 Jahre alte Festplatte mit IDE Controller, deren Spindelmotor nach
etlichen Jahren des Nichtstuns nicht mehr starten wollte. Die gute alte
Methode mit dem (Gummi)hammerschlag in tangentialer Richtung zum
Plattenstapel half nichts.

Disclaimer: Die exakte Kausalität ist natßrlich genauso ungeklärt wie bei
Deiner These: "mir ist schon einmal eine SSD bei sowas [=längere Zeit ohne
Benutzung] vergesslich geworden.". KĂśnnte auch irgendwelche kosmische
Strahlung oder ein radioaktiver Zerfall gewesen sein, der Deine Platte
eine Sekunde nach dem Abschalten beschädigt hat. Oder ein Firmwareproblem.

Eher Firmwareproblem, die kaputten Daten waren zu weit verteilt als das
ein einzelner Event das hätte verursachen kÜnnen. Auf dem Gerät waren
keine wichtigen Daten, also hat es nicht wirklich gestĂśrt, war aber eben
ein Hinweis darauf, daß eine SSD neue Fehlermodi bringt wie wir sie von
HDs nicht kennen.

Gerrit

 

[Volker Bartheld]

On Wed, 30 Jan 2019 12:46:03 +0100, Gerrit Heitsch wrote:

On 1/30/19 12:41 PM, Hanno Foest wrote:
On 30.01.19 09:06, Gerrit Heitsch wrote:
Mir ist bisher noch keine HD durch Lagerung kaputtgegangem.
Mir schon...
-v bitte.

Gut 20 Jahre alte Festplatte mit IDE Controller, deren Spindelmotor nach
etlichen Jahren des Nichtstuns nicht mehr starten wollte. Die gute alte
Methode mit dem (Gummi)hammerschlag in tangentialer Richtung zum
Plattenstapel half nichts.

Disclaimer: Die exakte Kausalität ist natürlich genauso ungeklärt wie bei
Deiner These: "mir ist schon einmal eine SSD bei sowas [=längere Zeit ohne
Benutzung] vergesslich geworden.". Könnte auch irgendwelche kosmische
Strahlung oder ein radioaktiver Zerfall gewesen sein, der Deine Platte
eine Sekunde nach dem Abschalten beschädigt hat. Oder ein Firmwareproblem.

Volker

 

[Gerrit Heitsch]

On 1/30/19 12:46 PM, Volker Bartheld wrote:

On Wed, 30 Jan 2019 06:50:59 +0100, Gerrit Heitsch wrote:
Transcend wird auch immer wieder wegen seiner MLC NANDs
beschimpft.
Was man nicht ganz so einfach testen kann ist der Datenerhalt bei
stromloser Lagerung. Kann schliesslich mal vorkommen, daß man aus
irgendeinem Grund die Kiste längere Zeit nicht benutzt.

Das Problem besteht nur darin, das frßhzeitig(!) herauszufinden, nämlich
bevor man die korrupte Datei fĂźr ein Backup wegschreibt. Ich wĂźrde aber
fast einen Besen fressen, wenn der Plattencontroller das nicht mitbekäme,
ECC ist ja nun keine ganz neue Erfindung:

Tja, sollte man meinen. Die bei mir vergesslich gewordene SSD hat
allerdings brav fehlerhafte Daten geliefert. Sah man sehr gut bei
Bildern. Ein Filesystem mit Checksummen wäre da gut gewesen.

Fragt sich also, wie man damit umgeht, wenn das "The driver detected a
controller error on \Device\HarddiskX\DRY" Fenster hochpoppt. Auf "Ja, ist
mir wurscht" klicken, wäre vielleicht keine so dolle Idee.

Nachdem sowas auch bei automatischen Jobs passieren kann wäre es ßbel
wenn da was aufpoppen wĂźrde.

Eines der zahlreichen, unabhängigen Backups zu greifen, die Hashes zu
vergleichen oder sonst eine Integritätsprßfung zu veranstalten wäre dann
schon besser. Hernach kann man sich fragen, warum TRIM und andere Methoden
zur Vermeidung von schleichendem Ladungsverlust nicht funktioniert haben.

TRIM hat damit nichts zu tun und das einzige was du tun kannst ist die
Daten in einer Endlosschleife zu lesen und immer die Schwellwerte zu
checken. Sobald die den spezifizierten Bereich verlassen wird der
fragliche Block umkopiert und gelĂśscht damit er wieder neu beschrieben
werden kann.

Gerrit

 

[Volker Bartheld]

On Wed, 30 Jan 2019 06:50:59 +0100, Gerrit Heitsch wrote:

Transcend wird auch immer wieder wegen seiner MLC NANDs
beschimpft.
Was man nicht ganz so einfach testen kann ist der Datenerhalt bei
stromloser Lagerung. Kann schliesslich mal vorkommen, daß man aus
irgendeinem Grund die Kiste längere Zeit nicht benutzt.

Das Problem besteht nur darin, das frühzeitig(!) herauszufinden, nämlich
bevor man die korrupte Datei für ein Backup wegschreibt. Ich würde aber
fast einen Besen fressen, wenn der Plattencontroller das nicht mitbekäme,
ECC ist ja nun keine ganz neue Erfindung:

http://www.digilux.com.tw/faq.php?p=5&id=25
https://thessdguy.com/extreme-ssd-error-correction

Fragt sich also, wie man damit umgeht, wenn das "The driver detected a
controller error on \Device\HarddiskX\DRY" Fenster hochpoppt. Auf "Ja, ist
mir wurscht" klicken, wäre vielleicht keine so dolle Idee.

Eines der zahlreichen, unabhängigen Backups zu greifen, die Hashes zu
vergleichen oder sonst eine Integritätsprüfung zu veranstalten wäre dann
schon besser. Hernach kann man sich fragen, warum TRIM und andere Methoden
zur Vermeidung von schleichendem Ladungsverlust nicht funktioniert haben.

> Und ja, mir ist schon einmal eine SSD bei sowas vergesslich geworden.

Ist bei konventionellen Drehplatten auch schon vorgekommen.

Volker

 

[Gerrit Heitsch]

On 1/30/19 12:41 PM, Hanno Foest wrote:

On 30.01.19 09:06, Gerrit Heitsch wrote:

Mir ist bisher noch keine HD durch Lagerung kaputtgegangem.

Mir schon...

-v bitte.

Gerrit

 

[Gerrit Heitsch]

On 1/30/19 1:22 PM, Volker Bartheld wrote:

On Wed, 30 Jan 2019 13:15:12 +0100, Gerrit Heitsch wrote:
ein Hinweis darauf, daß eine SSD neue Fehlermodi bringt wie wir sie von
HDs nicht kennen.

Definitiv. Wie wir schon diskutiert hatten, grenzt es an ein Wunder oder
ist mir zumindest ein Rätsel, wie man bei ßblicher Hardware fßr den
Heimgebrauch etlich TB an Daten fehlerfrei von A nach B kopieren kann.

Naja, dafĂźr gibt es ECC und CRC auf den Datenpfaden. Nur beim RAM wird
ECC gerne eingespart. Da wundert mich, daß nicht mehr passiert, bei den
heute Ăźblichen Frequenzen zwischen Speichercontroller und Ram-Chip.

Auch der Ersatz nicht. Über DVD-Rs und untrschiedliche Dyes sowie
DVD-RAMs usw. hatten wir ja auch schon diskutiert.

Ich hatte damals mit DVD-RW/+RW gute Erfahrungen gemacht. Mit denen
hatte ich im Gegensatz zu den '-R/+R' keinen Ärger.


Gerrit

 

[Matthias Weingart]

Eric Bruecklmeier <usenet@nerdcraft.de>:

Am 29.01.2019 um 08:31 schrieb Gerrit Heitsch:
On 1/29/19 8:22 AM, Eric Bruecklmeier wrote:
Am 28.01.2019 um 22:14 schrieb Patrick Schaefer:
Am 27.01.2019 um 23:13 schrieb Volker Bartheld:

 > Sicher gibt es irgendwelche Specs und Marketingaussagen, warum man
die Pro
 > einer Evo vorziehen sollte.

850 Evo speichert 3 bit pro Flashzelle, 850 Pro nur 2 bit.

Ernsthaft 3 *Bit*? Das mag ich kaum glauben...

Doch, ist in zwischen leider Ăźblich. Es gibt sogar SSDs mit 4 Bits pro
Zelle. Samsung 860 QVO z.B.

Wie lange das gutgeht steht auf einem anderen Blatt.

Interessant, wir waren damals so "naiv" den Spielraum als
Sicherheitsfeature zu nutzen...

https://patents.google.com/patent/WO2001029840A1/

Bei einigen MSP430 kann man (*theoretisch) die Qualität des Flash testen und
den dann bei Bedarf neuschreiben. Sinnvoll wenn der bei >120°C eingesetzt
wird (automotive?).
*Theoretisch deshalb, weil dem Errata zufolge immer genau diese Funktion
nicht richtig funktioniert hat. ;-)

M.
--

 

Volker Bartheld wrote:

[...]
Das Problem besteht nur darin, das frßhzeitig(!) herauszufinden, nämlich
bevor man die korrupte Datei fĂźr ein Backup wegschreibt. Ich wĂźrde aber
fast einen Besen fressen, wenn der Plattencontroller das nicht mitbekäme,
ECC ist ja nun keine ganz neue Erfindung:
[...]

Bei SCSI-Platten war die Häufigkeit solcher Ereignisse frßher teilweise
im Manual spezifiziert. Beispiel Cheetah 15K.6 FC:
|
| Read Error Rates
| Recovered Data Less than 10 errors in 10š² bits transferred
| (OEM default settings)
| Unrecovered Data Less than 1 sector in 10š⁜ bits transferred
| Miscorrected Data Less than 1 sector in 10²š bits transferred

Außerdem können die Daten auch im Hauptspeicher (bzw. auf dem Weg
dorthin) kaputt gehen. Auch dafĂźr gibt es ECC, aber auch dort wird
es mit einer gewissen Wahrscheinlichkeit versagen.

Am Ende muss man sich fragen was "gut genug" ist bzw. wie viel man
bereit ist zu bezahlen. Wenn es teuer wird, sind auch schlechtere
Werte plĂśtzlich doch "gut genug".

 

[Volker Bartheld]

On Wed, 30 Jan 2019 13:29:41 +0100, Gerrit Heitsch wrote:

Wie wäre denn die Handlungsempfehlung eine Datei mit gleichem Datum
(Erstellung, Modifikation, usw.), Länge, ... aber unterschiedlichem Inhalt
entweder der Kategorie "User hat die Datei willentlich verändert" oder der
Kategorie "durch Alterung/Lagerung sind Bits gekippt und der Controller
der SSD hats nicht gemerkt" zu differenzieren?

Gleiches Modifikationsdatum aber unterschiedlicher Inhalt kann nicht der
User gewesen sein, denn dann wäre das Datum unterschiedlich.

Leider steht das Modifikationsdatum nicht unter Alleinherrschaft des OS.
Zumindest bei Windows trifft das zu und es gibt genug Programme, die am
Modifikations- und Zugriffdatum herumpopeln. Es ist nicht vernünftig, aber
- z. B. mit dem Total Commander trivial möglich und vor diesem Hintergrund
als Unterscheidungskriterium nicht geeignet. Wenn wir das Bitrot-Faß
aufmachen, dann steht die stinkende Kiste mit Aufschrift "Mal-/Crapware"
leider unmittelbar daneben.

Das Problem ist in diesem Falle automatisiert rauszufinden welche Datei
jetzt die korrekte ist und welche die kaputte. Üblicherweise wäre die
korrekte die auf dem Backup, wenn das nicht auch auf einer SSD liegt.

*sic* Genau. Oder die Drehplatten im Backup haben was. Oder deren
Controller. Oder es stimmt was mit der Firmware im NAS nicht. Oder es ist
während der initialen Kopie schon was schiefgelaufen. Oder, oder, oder, ...

Ob sich Otto-Normal-DAU darüber einen Kopf macht? Vermutlich nicht. Die
Cloud ist doch sicher.

Volker

 

[Volker Bartheld]

On Wed, 30 Jan 2019 13:32:10 +0100, Gerrit Heitsch wrote:

On 1/30/19 1:22 PM, Volker Bartheld wrote:
Über DVD-Rs und untrschiedliche Dyes sowie
DVD-RAMs usw. hatten wir ja auch schon diskutiert.
Ich hatte damals mit DVD-RW/+RW gute Erfahrungen gemacht. Mit denen
hatte ich im Gegensatz zu den '-R/+R' keinen Ärger.

Selbst wenn sie ewig hielten. Sie sind leider zu klein und daher nicht
praktikabel.

Volker

 

[Gerrit Heitsch]

On 1/30/19 2:09 PM, Volker Bartheld wrote:

On Wed, 30 Jan 2019 13:29:41 +0100, Gerrit Heitsch wrote:
Wie wäre denn die Handlungsempfehlung eine Datei mit gleichem Datum
(Erstellung, Modifikation, usw.), Länge, ... aber unterschiedlichem Inhalt
entweder der Kategorie "User hat die Datei willentlich verändert" oder der
Kategorie "durch Alterung/Lagerung sind Bits gekippt und der Controller
der SSD hats nicht gemerkt" zu differenzieren?

Gleiches Modifikationsdatum aber unterschiedlicher Inhalt kann nicht der
User gewesen sein, denn dann wäre das Datum unterschiedlich.

Leider steht das Modifikationsdatum nicht unter Alleinherrschaft des OS.
Zumindest bei Windows trifft das zu und es gibt genug Programme, die am
Modifikations- und Zugriffdatum herumpopeln.

Kaputte OS kĂśnnen zu kaputten Daten fĂźhren. Von Hand kann man das zwar
immer faken, aber der Default sollte es nie sein.

*sic* Genau. Oder die Drehplatten im Backup haben was. Oder deren
Controller. Oder es stimmt was mit der Firmware im NAS nicht. Oder es ist
während der initialen Kopie schon was schiefgelaufen. Oder, oder, oder, ...

Defekte Platten solltest du aber mit der PrĂźfsumme des FS ausschliessen
kĂśnnen.

Ob sich Otto-Normal-DAU darĂźber einen Kopf macht? Vermutlich nicht. Die
Cloud ist doch sicher.

So? Wer sagt denn, daß die Daten dort nicht auch kaputtgehen können?
Liegen dort schliesslich auch nur auf HDs oder SSDs.

Gerrit

 

[Gerrit Heitsch]

On 1/30/19 2:10 PM, Volker Bartheld wrote:

On Wed, 30 Jan 2019 13:32:10 +0100, Gerrit Heitsch wrote:
On 1/30/19 1:22 PM, Volker Bartheld wrote:
Über DVD-Rs und untrschiedliche Dyes sowie
DVD-RAMs usw. hatten wir ja auch schon diskutiert.
Ich hatte damals mit DVD-RW/+RW gute Erfahrungen gemacht. Mit denen
hatte ich im Gegensatz zu den '-R/+R' keinen Ärger.

Selbst wenn sie ewig hielten. Sie sind leider zu klein und daher nicht
praktikabel.

Jetzt schon, damals noch nicht.

Heute mache ich Backups u.a. auf externe HDs die danach stromlos und vom
Rechner getrennt gelagert werden. Dann rĂśstet mir wenigstens ein
Gewitter zur falschen Zeit nicht alle Daten.

Und ja, so alle paar Wochen mache ich einen binary verify der Daten im
Backup mit dem Original. Dauert zwar fast einen Tag, aber danach weiss
ich, daß noch alles gut ist.

Gerrit