Backup stockt

[Offerus]

Hallo zusammen,

ich mache gerade ein Backup von einer externen Festplatte zu einer zweiten mit Luckybackup unter Debian Wheezy. Irgendwie werden dabei immer nur ein paar Dateien kopiert und dann bleibt er 10 bis 40 Sekunden hängen, dann werden wieder ein paar Dateien kopiert usw... Ist das normal?
Die anzeige "vergangene Zeit" bleibt dabei auch immer hängen und springt dann wieder auf den richtigen Wert.
Am log von Luckybackup kann man das leider nicht so gut erkennen, aber an der CPU auslastung (ich hab währenddessen keine weiteren CPU hungrigen Programme laufen lassen):


Beste Grüße,
Offerus

[Cae]

Vorneweg, damit wir auch vom Selben sprechen: Du meinst die Spikes in der CPU-History mit den 15- bzw. 25-sekuendigen Idle-Phasen dazwischen? Ausserdem kenne ich Luckybackup nicht (vielleicht aber das Backend, falls das nur 'ne GUI ist), aber ich wuerde das erstmal nicht fuer normal halten (sofern's nicht I/O ist, s.u.).

Vielleicht wird in der Zeit einfach auf die Platte gewartet (das "Speicher" darunter ist RAM, hat allenfalls indirekt etwas damit zu tun). Sehen wuerde man das gut, wenn du parallel mal

Code: Alles auswählen

$ vmstat 1

laufen laesst und mal einen der Grafik aehnlichen Bereich postest. Das wuerde ich an der vorletzten Spalte ("cpu id" wie CPU-Idle-Anteil) ablesen, 1 bedeutet sekuendliche Ausgabe, womit auch die Zeitbasis klar ist. Fuer meine Theorie waere dann unter io wie Input/Output der Wert fuer jeweils bi (Blocks in) und bo (Blocks out) spannend.

Gruss Cae

[Offerus]

Tut mir Leid, dass ich mich erst jetzt wieder melde - ich musste genug Daten sammeln um ein Backup zu machen, das länger als ein paar Minuten dauert.

Ja ich meinte die Spikes in der CPU-History. Luckybackup ist eine GUI für rsync. Man kann dort halt die Optionen anklicken anstatt sie per Hand einzugeben.

Hier ist mal die Ausgabe von vmstat 1:

37987

Hier waren die Intervalle zwischen Dateiübertragung und Stop kürzer, aber durchaus vorhanden.

[rendegast]

'dmesg'? Vielleicht Übertragungsfehler/Kollisionen?
Kabel / Stromversorgung der Platten?
smartctl-Abfrage der Platten? (bei externen manchmal etwas tricky -> Option '-d|--device=')

Code: Alles auswählen

fdisk -l

-> eventuell fehlendes Alignment?

Code: Alles auswählen

cat /dev/sdX > /dev/null
cat /dev/sdY > /dev/null

dabei jeweils mit 'vmstat 1 beobachten.

Aus dem vmstat, bi geht hoch bis auf ~ 70/80 MB/s.
Es handelt sich nicht um USB2, zumindest bei einer der Platten? (dmesg)
-> versuche den wheezy-backports-kernel (neueres USB3, ext.SATA).

BIOS-Upgrade?

[Offerus]

Was für Optionen sollte ich bei 'dmesg' angeben?
Defekt in der Kabal/Stromversorgung denke ich eigentlich nicht, da die Platten z.B. bei Filmwiedergabe gut funktionieren.
Die vorgeschlagenen Befehle kann ich jetzt noch nicht ausführen, da das Backup jetzt erstmal den halben Tag läuft und ich denke, dass sich dann vmstat überlagern würde, oder?

Ich merke ich habe zu wenig Informationen über das System gegeben:
Ja, sehr gut bemerkt: Die Quellfestplatte ist USB3, die Zielfestplatte USB2. Beide Festplatten sind mit truecrypt verschlüsselt und benutzen das NTFS Filesystem. Diese werden dann gemountet und dann wird wie gewöhnlich das Backup ausgeführt.

Ich benutze bereits den Kernel aus den Backports, da sonst bei mir das wlan nicht funktioniert:

Code: Alles auswählen

 x@xx:~$ uname -r
3.13-0.bpo.1-amd64

Bios-Upgrade hab ich vor ein paar Wochen gemacht.

[rendegast]

Was für Optionen sollte ich bei 'dmesg' angeben?

Ein 'dmesg' eines "guten" Systems zeigt schonmal alles an,
da nicht von Meldungen überlaufend.
Plattenbezogen

Code: Alles auswählen

dmesg | egrep "sd[a-z]|scsi" -C1

USB-bezogen sowas

Code: Alles auswählen

dmesg | grep -i "usb" -C1

3.13-0.bpo.1-amd64

Es gäbe da mittlerweile
3.14-0.bpo.2-amd64 (3.14.15)

Code: Alles auswählen

aptitude install linux-image-amd64 -t wheezy-backports

gegebenenfalls noch
aptitude install linux-headers-amd64 -t wheezy-backports
resp.
aptitude install linux-image-amd64 linux-headers-amd64 -t wheezy-backports