Duplicity: warum dauert das so lange!

[DelphiKing]

Aloha,

ich mache meine Backups via duplicity (und duply) auf einen entfernten FTP-Server. Der gesamte Platteninhalt (ohne /proc, /dev, /sys) wird dabei in 5MB-große symmetrisch (nur ne Passphrase) verschlüsselte Dateien (Volumes) verpackt und diese dann hochgeladen.

Habe heute Mittag das erste Full-Backup angestoßen und die ersten 1860 Volumes gingen super schnell (10 Volumes pro Minute), aber seitdem hängt es ziemlich: V1861 kam 3h später, V1862 weitere 2h später.

Jetzt frage ich mich natürlich, was da los ist oder welche Dateien hier solche Probleme bereiten.

lsof gibt nichts wirklich hilfreiches aus, außer Python-Libs und der pipe nur 3 Dateien die gelöscht sind:

1:
2:
3:
duplicity 25385 root    4u   REG    9,1          0     16694 /tmp/tmpfqdHSF (deleted)
duplicity 25385 root    5u   REG    9,1          0     16696 /tmp/tmpei65F4 (deleted)
duplicity 25385 root    6r   REG    9,1 3877109760    457102 /root/old_stuff/riesige_datei.tar (deleted)

Oder könnte das wirklich an riesige_datei.tar liegen, obwohl die gelöscht ist?
(Wieso will er die überhaupt sichern, obwohl sie doch gar nicht mehr da ist?)

Ansonsten: Kann ich irgendwie rausfinden, welche Dateien in einem speziellen Volume sind?

Meine Notlösung wäre sonst nur: abbrechen, Debugausgabe aktivieren, alles nochmal laufen lassen und dann gucken, bei welchen Files er hängt (sofern das dort ausgegeben wird)... aber wäre ärgerlich, das jetzt abzubrechen, nachdem es schon stundenlang lief.


Grüßle, flo

[Talion]

Dateien in einem speziellen Volume angucken müsstest du mit gnupg und tar können, duplicity verwendet ja kein spezielles Format.

Woher kommt die riesige Datei, hat duplicity die selbst angelegt oder war die vorher da? Wenn letzteres: War die zum Zeitpunkt als du duplicity gestartet hast bereits gelöscht?

[DelphiKing]

Hm stimmt, das geht ja wirklich ôO Danke!

Das betreffende Archiv ist voll mit 150.000 temporären Session-Dateien aus einem Webserver-Verzeichnis... ich denke, ich muss eher an anderer Stelle mal was korrigieren, nicht bei duplicity

Ich schätze, das bei so vielen (winzigen) Dateien der Overhead für die Dateiinfo-Speicherung (letzte Änderung/Hash/whatever) so groß wird, dass das Backup exorbitant lange dauert...