Vereinzelt kaputte Dateien b Kopieren übers Netzwerk - plse hlp

Oktavus

Enthusiast
Thread Starter
Mitglied seit
16.11.2010
Beiträge
359
Hi,

ich hab' mir vor einigen Tagen eine *.exe aus dem Internet downgeladen und installiert. Dann hab' ich selbige übers Netz auf meinen Debian-(Home-)Server geschoben. Drei Tage später wollte ich die *.exe auf einer anderen WS installieren - meckert die Installationsroutine 'Die Quelldatei ist beschädigt' und bricht ab. Wie gesagt: vor 3 Tagen hat die exe noch funktioniert ... ???

Nachdem das nun der zweite (ähnliche) Fall innerhalb einiger Tage war, ging ich dem nach: ich hab' testweise mehrmals z.B. 500 (Foto-)Dateien (RAWs) von der Windows-WS auf den Debian-Server (mittels Total Commander) übers Netz (inkl. LWL) kopiert und dann (mit dem Total Commander) einen Datenvergleich gemacht: 3x ging's gut - beim 4. mal waren 3 Dateien unterschiedlich!

Als ich vor vielen Jahren (auf einem anderen PC) ein ähnliches Problem (verbogene Dateien beim Kopieren) hatte, war es der RAM. Natürlich hab' ich jetzt beim aktuellen Fall sofort den RAM in Verdacht gehabt - und sowohl auf der Windows-WS als auch auf dem Debian-Server Memtest 86+ zwei x durchlaufen lassen - ohne Befund.

Was gäb's sonst noch für Verdächtige? Kann eine HDD defekt werden, indem sie gelegentlich Bits verbiegt, während die Smart-Werte OK sind? Oder Netzwerkkomponenten? D.h. wie kann ich den Fehler eingrenzen?

Thx
Oktavus


Windows-WS: ASUS P7P55D, i5/750, 8GB RAM, Win7
Debian-Server: Intel i3 auf einem MSI-Board (Details könnte ich raussuchen, wenn wichtig), Debian Squeeze, Samba-Shares
Netzwerk: TP-Link-Swiches und dazwischen ein LWL mit TP-Link-Medienkonvertern (weil der Server im Nebenhaus steht)
.

-------------------

Update: ich hab' jetzt in der Zwischenzeit -zig GB an Dateien mehrmals auf den Server schaufelt und verglichen ... nichts! Derzeit keine einzige ungleiche Datei. Dabei hab' ich nichts geändert (außer Memtest laufen lassen und damit die Rechner neu gebootet).

Ich versteh's nicht.
.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hier haben wir mal ein schönes Beispiel bei dem einem ein Dateisystem mit Checksumming wie ZFS, ReFS oder btrfs und ECC-Speicher helfen kann.

Mach auf allen Rechnern einen Memtest (mit aktueller Version, am besten den neuen von Passmark von PassMark MemTest86 - Memory Diagnostic Tool) für mindestens 24h und mach bei allen Festplatten einen vollständig Test, z.B. mit smartctl -t long /dev/xyzfestplatte, unter Windows kannst du auch smartctl nutzen oder eines der vielen anderen Programme.
Wenn die Komponenten dann wirklich alle in Ordnung sind kann man sich danach noch mehr Gedanken machen, aber das wären erst mal so die Grundtests bevor man irgendetwas anderes macht. Netzwerk ist eher unwahrscheinlich da TCP automatisch Übertragungsfehler erkennen und korrigieren sollte, aber das schauen wir uns erst später an.
 
Zuletzt bearbeitet:
Danke, GrafikTreiber, für Deinen Input - somit hab' ich jetzt mal einiges an Arbeit (den Server muss ich morgen wegen Umbauarbeiten räumlich auch noch übersiedeln). D.h. es wird dauern ... ich meld' mich wieder.

Danke und lG
 
Hallo Octavus,

das Problem kenne ich. Du kannst dem Memtest so lange laufen lassen wir Du willst, damit findest Du den Fehler nicht. Die Module sind wahrscheinlich in Ordnung.
Bei mir war es die Menge an installieren RAM, obwohl das Board dafür zugelassen war. Ein paar Module raus und alles war wieder in Ordnung. Egal welche Module benutzt wurden. Ob es ein Problem des BIOS war oder in Verbindung mit dem Raidkontroller konnte ich nicht in Erfahrung bringen.

edit: war bei mir auch ein Asus-board.

Gruß millenniumpilot
 
Zuletzt bearbeitet:
Kann auch eine instabile CPU sein, so etwas kennt man normalerweise nur vom OC, aber so etwas kann durch aus auch mit Stock-Komponenten durch suboptimale BIOS-Einstellungen und/oder ein defektes Mainboard/Netzteil passieren. Nach den Memtest und Festplatten teste mal CPU-Last Test mit Prime95 (x64-bit Variante verwenden, wichtig!) für mindestens 6h. Falls du dazu Anleitungen benötigst gibt es diese im OC-Teil vom Luxx sicherlich zur Genüge.

Aber wie schon gesagt, fang erst mit den Sachen an die du für am wahrscheinlichsten hälst. Für mich wäre das in deinem Fall RAM > HDD > CPU (Mainboard/Netzteil können instabile CPU zur Folge haben) > vieles anderes wie Netzwerkkomponenten, Software...

Alternativ kannst du das Problem auch umgehen indem du eine Software wie rsync zur Übertragung nutzt die Hashchecks automatisch macht und gegebenfalls die Datei neu überträgt. Aber das wäre nur ein Workaround, das Problem bleibt ja weiterhin bestehen und könnte auch andere Teile des Systems betreffen.
 
Zuletzt bearbeitet:
Frage: Wieviele rechner sind hier im Spiel?
Einmal Download PC
Einmal Server
Einmal Workstation
...
Kann man den Fehler auf eine Maschine eingrenzen?
Bin nicht sicher ob ich alles richtig verstanden habe aber kann es auch an der Workstation liegen wo der Fehler das erste mal auftrat?
 
Frage: Wieviele rechner sind hier im Spiel?
Eigentlich erst mal 2:

  1. Server (Debian)
  2. Workstation (auf der das Problem mit der defekten *.exe auftrat und von wo ich dann meine Kopierversuche zum Server gemacht hab'). Nennen wir mal diesen Rechner Workstation-1.
Aber es gibt noch weiteres PCs im Haus - jenen meiner besseren Hälfte (Workstation-2) und einige Notebooks. Von WS-2 hab' ich 1000e Fotodateien, die meine Frau vor Monaten auf den Server gesichert hat, abgeglichen - kein Fehler festgestellt.

Kann man den Fehler auf eine Maschine eingrenzen? ... kann es auch an der Workstation liegen wo der Fehler das erste mal auftrat?
Jetzt wo Du es sagst, fallen mir dazu 3 Dinge ein:

  • Auf der WS-1 (mit dem ASUS-Board) hab' ich so ca. alle 2 Monate beim Boot noch vorm Windows-Start einen BSOD! Nach dem Reset-Knopf läuft er dann wie ein Glöcklein. Ich dachte erst mal an einen Kontaktfehler ... und hab' (vor ca. 4 Wochen) alle Kabelverbindungen gelöst, RAM & GraKa raus und wieder rein gesteckt.
  • Im BIOS ist z.Z. die Leistung auf 'Turbo-Modus' gesetzt (was immer das heißen mag).
  • Wenn ich mich nicht irre, ist mir auf diesem Rechner schon mal ein Corsair kaputt geworden.
Hmmm ... rückt das jetzt die WS-1 in vorderste Front des Kreises der Verdächtigen? Vielleicht stört's, dass im BIOS der Turbo aktiviert ist? Ich könnte ja mal 24 Stunden Memtest mit und ohne selbigem laufen lassen (wenn's was bringt).

Thx
Oktavus


P.S.: Eigentlich hab' ich eh schon über einen Tausch des Innenlebens dieser WS nachgedacht (Tausch von MoBo, CPU & NT - den RAM wollte ich eigentlich weiter verwenden; Asrock Z87 Extreme-6 bzw. GA-Z87-UD3H wären in der engeren Wahl). Wenn sich erhärten lässt, dass das ASUS-Board ein Leiden hat, würde ich die Sache zum Anlass nehmen, das Innenleben aufzurüsten (wenn ich allerdings nur den Turbo abdrehen müsste...?)
 
Zuletzt bearbeitet:
Mach auf allen Rechnern einen Memtest (mit aktueller Version, am besten den neuen von Passmark von PassMark MemTest86 - Memory Diagnostic Tool) für mindestens 24h und mach bei allen Festplatten einen vollständig Test, z.B. mit smartctl -t long /dev/xyzfestplatte, unter Windows kannst du auch smartctl nutzen oder eines der vielen anderen Programme.
Update:

  • Memtest ist nun ca. 36 Stunden auf dem Debian-Server und auf der betreffenden WS gelaufen - ohne Fehler.
  • Im BIOS hab' ich jetzt mal sicherheitshalber bei 'OC Tuner limit value' das 'Turbo Profile' heraus genommen.
  • Sicherheitshalber und mit mulmigem Gefühl im Bauch hab' ich ca. 3000 Fotodateien (RAWs), die ich vor 3 Tagen auf dieser WS von meiner Urlaubs-HDD auf eine andere HDD kopiert habe, abgeglichen - Gott sei Dank keine unterschiedliche Datei.
  • Das erste mal fiel mir das Kopierproblem auf dieser WS vergangenen Dienstag auf: da hab' ich vom Server eine *.rar geholt und versucht selbige zu entpacken - da kam mir zum ersten mal die Meldung 'Die Quelldatei ist beschädigt'. Diese *.rar ist aber eine Datei, die ich alle paar Wochen benötige (das letzte mal vor 4 Wochen) - bisher hatte sie immer funktioniert! Somit schließe ich einen Fehler auf dem Server eher aus. Oder?
Heute übersiedle ich den Server, abends mach' ich die Harddisk-Tests. Wenn auch das ohne Ergebnis bleibt (was ich eigentlich annehme), wird's blöd.

Irgendwie hab' ich den Spaß an dieser WS verloren ... ich denke, ich werde selbiger nächste Woche ein neues Innenleben verpassen (in der Hoffnung, dass damit das Problem gegessen ist).

Thx
 
Es gibt allgemein zwei wichtige Massnahmen bei derartigen Problemen (zur Analyse bzw. um sie zu vermeiden)

- ECC Speicher,
der gibt Bescheid, wenn Speicherprobleme auftreten bzw. sorgt dafür das normalerweise dadurch kein Datenverlust entsteht.

. Dateisysteme mit Prüfsummen (erkennen und reparieren Fehler automatisch -> self healing) und Copy On Write (immer konsistet). Das sind in erster Linie ZFS aber auch btrfs und ReFS (letztere müssen meiner Ansicht nach noch etwas reifen)
 
Hallo Gea,

mein oben genanntes Problem war der Grund, warum ich mit Hilfe Deines Napp-it zu ZFS gewandert bin. Nicht so sehr, das das Board die Menge Ram nicht vertragen hat, sondern das ich es nicht bemerkt habe. Alle BurnIn-Tests waren erfolgreich und trotzdem gab es sporadisch Probleme im Betrieb. Nur gut, das ich noch ein altes Backup hatte, welches ich VOR der Inbetriebnahme des Servers angelegt hatte. Den Fehler habe ich leider erst nach 6 Monaten bemerkt und meist hält man so lange keine Backups vor.
 
... mach bei allen Festplatten einen vollständig Test, z.B. mit smartctl -t long /dev/xyzfestplatte, unter Windows kannst du auch smartctl nutzen ...
Unter Windows hab' ich mit GSmartControl getestet - kein Problem. Beim Debian-Server hab' ich mit 'smartctl -t long /dev/sdd' in der Console den Batch-Test gestartet: er sagte mir, dass er um xx.xx Uhr fertig ist ... dumme Frage: wo schreibt er seine Testergebnisse hin? Ich hätt' mal unter /var/log/ eine Datei smartctl.log gesucht ... da ist aber nix. Thx für den entscheidenden Hinweis.

Ich hab' mir nun Teile für ein neues Innenleben meiner Problem-WS bestellt. Falls ich mal wieder den Server neu baue, werd' ich auf ECC etc. aufpassen (bei der WS hab' ich darauf verzichtet).

Thx
 
... hatte ich einfach nur Glück (in 25 Jahren), das ich das nie erlebt habe ?

wenn ein Copy bei mir fertig war, dann war es auch zuverlässig ...... war das echt nur Glück über 25 Jahre ?

wenn zu mir jemand mit CRC Errors kommt dann check ich zuerst seinen Raid (smart, controller, power), nicht den Ram .... (wenn der Ram nen Error hat sieht man das im log ... sogar unter Windoofs, wobei das zu 60% im BS endet = whatchdog reboot)
 
Zuletzt bearbeitet:
Hallo,

bei mir wars beim Kopieren übers Netzwerk in Verbindung mit einer Vollbestückung der RAMs UND gestecktem Raidcontroller. Ich vermute das das was mit dem Adressmapping des Controllers bei Vollbestückung zu tun hatte. Zugelassen war das Bord für diese 4 RAM-Module als Vollbestückung!
Bis dahin ging ich auch davon aus, das ein erfolgreicher Copyvorgang auch erfolgreich war. Ich konnte die Daten 100x ohne Fehlermeldung hin und her kopieren, das sie korrupt werden ist keiner beteiligten Komponente aus Hard- und Software aufgefallen. Die Fehlersuche war daher sehr sehr mühsam.
 
Auf der WS-1 (mit dem ASUS-Board) hab' ich so ca. alle 2 Monate beim Boot ... einen BSOD! Nach dem Reset-Knopf läuft er dann wie ein Glöcklein...
Heute war es wieder so weit - BSOD STOP: 0x0000009C. Die Teile für das neue Innenleben sind bestellt (das MoBo ist schon da) ... ich fiebere dem Umbau entgegen.

LG


P.S.: nachdem man leider nicht mit Sicherheit sagen kann, welches Teil (MoBo, i5/750, NT) den Ärger verursacht, werde ich die Teile wohl auch nicht verbuchten, um mir unnötigen Ärger zu ersparen.
 
Zuletzt bearbeitet:
... hatte ich einfach nur Glück (in 25 Jahren), das ich das nie erlebt habe ?

wenn ein Copy bei mir fertig war, dann war es auch zuverlässig ...... war das echt nur Glück über 25 Jahre ?

Hast du seit 25 Jahren jede einzelne Kopie mit Checksummen überprüft? Quelle und Ziel? Alle stationären Daten regelmäßig überprüft?
 
Hast du seit 25 Jahren jede einzelne Kopie mit Checksummen überprüft? Quelle und Ziel? Alle stationären Daten regelmäßig überprüft?

ähm, nope, aber immer war alles zu 100% ok bei Nutzung .... CRC Summen find ich toll , aber wozu solange alles funktioniert ?

ich geb dir Recht bei Datenbanken da sind CRC wichtig
 
Diese 2 Aussagen sind gegensätzlich. Ob es 100% OK war, kannst du nur durch Tests wissen.

eigentlich nicht, bei einer datenbank hast du recht, aber bei einem Program/SW/Film /mp3 nicht (und wir reden hier im HOME Bereich) wenn die zum 100% laufen braucht man keine CRC (ne Db kann keiner ohne CrC oder tests zu 100% checken)
 
Zuletzt bearbeitet:
eigentlich nicht, bei einer datenbank hast du recht, aber bei einem Program/SW/Film /mp3 nicht (und wir reden hier im HOME Bereich) wenn die zum 100% laufen braucht man keine CRC (ne Db kann keiner ohne CrC oder tests zu 100% checken)

Interessante Theorien. Ich hoffe, du betreust keine Daten irgendwelcher Leute, die sich darauf verlassen. Das wäre tragisch.
 
Interessante Theorien. Ich hoffe, du betreust keine Daten irgendwelcher Leute, die sich darauf verlassen. Das wäre tragisch.

im Homebereich nur meine .... "siehe HOME", dass es im productive Bereich anders ist schilderte ich bereits (siehste auch an meinem backup "Home Server" der 2 fach gesichert ist, 4 fach wenn du das Raid 10 und 1 mitrechnest, was für mich aber keine Sicherung ist)
 
Zuletzt bearbeitet:
Das Problem ist einfach das du nicht erkennst wenn Dateien kaputt gehen ohne CRC Checksums. Wie oft ich schon Dateien aus dem Netz gezogen habe und diese sich nicht öffnen ließen.
 
Raid und Backup hilft dir hier kein bisschen, nur regelmäßige Tests der Daten.
Ohne ein modernes Dateisystem mit Checksumming wie ZFS, btrfs oder ReFS bekommst du nämlich überhaupt nicht mit wenn etwas schief geht.
Da hilft auch kein "bei mir läuft seit xyz Jahren auch in Produktivumgebungen alles wunderbar". Die Probleme hast du dort trotzdem, realisiert es halt bloß überhaupt nicht und ziehst bei Problemen einfach die falschen Schlüsse.

Man hat ständig gekippte Bits, nur mit NTFS und Co bekommt man es einfach nicht mit, erst wenn es bereits zu spät ist. Das äußert sich in allen möglichen unerklärlichen Dingen für die dann auch fast immer die falschen Schlüsse gezogen werden wie "Software neuinstallieren und es geht wieder" oder "mal nen Update machen" oder "tauschen wir mal die Festplatte, sie muss ja auf jeden Fall defekt sein, ist im Smart zwar in Ordnung und hat keine defekten Sektoren und sonst ist auch nichts mit, aber die Daten sind ständig korrupt".

Klar, ein paar falsche Bit in einer Video- oder Audio-Datei auf einem Homeserver sind in der Regel nicht zu schlimm und verursachen keine großen finanziellen Schäden oder gefährden Menschenleben. Wenn es dann aber um ein wichtigs Word-Dokument, eine Datenbank oder z.B. Patientendaten von medizinischen Geräten geht kann es ganz schnell unschön und wie im letztem Beispiel sogar gesundheitsgefährdend sein wenn der Arzt dann Aufgrund inkorrekter Werte falsche Schlüsse für die weitere Behandelung zieht.
 
Zuletzt bearbeitet:
Selbst im Homebereich will ich keine "clicks & pops" oder Bildartefakte. Durch die extremen Kompressionen wie MPEG und JPEG sind ja einzelne Bitfehler nicht unhörbar oder unsichtbare Pixel. Das kann ja eine Lawine an hör-/sichtbarer Korruption nach sich ziehen.

Schon mal ein JPEG-Bild gesehen, was kaputt war und ab einer bestimmten Stelle bis nach unten komplett zerstört aussah? Sieht dann z.B. so aus: http://static.photo.net/attachments/bboard/00X/00Xe3e-299791684.jpg Das Bild ist dann de facto komplett zerstört.
 
Zuletzt bearbeitet:
Schon mal ein JPEG-Bild gesehen, was kaputt war und ab einer bestimmten Stelle bis nach unten komplett zerstört aussah? Sieht dann z.B. so aus: http://static.photo.net/attachments/bboard/00X/00Xe3e-299791684.jpg Das Bild ist dann de facto komplett zerstört.
Ein sehr gutes Beispiel! So etwas kennt doch jeder der mal durch große Foto-Sammelungen bei Kunden und Bekannten gescrollt hat und dann gefragt wurde woran das denn nun liegt. Für den Wald-und-Wiesen IT-Techniker ist dann immer "die Kamera schuld" oder "die SD-Karte defekt gewesen". Gut möglich, aber meistens ist da einfach irgendwo ein Bit gekippt!

Oder die Sauger wundern sich warum die Datei die sie wieder seeden wollen plötzlich nach mehrmaligen Hashcheck bei 99,98% beendet wird. Zuvor hatte man sie doch vollständig runtergeladen, da muss wohl der Torrentclient defekt sein? Wohl eher nicht, umgekippte Bits wahrscheinlichster.
 
Zuletzt bearbeitet:
Irgendwie hab' ich den Spaß an dieser WS verloren ... ich denke, ich werde selbiger nächste Woche ein neues Innenleben verpassen (in der Hoffnung, dass damit das Problem gegessen ist).
Falls es noch jemanden interessiert: der Rechner hat nun ein neues Innenleben (MoBo, CPU, Sys-SSD & NT) - er läuft wie geschmiert. Ich hab' auch mehrfach 1xx GB Daten übers Netz geschaufelt und danach verglichen - passt :d.

Thx & lG
Oktavus
 
Ich erzeug immer MD5 Checksummen, ist schon praktisch. Es gab schon Dinge wie der falsche Asus oder war es Nvidia Lantreiber, der Daten korrumpiert hat. Vor einem Jahr hat es mich dann gleich zweimal erwischt, immer Speicher defekt, war wohl ein blödes 19 Volt Netzteil für das Intel Atomboard. Es waren Bitkipper, konnte ich bei Dateien sehen, die ich noch einmal ganz hatte. Netzerkfehler schieben manchmal einen Block um ein paar Byte. Dateien, die ich wärend der Zeit des fehlerhaften Speichers erzeugt hatte, konnte ich nicht retten, alle anderen mit MD5 habe ich mittels Brute Force (ich wusste ja, welche Bits immer mal gekippt sind) wiederherstellen :) Da hat ein i7 aber schon ne Weile rechnen dürfen.
 
Wenn ich Sachen auf zur Archivierung ablege, verpacke ich sie seit einiger Zeit mit Rar und schalte Redundanz ein. Das kostet zwar ein wenig Platz, aber bis auf eine DVD-RAM die sich nicht mehr lesen liess, habe ich seitdem keine Daten verloren <aufholzklopf>.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh