Forum: PC Hard- und Software Warnung vor WD MyCloud


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bernd K. (prof7bit)


Bewertung
3 lesenswert
nicht lesenswert
Die MyCloud ist ein NAS für geiz ist geil Konsumenten und hat einen 
USB3-Anschluss um beliebig viele zusätzliche USB-Platten anschließen zu 
können. Drinnen ist ein ARM-Board mit GbE, SATA und USB3 und eine 3TB 
Platte, Irgend ein von WD verkorkstes Linux läuft drauf aber man kann 
ohne Klimmzüge ein sauberes Debian drauf installieren weil alles offen 
ist, es kann sogar von USB booten. Wenn man sich das selber zusammenbaut 
inkl. Gehäuse und Netzteil wirds auch nicht billiger. Eigentlich eine 
nette Plattform für den Preis.

Dachte ich.

existierende 2TB Platte mit Filmen drangestöpselt, ssh eingeloggt und

  cp -rv /mnt/Filme2/* /mnt/internal/

6 Stunden später kommt das Prompt zurück. Kurz nachgeschaut, alles an 
Ort und Stelle, nix vergessen, schaut gut aus. jetzt die externe Platte 
endlich mal auf Ext4 formatieren (lange überfällig) und alles wieder 
zurück.

  cp -rv /mnt/internal/* /mnt/Filme2/

Absturz nach 5 Sekunden. Dmesg geschaut: USB-Device hat sich abgemeldet, 
Platte verschwunden. Neustart, zweites terminal mit dmesg -w daneben 
gelegt, fsck, mounten, Überreste löschen, schaut gut aus, also nochmal

  cp -rv /mnt/internal/* /mnt/Filme2/

Absturz nach 5 Sekunden. Kilometerlange IO-Error im dmesg, device reset, 
erfolglos, USB-Platte verschwunden.

USB-Platte an PC angeschlossen (leider nur USB2) und hol ich mir die 
Dateien übers Netzwerk zurück.

  cp -rv /mnt/mycloud/internal/* /media/bernd/Filme2/

14 Stunden später kommt das Prompt zurück, alles wieder auf der 
USB-Platte.

Dachte ich.

Später die Schrottkiste nochmal mit Debian und neuerem Kernel gebootet, 
selbes Symptom, USB schreiben Fehlanzeige bei 3 verschiedenen externen 
Platten, mit oder ohne Hub (alle haben übrigens ein eigenes Netzteil). 
Schrott hoch 3. MyCloud zurück, Geld zurück.

2 Wochen später:

Alle Videos sind auf subtile Weise beschädigt. Alle 50 MB ungefähr ist 
ein I-Frame beschädigt, bei manchen sieht man es kaum, bei manchen 
unerträglich. Es muss bereits beim Lesen von der USB-Platte passiert 
sein, aber da traten angeblich keine Fehler auf! cp lief 6 Stunden 
durch! Wer rechnet denn mit sowas?

Das ist das erste Mal in 30 Jahren daß mir beim Kopieren Dateien 
kaputtgehen ohne daß irgendwelche Fehlermeldungen auftauchen.

Lasst bloß die Finger vom diesem Schrott.

Hab jetzt ein Rock64 mit GbE und USB3 mit Debian Stretch für mein 
Ghetto-USB-NAS und das lief von der ersten Sekunde an wie am Schnürchen.

: Bearbeitet durch User
von oszi40 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
MD5 ist eine Prüfsumme.  md5sum hilft bei Linux.

von Marek N. (bruderm)


Bewertung
3 lesenswert
nicht lesenswert
Das ist noch dein kleinstes Problem.
Bei der WD MyCloud ist das root-Passwort im Klartext fest in der 
Firmware programmiert und somit nicht änderbar. D.h. sobald die Platte 
am Netzwerk hängt, kommt jedes Scriptkiddie drauf.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
oszi40 schrieb:
> MD5 ist eine Prüfsumme.  md5sum hilft bei Linux.

Wie schon geschrieben, das ist das erste Mal in 30 Jahren dass mir mit 
cp Dateien kaputt gegangen sind oder daß ich auch nur davon gehört hätte 
daß das jemand anderem jemals passiert wäre.

von g457 (Gast)


Bewertung
-8 lesenswert
nicht lesenswert
> Wer rechnet denn mit sowas?

..jeder mit Ahnung (oder Erfahrung). Wie schon geschrubt gibts ∗genau∗ 
dafür Prüfsummen.

Nix für ungut.

von Bernd K. (prof7bit)


Bewertung
3 lesenswert
nicht lesenswert
g457 schrieb:
> ..jeder mit Ahnung (oder Erfahrung).

Sorry, aber das ist Bullshit, das mußt Du selber zugeben.

Erfahrung daß bei einem ganz normalen cp nichts kaputt geht denn 
Datenintegrität wird von tieferen Schichten garantiert, dazu sind sie 
da, Festplattensektoren sind mit CRC geschützt, USB-Pakete sind mit CRC 
geschützt, Fehlermeldungen werden nach oben propagiert! Kein Mensch 
checkt den ganzen Tag lang Prüfsummen bei solchen trivialen 
Allerweltstätigkeiten wie Dateien von einem Ordner in den anderen zu 
kopieren. Du auch nicht!

Und selbst wenn, wie soll ich bitteschön eine Prüfsumme erechnen und 
vergleichen wenn mir der kaputte USB Host-Controller der MyCloud beim 
Lesen schon stillschweigend bösartig genau jedes millionste Bit 
umkippt, und zwar jedesmal das selbe, ohne dabei einen IO-Fehler nach 
oben zu werfen?

Auf irgendwas muss man sich verlassen können. Wer garantiert Dir daß das 
Prüfsummentool funktioniert? Bauchgefühl oder irgendeine Garantie daß 
fatale exceptions normalerweise nach oben propagiert und nicht 
stillschweigend verschluckt werden?

Wenn Du einen nagelneuen PC kaufst von einem namhaften Hersteller 
checkst Du dann erstmal mit mindestens 2 anderen Referenz-PCs und der 
selben Festplatte daß der SATA-Controller in dem neuen Gerät nicht 
zufällig beim Lesen genau alle 64MB heimlich genau ein Byte verschluckt? 
Kannst Du mir Präzedenzfälle nennen bei denen man mit sowas bescheuertem 
hätte rechnen müssen?

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Erfahrung daß bei einem ganz normalen cp nichts kaputt geht denn
> Datenintegrität wird von tieferen Schichten garantiert,

Ich bezweifle, dass so ein Billigteil mit ECC-RAM arbeitet. 
Möglicherweise macht es bei Start auch keinen RAM-Test. Ein teilweise 
defektes RAM kann zu Datenschrott führen.

Ist recht selten, aber irgendwen muss es mal erwischen. Und dann lieber 
dich als mich ;-) (ok, mein Serverlein hat ECC).

: Bearbeitet durch User
von oszi40 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
A. K. schrieb:
> mein Serverlein hat ECC

Bei Plattenfehler freut man sich über gesunden RAM, aber helfen wird es 
nicht. Nicht umsonst wird zu einigen Linux-Distibutionen eine Prüfsumme 
mitgeliefert. Allerdings gab es Zufälle, wo die Prüfzahlen wieder 
stimmten. Genau deswegen gibt es verschiedene Prüfverfahren wie CRC, 
LRC, MD5 usw. Beispiel 
Suse:https://software.opensuse.org/distributions/leap?locale=de

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
oszi40 schrieb:
> Bei Plattenfehler freut man sich über gesunden RAM, aber helfen wird es
> nicht.

ECC-RAM ist nur ein Glied in der Kette.

Wobei Plattenfehler sich praktisch immer bemerkbar machen und so gut wie 
unmöglich ist, dass dabei alle 64MB ein Byte futsch ist.

> Nicht umsonst wird zu einigen Linux-Distibutionen eine Prüfsumme
> mitgeliefert.

Mach dir um mich keine Sorgen. Mein Serverlein verwendet btrfs, das hat 
CRCs auch im Filesystem. ;-)

: Bearbeitet durch User
von oszi40 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> CRCs auch im Filesystem

Ich mache mir keine Sorgen. Es gab aber Fälle, wo eine Prüfzahl trotz 
Fehler ZUFÄLLIG STIMMTE. Deshalb hatte z.B. 1/2" Magnetband LRC und CRC 
und Paritätsprüfung.

von soso (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wer wie ich schon mal Besitzer einer IBM-Deathstar-Festplatte war *1), 
kennt das. Dein Fehlerbild stimmt exakt mit dem überein, welches ich 
damals hatte.

Bei mir hats damals unter Anderem meine mp3-Sammlung zerlegt. Noch heute 
habe ich Musikstücke mit Fehlern drin. Woraus ich den Schluss gezogen 
habe, dass Backups doch nicht nur für Weicheier sind.

Was ich also vermute:
Western Digital kann nur insofern was dafür, als dass deine Platte einen 
physikalischen Schaden hat. Ein fehlerhaftes Produkt eben. Es kann 
durchaus sein, dass deine Platte z.B. einen Transportschaden abbekommen 
hat.

Einen Serienfehler würde ich erst mal nicht vermuten. Weshalbe ich mit 
Warnungen für die ganze Serie vorsichtig würde.

*1) kuckt man hier:
https://en.wikipedia.org/wiki/Deskstar

von Karl (Gast)


Bewertung
2 lesenswert
nicht lesenswert
soso schrieb:
> Woraus ich den Schluss gezogen
> habe, dass Backups doch nicht nur für Weicheier sind.

Und wie stellst Du sicher, dass Du den Fehler bemerkst, bevor Du ihn 
backupst?

Ich habe eine 20 Jahre alte Word-Datei, die nicht mehr lesbar ist, weil 
da irgendwann ein Bit gekippt ist. Dummerweise ist auf sämtlichen CD, 
DVD und später Festplatten-Backups der Fehler schon drauf...

von Bernd K. (prof7bit)


Bewertung
2 lesenswert
nicht lesenswert
oszi40 schrieb:
> Bei Plattenfehler freut man sich über gesunden RAM, aber helfen wird es
> nicht.

Es war ja kein Plattenfehler. Die Platte ist nachweislich immer noch 
100% OK und funktioniert tadellos.

Der Fehler war irgendwo in dem MyCloud-Gerät welches übrigens von 
Western Digital (und nicht von Ching Chang-Chung aus Hong-Kong) 
vermarktet wird und die explizit als NAS beworben wird.

Ich kenne keinen dem jemals ein neu gekauftes NAS gleich beim ersten 
Kopier-Job 2TB an Daten auf derart subtile Weise geschrottet hat ohne 
auch nur einen einzigen(!) Fehler zu werfen.

Fehler hat sie erst beim zweiten Kopierjob in die andere Richtung 
geworfen, aber zu dem Zeitpunkt waren die Daten schon im Arsch.

Und weil ich diese spezielle Art der Datenschrottung für so 
bemerkenswert und ungewöhnlich halte postete ich diesen Thread als 
Warnung um andere Personen davon abzuhalten sich versehentlich diesen 
als NAS umgelabelten Datenschredder zu kaufen.

von soso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> soso schrieb:
>> Woraus ich den Schluss gezogen
>> habe, dass Backups doch nicht nur für Weicheier sind.
>
> Und wie stellst Du sicher, dass Du den Fehler bemerkst, bevor Du ihn
> backupst?
>
> Ich habe eine 20 Jahre alte Word-Datei, die nicht mehr lesbar ist, weil
> da irgendwann ein Bit gekippt ist. Dummerweise ist auf sämtlichen CD,
> DVD und später Festplatten-Backups der Fehler schon drauf...

Das kann passieren, ja. Aber in vielen Fällen hilft das.

Damals hätte es geholfen. Beim Lesen der dateien gab es natürlich Fehler 
und entsprechende Fehlermeldungen. Da war es schon zu spät.

Würde man ein Backup machen, würde es spätestens da auffallen.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> btrfs, das hat
> CRCs auch im Filesystem. ;-)

Dann weiß ich jetzt immerhin womit ich die nächsten NAS-Platten 
formatiere. Meine Backup-Platte hat das schon aber nur weil ich dann 
dort Kompression und Snapshots statt Hardlink-Farmen für inkrementelles 
Backup verwenden kann, aber daß CRC auf Datenblöcke direkt im 
Dateisystem sich als Vorteil erweisen könnte weiß ich erst seit ich zum 
ersten Mal lautlose Network-Attached Shredder mit USB3-Anschluss gesehen 
habe.

: Bearbeitet durch User
von --- (Gast)


Bewertung
0 lesenswert
nicht lesenswert
So subtile Fehler hatte ich vor Jahren beim Kopieren
von einer USB-HD auf eine zweite USB-HD.

BS damals XP3.

Der Fehler verschwand voellig, wenn 2 USB-Adapter im
Rechner steckten. Einmal der vom Motherboard selber,
plus ein NEC-Adapter und die Platten jeweils ihren
eigenen USB-Adapter hatten.

von (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Erfahrung daß bei einem ganz normalen cp nichts kaputt geht denn
> Datenintegrität wird von tieferen Schichten garantiert, dazu sind sie
> da, Festplattensektoren sind mit CRC geschützt, USB-Pakete sind mit CRC
> geschützt, Fehlermeldungen werden nach oben propagiert! Kein Mensch
> checkt den ganzen Tag lang Prüfsummen bei solchen trivialen
> Allerweltstätigkeiten wie Dateien von einem Ordner in den anderen zu
> kopieren. Du auch nicht!

Gerade bei einem neuen System bin ich zumindest paranoid und überprüfe 
sowas, bevor ich eine Platte lösche. Auspacken, einschalten, geht nicht 
kommt vor. Gerade kritische Geräte sollte man einer Art "Burn In" 
unterziehen, damit man sich halbwegs sicher ist, dass das Ding auch 
richtig funktioniert.

Frisch geschriebenen Festplattensektoren werden üblicherweise nicht 
wieder eingelesen und verifiziert, das würde man an einer nicht mal halb 
so großen Schreib- wie Leserate massiv merken. So lang man das also 
nicht selber wieder einliest kriegt die Festplatte von eventuell 
schlechten Prüfsummen auf der Plattenoberfläche nichts mit.

> Und selbst wenn, wie soll ich bitteschön eine Prüfsumme erechnen und
> vergleichen wenn mir der kaputte USB Host-Controller der MyCloud beim
> Lesen schon stillschweigend bösartig genau jedes millionste Bit
> umkippt, und zwar jedesmal das selbe, ohne dabei einen IO-Fehler nach
> oben zu werfen?

Die Prüfsummen kann man ja bei wichtigen Dateien gleich an Ort und 
Stelle pro Directory mitabspeichern. Bevor man die Quell-Platte löscht 
einmal überprüfen. Eiert dabei der USB Controller oder sonstwas hat man 
noch nichts gelöscht.

> Auf irgendwas muss man sich verlassen können. Wer garantiert Dir daß das
> Prüfsummentool funktioniert? Bauchgefühl oder irgendeine Garantie daß
> fatale exceptions normalerweise nach oben propagiert und nicht
> stillschweigend verschluckt werden?

Garantien gibts sowieso keine. Alles eine Frage der Wahrscheinlichkeit.

von bastel_ (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Seit 20 Jahren pack ich immer eine ".md5" pro Verzeichnis zu meinen 
Dateien und verifziere die meist auch nach Kopierorgien. Ist so eine 
Angewohnheit, tut nicht weh und bringt auch mal was. Duplikate finden, 
z.B.

Als mir ein Speicherfehler Bits zerhauen hat, konnte ich nach Analyse 
und Erkennen des Fehlermusters  per (optimiertem) Bruteforce so lange 
Bits toggeln, bis die MD5 wieder stimmte, und ja die Music/Videos waren 
danach wieder einwandfrei :)

Verloren hat man, wenn da ganze 512 Byte Blöcke genullt werden, kenn ich 
auch von defekten Controllern und so.
Unter NTFS und EXT4, XFS kann man die Checksumme auch gleich in einem 
erweiterten Attribut mitführen und sich dann periodische Tests/Scrubbing 
machen (gibt's fertige Skripte/Tools, ich hab mein eigenes Zeug)

cp hat glaube auch ein Verifyflag.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
bastel_ schrieb:
> Verloren hat man, wenn da ganze 512 Byte Blöcke genullt werden

Ist nicht der Fall, im hex editor sieht man nichts auffälliges.

von bastel_ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Man braucht unbedingt die selbe Datei einmal kaputt und einmal ganz, nur 
so kann man feststellen, was wie zerschossen wurde. Hab auch schon 
gesehen, das ganz einfach zwei Bytes am Anfang eines 512 Byte Blocks 
verschwanden und Müll ans Ende wanderte.  Wenn es ein Paar(!) 
nachvollziehbare Bitkipper pro 1 oder 4 Kilobyte sind und man einen 
kryptografischen Hashcode zur Hand hat, dann kann man da was machen, 
sonst nicht.

Das einzige wo noch ein Fehler reinpropagieren kann ist dann das 
Entpacken einer Datei während der Fehler besteht. Wer überprüft schon 
die entpackte Datei mit der CRC32 aus dem Archiv. Das Entpackprogramm? 
Ja. Aber wenn der Fehler danach im Cache oder auf dem Weg zur Platte 
passiert... und wenn da dann die MD5 generiert wird ist die eh auch 
kaputt.

Ich hab schon Platten gesehen, die reproduzierbar Bits haben kippen 
lassen, wenn sie warm wurden.

Laberteil:
Lerneffekt? Hmm. Zu DOS Zeiten FAT zerschossen, mit Diskeditor Daten 
gerettet. FreeBSD Raid zerschossen, Rettungstools konnten viel, aber 
nicht das Wichtigste retten, deshalb eigenen UFS2 Inodeparser 
geschrieben, der einige Terabyte durchgekaut und von Datenblöcken, wo 
ich wusste, das da die Daten liegen, heuristisch auf indirekte 
Inodetabellen geschlossen und dann per Bruteforce wieder zusammengesetzt 
hat - es fehlten logischerweise die ersten 12 direkten Blöcke, war aber 
eine 4 GB Rardatei, da konnte ich das meiste rausholen).
Ich lager meine Daten nun offline im Schrank auf einzelnen USB Platten, 
allerdings bis jetzt nicht dupliziert, ist zu viel, und nicht sooo 
wichtig. Wollte mal dafür ein offline Raid 4 schreiben, bis jetzt nie 
dazu gekommen ;)
Ein NAS betrachte ich nun nur noch als Puffer für Daten, die ich grade 
bereitstellen / streamen will. Nicht als Referenz. Und das wickelt mein 
Server gleich so nebenbei mit ab.

Nur mein Arbeitssystem mit meinem persönlichen Emails, Code etc hat 
Backups. Persönliche Bilder sortieren und ausmisten, als Photobuch 
physikalisch verewigen, Familienfilme zusammenschneiden und neben HDD 
auf DVD brennen. Wer privat profimäßig Photos/Filme macht braucht 
natürlich ein richtiges Backup, so wie ich meinen Code sichere. 
Ansonsten digitale Sammelwut überwinden bzw dortige Verluste 
achselzuckend abtun. Das Leben geht weiter.

von c.m. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
bastel_ schrieb:
> Lerneffekt?
> ...
> Ich lager meine Daten nun offline im Schrank auf einzelnen USB Platten

dito. backups alternierend auf 4 3TB platten, verschlüsselt, eine davon 
ist im büro falls mir die bude abbrennt.

ich wollte dem nicht schon wieder einem TO mit datenverlust schreiben, 
dass er halt das letzte gültige backup restoren soll - ist schließlich 
unfreundlich.
andererseits ists auch wahr.

von Reinhard S. (rezz)


Bewertung
0 lesenswert
nicht lesenswert
c.m. schrieb:
> ich wollte dem nicht schon wieder einem TO mit datenverlust schreiben,
> dass er halt das letzte gültige backup restoren soll - ist schließlich
> unfreundlich.
> andererseits ists auch wahr.

Blöd wenn der Fehler, wie hier schonmal geschrieben, im letzten gültigen 
Backup ebenfalls enthalten ist ;)

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Reinhard S. schrieb:
> im letzten gültigen Backup ebenfalls enthalten ist ;)

Jahrelang faule Eier im Backup?
-Es könnte eine andere Prüfsumme auffallen?
-Es könnte auch ein bisher unerkannter Virus gewütet haben?
-Leider besteht ja ein Backup nicht nur aus 3 Dateien, die nieee 
verändert werden...

von Gero (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ TO
welche NAS hast Du denn genau und welche Firmware werkelt darauf!?

Ich habe die myCloud miror mit 2x2TB aus der 1. Generation, Firmware ist 
die 2.11.168.

Mein PC beinhaltet die Arbeitskopien von allem, was auch auf der NAS 
ist. Die Projekte selbst sind auf der gespiegelten NAS die wiederrum 
regelmäßig über den UBS3.0-Port auf eine ext. 2,5" HDD gesichert wird.

Habe jetzt mal die größeren Dateien direkt im Hashwert verglichen und 
recht viele Ordner, die sehr, sehr viele kleine Dateien beihnalten als 
gezipptes File im Hash-wert kontrolliert. (PC- NAS - ext. 
Datensicherung)

Ich habe nicht eine einzige Abweichung gefunden....

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Gero schrieb:
> welche NAS hast Du denn genau und welche Firmware werkelt darauf!?
>
> Ich habe die myCloud miror mit 2x2TB aus der 1. Generation, Firmware ist
> die 2.11.168.

Es war die zweite Generation, ich hab sämtliche dafür existierenden 
Firmwares ausprobiert, von der ältesten bis zur aktuellen und außerdem 
noch ein inoffizielles Debian-Image mit relative aktuellem Kernel, alle 
zeigten exakt das selbe Symptom: Beim USB schreiben crashte der USB 
Treiber spätestens nach etwa zwei bis drei GB am Stück. Beim USB lesen 
crashte es nicht und lief scheinbar durch (leider, sonst hätt ich noch 
rechtzeitig bemerkt daß irgendwas faul ist).

Der Hinweis mit dem defekten RAM weiter oben hat mich hellhörig gemacht. 
Das könnte eventuell die Symptome erklären.

von g457 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> Sorry, aber das ist Bullshit, das mußt Du selber zugeben.

Nope. So ist die Realität leider.

> [..] Datenintegrität wird von tieferen Schichten garantiert [..]

Niemand garantiert da auch nur irgendwas.

> Und selbst wenn, wie soll ich bitteschön eine Prüfsumme erechnen und
> vergleichen [..]

Die legst Du mit ab wenn Du die Originale das erste Mal ablegst. Und 
wenns wichtig war prüfst Du sie auch dann das erste mal. Und wenns 
wirklich wichtig ist machst Du auch ein Backup (von den Originalen, auf 
einem anderen Datenträger, auch mit Prüfsummen versehen versteht sich, 
und die werden latürnich auch geprüft).

> Kannst Du mir Präzedenzfälle nennen bei denen man mit sowas bescheuertem
> hätte rechnen müssen?

Reihenweise. Nennt sich Erfahrung. Verbuche Deine doch einfach unter 
Lehrgeld und mach es das nächste mal besser.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
g457 schrieb:
>> Kannst Du mir Präzedenzfälle nennen bei denen man mit sowas bescheuertem
>> hätte rechnen müssen?
>
> Reihenweise.

Na dann mal her damit, ich höre?

von Peter D. (peda)


Bewertung
3 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Absturz nach 5 Sekunden. Kilometerlange IO-Error im dmesg, device reset,
> erfolglos, USB-Platte verschwunden.
>
> USB-Platte an PC angeschlossen (leider nur USB2) und hol ich mir die
> Dateien übers Netzwerk zurück.

Ich würde nie ein Backup überschreiben, wenn auch nur die allerkleinste 
Unregelmäßigkeit auftritt.
Wichtige Daten habe ich immer 3-fach gespeichert, also eine Arbeitskopie 
+ 2 Backups. Sobald ich eins davon zerstört wähne, erstmal einen Tag 
darüber nachdenken, was genau passiert ist. Und dann ganz ruhig wieder 
eine 3. Kopie erzeugen, binär vergleichen und aufatmen.
Ich verstehe das, daß man in der Hektik völlig irrational reagiert und 
z.B. Quelle und Ziel vertauscht, d.h. die Quelle neu formatiert. Daher 
bei 2 Backups darf man sich das einmal erlauben. Selbstverständlich sind 
auch die 2 USB-Backup-HDDs nie gleichzeitig an den PC/NAS angeschlossen.

von Bernd K. (prof7bit)


Bewertung
2 lesenswert
nicht lesenswert
Peter D. schrieb:
> Ich würde nie ein Backup überschreiben, wenn auch nur die allerkleinste
> Unregelmäßigkeit auftritt.

Leider trat die erste Unregelmäßigkeit erst auf als ich die Daten auf 
die zu diesem Zeitpunkt bereits umformatierte Platte zurückspielen 
wollte.

Vorher lief alles vollkommen reibungslos und wiegte mich in dem Glauben 
die Dateien seien jetzt nach einem vollkommen unauffällig verlaufenden 
lokalen(!) Kopiervorgang alle auf der nagelneuen WD Platte unversehrt 
angekommen (wie schon tausendmal zuvor bei unzähligen anderen 
Gelegenheiten in den letzten zig Jahren).

> Wichtige Daten

Wichtige Dateien habe ich auch redundant und wichtige Schlüssel sogar 
teilweise nochmal separat auf Papier.

Die besagten Filme auf der Platte sind alle nicht unwiederbringlich, es 
sind Kopien, keine Orginale, es ist einfach nur gerade eben ärgerlich 
genug um es nicht ignorieren zu können und mich dazu zu veranlassen mich 
über dieses elende Drecksteil aufregen zu müssen.

: Bearbeitet durch User
von Sebastian L. (sebastian_l72)


Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> oszi40 schrieb:
>> MD5 ist eine Prüfsumme.  md5sum hilft bei Linux.
>
> Wie schon geschrieben, das ist das erste Mal in 30 Jahren dass mir mit
> cp Dateien kaputt gegangen sind oder daß ich auch nur davon gehört hätte
> daß das jemand anderem jemals passiert wäre.

Ich melde mich dann mal. Kopierfehler ohne Meldung auf Novell Netware, 
irgendwann Mitte 90er.
Nun hast du von einem gehört dem Dateien beim kopieren kaputt gegangen 
sind.

WD myCloud ist halt "Geiz ist Geil". Es gibt schon ältere Warnungen aber 
danke für die Wiederholung.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Ich hab ein Qnap mit Debian drauf, und irgendwann war da mal ein Kernel 
mit kaputtem Ethernet-DMA drauf. Die Daten auf der Platte sind korrekt, 
aber wenn man sie durchs Netzwerk schiebt, gehen sie kaputt... der 
Fehler ist schon lange behoben, der Vertrauensverlust bleibt.

Und ja, sämtliche Übertragungen waren fehlerfrei und vollkommen korrekt 
- nur die Daten waren zerstört.

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
Ich hatte mal nen kaputten RAM-Riegel. Das OS lief im funktionierenden, 
hat also nicht gemuckt. Bei einer Aufräumaktion wurde der defekte Riegel 
vom OS als Cache verwendet und alle Daten, die ich umkopiert hatte, 
waren danach gescrambelt.

von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte bei einem gleichem Gerät die selben Probleme, mit 
Verbindungsabbruch nach ca. 1 TB Übertragung. Allerdings habe ich noch 
keine Dateifehler festgestellt. Ich vermute thermische Probleme im 
Gehäuse als Ursache, denn nach einer mehrstündigen Ruhephase 
funktioniert das Gerät wieder.
Allein es bleibt ein flaues Gefühl wenn Backups plötzlich so komisch mit 
Fehlermeldung abgebrochen werden.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.