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
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.
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.
> Wer rechnet denn mit sowas?
..jeder mit Ahnung (oder Erfahrung). Wie schon geschrubt gibts ∗genau∗
dafür Prüfsummen.
Nix für ungut.
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
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
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
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
> 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.
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
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...
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.
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.
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
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.
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.
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.
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.
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.
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.
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 ;)
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...
@ 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....
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.
> 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.
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?
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.
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
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.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.