Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit
GELÖST

Linux-to-Linux-Copy mit unterschiedlichen Ergebnissen

Frage Linux Ubuntu

Mitglied: FrankN

FrankN (Level 1) - Jetzt verbinden

09.07.2014 um 21:41 Uhr, 1622 Aufrufe, 10 Kommentare

Hallo zusammen,

vielleicht kann mir jemand auf die Sprünge helfen, welchen Fehler ich bei folgendem Vorgehen mache.

Ich habe zwei kleine Linux-Server (keine VMs). Beide sind mit Ubuntu-Server 12.04 installiert. Beide haben 4 GB RAM und genügend Festplattenplatz. Alle Dateisysteme haben den Typ ext3.

Nun erstelle ich zwei tar-Archive der selben Daten (Attachments eines Zarafa-Servers aus /var/lib/zarafa). Diese werden ca. 9 GB groß ist. Bei der einen Datei verwende ich die Komprimierungsoption "z" für gzip, bei der anderen verwende ich die Option "J" für xz.

Die beiden Dateien kopiere ich mit scp (und auch mal mit rsync) vom einen System auf das andere. Das Ergebnis ist "spannend".

Die mit gzip komprimierte Datei hat am Zielsystem immer eine andere MD5-Summe und endet beim Entpacken mit einem CRC-Fehler.

Die mit xz komprimierte Datei hat am Zielsystem die selbe MD5-Summe wie am Quellsystem. Beim Entpacken kommt aber die Fehlermeldung, dass die Daten korrupt seien.

Das Ganze habe ich jetzt sowohl für gz als auch für xz 3 Mal gemacht, 3 Mal kopiert und probiert zu entpacken. Jedesmal mit dem obigen Ergebnis... wo ist mein Denkfehler? Was läuft hier schief?

Ich bin *sehr* gespannt

Danke im Voraus und viele Grüße,

Frank


Mitglied: Lochkartenstanzer
LÖSUNG 09.07.2014, aktualisiert 13.07.2014
Moin,

Mein erster Tipp wäre: defekter Datenträger oder defektes Filessystem.

  • verändern sich die Quelldaten während des Packens?
  • funktioniert das korrekte Entpacken auf dem Quellsystem in einem temporären Verzeichnis.
  • funktioniert die Übertragung über Datenträger (USB-Stick, Diskette, Bänder, etc.)
  • funktioniert das kopieren über (s)ftp oder rsync?
  • hast Du mal statt md5 mal sha-Prüfsummen ausprobiert?

lks
Bitte warten ..
Mitglied: Dobby
LÖSUNG 09.07.2014, aktualisiert 13.07.2014
Hallo Frank,

ich denke es verhält sich so;
- Die Dateien werden im RAM gecachet und weil der nicht gerade üppig ist wird auf die HDDs
ausgelagert (/temp & /swap) und dann kommt es eben zu solchen Fehlern.

- Du hast keinen ECC RAM und bei solchen großen Operationen kommt es dann eben zu CRC
Fehlern.

Verteil doch einfach die gesamte Last und somit auch die gesamten Daten auf mehrere kleine
Archive und benutze .tar.gzip eventuell fällt das dann nicht so ins Gewicht und es kommt nicht
zu Fehlern dieser Art.

Gruß
Dobby
Bitte warten ..
Mitglied: Lochkartenstanzer
LÖSUNG 10.07.2014, aktualisiert 13.07.2014
Zitat von Dobby:

ich denke es verhält sich so;
- Die Dateien werden im RAM gecachet und weil der nicht gerade üppig ist wird auf die HDDs
ausgelagert (/temp & /swap) und dann kommt es eben zu solchen Fehlern.

Swappen wäre nur dann ein Grund, wenn der Kernel eine Macke hätte, was ich für unwahrscheinlich halte, wenn die Kisten stabil laufen. Wenn, dann ist es der RAM, wenn kein ECC-RAM verwendet wird.

lks
Bitte warten ..
Mitglied: Gersen
10.07.2014, aktualisiert um 09:44 Uhr
Hallo,

ein paar Ansatzpunkte...

Außerdem -rein interessehalber- die Frage, wie lange ein "tar cJf" dauert, der eine 9 GB große Archivdatei erzeugt... Ich lese hier: "it takes significantly longer to do the compression" und "also take a hit in the memory requirements".

Läuft währenddessen der Zarafa-Server?

Gruß,
Gersen
Bitte warten ..
Mitglied: Lochkartenstanzer
10.07.2014 um 08:08 Uhr
Zitat von Gersen:

Hallo,

ein paar Ansatzpunkte...


Die alle schon oben erwähnt wurden.

lks
Bitte warten ..
Mitglied: Gersen
10.07.2014, aktualisiert um 09:10 Uhr
Hallo,

Die alle schon oben erwähnt wurden.

Touché. War ja noch nicht fertig - musste aber ins Bett...

Gruß,
Gersen
Bitte warten ..
Mitglied: Lochkartenstanzer
10.07.2014 um 09:28 Uhr
Zitat von Gersen:

Hallo,

> Die alle schon oben erwähnt wurden.

Touché. War ja noch nicht fertig - musste aber ins Bett...


Macht nichts, aber manchmal hilft es alles doppelt zu sagen

lks
Bitte warten ..
Mitglied: FrankN
10.07.2014 um 10:37 Uhr
Hallo zusammen,

vielen Dank für die vielen Anregungen, da hab ich heute Abend was zum Testen

Hier auch schon mal die ersten Antworten:

- die Quelldateien verändern sich während des Packens nicht, da ich Zarafa immer vorher gestoppt habe.
- das Entpacken auf dem Quellsystem funktioniert, die MD5-Summe ist dort richtig (sorry, hatte ich vergessen zu erwähnen)
- Das Übertragen habe ich außer mit scp auch mal mit rsync probiert, aber nicht mit (s)ftp

Das Kopieren auf eine USB-Platte habe ich heute morgen angeworfen, das probiere ich heute abend auch aus.

Ich kann heute Abend das auch mal genauer stoppen, wie lange das Packen mit xz bei dieser Datenmenge dauert und das dann posten.

Und ich werde den Speicher testen, das hätte ich nicht gedacht, muss ich gestehen, aber nach allem was ich jetzt gelesen habe, klingt das plausibel. Der Speicher ist kein ECC-RAM und der Speicher ist (genau wie die Maschinen) ca. 4 Jahre alt. Das könnte dann schon sein.

Vielen Dank erstmal, ich halte Euch auf dem Laufenden, viele Grüße,

Frank
Bitte warten ..
Mitglied: Gersen
10.07.2014 um 11:21 Uhr
Das Übertragen habe ich außer mit scp auch mal mit rsync probiert...

Was mich wundert: rsync macht grundsätzlich nach jedem Transfer eine Checksum-Prüfung ("Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred"; http://linux.die.net/man/1/rsync). Die müsste doch schon auf die Nase fallen - und der rsync-Prozess mit Fehler stoppen. Oder?
Bitte warten ..
Mitglied: FrankN
13.07.2014 um 15:51 Uhr
Hallo zusammen,

danke für Eure Inputs. Das Problem war bzw. ist der Zielserver. Das mit dem Speicher hat sich als richtig rausgestellt. Ich habe noch folgende Tests gemacht:

Kopieren auf mein Linux-Notebook funktioniert mit scp und rsync problemlos, gleiche MD5-Summe.

Wenn ich eine USB-Platte verwende, kommt die selbe MD5-Summe, solange ich das File auf dem Quellsystem habe oder auf der USB-Platte:
- MD5 ist ok auf dem Quellsystem
- MD5 ist ok auf dem Quellsystem nach dem Kopieren auf USB
- MD5 ist ok auf dem Zielsystem auf der USB-Platte
- MD5 ist *nicht* ok auf dem Zielsystem nach dem Kopieren auf das lokale Filesystem

Ein Memtest auf dem Zielsystem hat ziemlich viele Fehler angezeigt, das dürfte damit auch der Grund für die Probleme sein, denke ich. Der neue Speicher ist bestellt.

Die Frage war noch, wie lange das Erstellen einer .tar.xz-Datei dieses Umfangs bei ext3 benötigt. Die Datei mit etwas mehr als 9 GB wird bei mir in ca. 1 Stunde und 40 Minuten erstellt. Zugrunde liegt ein Filesystem mit ext3, bestehend aus 4 RED-Festplatten von WD und einem Software-RAID. Allerdings ist die CPU nicht die Stärkste, diese war auch die meiste Zeit zu 100% ausgelastet (Intel Core 2 Duo, E8400).

Danke euch und viele Grüße,

Frank
Bitte warten ..
Neuester Wissensbeitrag
Windows 10

Powershell 5 BSOD

(8)

Tipp von agowa338 zum Thema Windows 10 ...

Ähnliche Inhalte
Windows Server
WDS mit PXE Linux (3)

Frage von HansWurstAugust zum Thema Windows Server ...

Linux Tools
Docker - Minimize your containers with alpine linux

Link von Sheogorath zum Thema Linux Tools ...

Monitoring
System Monitoring für Windows, Linux (5)

Frage von manuelw zum Thema Monitoring ...

Viren und Trojaner
gelöst WHM cPanel Anti Virensoftware für Linux ? (2)

Frage von xpstress zum Thema Viren und Trojaner ...

Heiß diskutierte Inhalte
Microsoft
Ordner mit LW-Buchstaben versehen und benennen (21)

Frage von Xaero1982 zum Thema Microsoft ...

Netzwerkmanagement
gelöst Anregungen, kleiner Betrieb, IT-Umgebung (18)

Frage von Unwichtig zum Thema Netzwerkmanagement ...

Windows Update
Treiberinstallation durch Windows Update läßt sich nicht verhindern (17)

Frage von liquidbase zum Thema Windows Update ...

Windows Tools
gelöst Aussendienst Datensynchronisierung (12)

Frage von lighningcrow zum Thema Windows Tools ...