duplicity

[Merthos]

Basierend auf der Empfehlung in der letzten c't wollte ich mir mal duplicity anschauen. Aber anscheinend ist das ein Bug drin, so dass es nicht funktioniert. Es werden leere Manifest-Dateien auf der Remote-Seite erstellt und nachfolgende Backups brechen ab. Wenn es funktionieren würde, dann ganz nett, inkrementelle Backups, Verschlüsselung via GPG und so alle Ziele die man sich wünschen kann.

Hier meine Erkenntnisse so weit, vielleicht hilft es ja jemandem weiter.

Installation:

• IPKG installieren
• duplicity installieren, alle Abhängigkeiten sollten mit installiert werden:

  ipkg install py26-duplicity

• Anscheinend wird vom Script gpg erwartet, installiert wird aber gpg2, also das fixen:
  

  cd /opt/bin
  ln -s gpg2 gpg

• Schlüssel erstellen:
  

  gpg2 --gen-key

  (Das hat bei mir auf der DS nicht funktioniert. Beim Erzeugen der Randoms ist er stehengeblieben. Also hab ich die auf einem anderen Rechner erstellt und dann importiert, unter windows z.B. mit Gpg4win. In dem Fall nicht vergessen, den Schlüssel als vertrauenswürdig zu kennzeichnen.)
  
• Schlüssel anzeigen:
  

  gpg2 --list-keys

  Wichtig ist die 8-stellige Buchstaben-Ziffer-Kombination in der ersten Zeile, das ist die ID von dem Schlüssel.

Backup:

export PASSPHRASE=GPGPASSWORT
duplicity --encrypt-key "XXXXXXXX" --sign-key "XXXXXXXX"  /volume1/was_auch_immer/ Ziel

GPGPASSWORT - das Passwort für GPG (für den Schlüssel); kann man weglassen, dann muss man es immer eingeben
XXXXXXXX - die Schlüssel-ID von oben
Weitergehende Optionen (z.B. Ex/Include) auf der man-Page.​

GMail:

duplicity --encrypt-key "XXXXXXXX" --sign-key "XXXXXXXX" --volsize 10 --imap-mailbox "LABEL" /volume1/was_auch_immer/ imaps://ACCOUNT:PASSWORT@imap.gmail.com/ADRESSE

LABEL - das Label muss schon existieren
ACCOUNT - der Teil vor dem @ der Adresse
PASSWORT - das Passwort (kann man inkl. des : weglassen, dann muss man es immer eingeben)
ADRESSE - Absende-Addresse für die Mails, sollte für jeden Backup-Job unterschiedlich sein​

Webdav (GMX-Mediacenter):

duplicity --encrypt-key "XXXXXXXX" --sign-key "XXXXXXXX" /volume1/was_auch_immer/ webdavs://KUNDENUMMER:PASSWORT@mediacenter.gmx.net/

KUNDENUMMER - die Kundennummer bei GMX
PASSWORT - das Passwort (kann man inkl. des : weglassen, dann muss man es immer eingeben)
Am Ende kann ein Pfad angehängt werden, wenn das Backup in einen Ordner soll.​

 

[jahlives]

Coole Idee, danke für's HowTo
Bei mir hat gpg2 --gen-key gefunzt. Allerdings habe ich gleichzeitig einen Backupjob angeworfen damit genügend Aktivität (für den Zufallsgenerator) entsteht. Der 2048bit Schlüssel wurde so in gut 3 Minuten generiert, auf einer DS 109+.
Jetzt probier ich mal weiter. Das sieht auf jeden Fall sehr vielversprechend aus.

 

[jahlives]

Habe jetzt mal einen Backupjob via duplicity angeworfen. Die Performance ist jedoch - mal diplomatisch ausgedrückt - unterirdisch Könnte sein, dass es auf Kisten mit HW-Support für Verschlüsselung schneller geht.
Fairerweise muss ich aber sagen, dass ich das Backup auch auf meine Kamerabilder losgelassen habe. Alle mindestens 10 MByte gross
Die Möglichkeit des IMAP Backups schaue ich mir dann als nächstes an.
Das Backup ist zu Ende. 11 Minuten pro GByte bei mir

 

[Merthos]

Habe jetzt mal einen Backupjob via duplicity angeworfen.

Und funktioniert dann auch ein zweiter inkrementeller?


Dieser Thread empfiehlt das Ersetzen des verwendeten GnuPGInterface. Hab zwar von Python nicht wirklich Ahnung , aber das hab ich noch so hinbekommen. Runterladen von http://sourceforge.net/projects/py-gnupg/files/ (Version 0.3.2), auspacken und die GnuPGInterface.py nach /volume1/@optware/lib/python2.6/site-packages/duplicity kopieren. Die dort liegende gleichnamige .pyc löschen, damit auch eine neue kompiliert wird (ist das nötig bei Python?).

Und siehe da, es scheint zu funktionieren. Mal mehr testen...

 

[Merthos]

So, Backup fertig. 1,15 GB, durch das packen zu 827 MB in 33 Minuten zu GMX (Webdav). Macht (wenn ich richtig gerechnet habe) 3,3 Mbit/s was prinzipell zu meiner Verbindung passt.

Inkrementelle Backups gehen auch, also prinzipiell bin ich erst mal zufrieden. Mal schauen wie es sich auf längere Sicht macht.

 

[trevorreznik]

So, Backup fertig. 1,15 GB, durch das packen zu 827 MB in 33 Minuten zu GMX (Webdav). Macht (wenn ich richtig gerechnet habe) 3,3 Mbit/s was prinzipell zu meiner Verbindung passt.

Inkrementelle Backups gehen auch, also prinzipiell bin ich erst mal zufrieden. Mal schauen wie es sich auf längere Sicht macht.

Wollte mir Duplicity mal anschauen, aber auf der Seite findet man nicht viel zur Funktionsweise. Kann mir jemand erklären, wie Duplicity funktioniert? Irgendwie müssen ja bei einem inkrementellen Backup die aktuellen Daten mit den verschlüsselten Remote-Daten abgeglichen werden. Hält Duplicity dafür auf der Quellseite Vergleichsinfos vor?

 

[Merthos]

Ja, die Doku ist etwas mau. Prinzipiell verwendet es den rsync-Algorithmus und erzeugt dann tar-Dateien. Für Deltas wird rdiff verwendet. Das Ganze wird dann (optional) mit GPG verschlüsselt / signiert. Die Metadaten werden in Manifest-Dateien abgelegt:

Hostname XZY
Localdir /volume1/was_auch_immer
Volume 1:
    StartingPath   datei x
    EndingPath     datei y
    Hash SHA1 hash_wert_1
Volume 2:
    StartingPath   datei z
    EndingPath     ...
    Hash SHA1 hash_wert_2

Dazu noch irgendwelche verschlüsselten tars, schätze mal, dass dort die konkreten Dateien und Hashs drin liegen.

Diese werden lokal gecached (~/.cache/duplicity/....) und beim Start nur die Signaturen verglichen. Wenn die lokalen fehlen, werden sie erst runtergeladen.

 

[jahlives]

Und siehe da, es scheint zu funktionieren. Mal mehr testen...

Das heisst damit gehen nur auch die Folgebackups korrekt? Wäre echt super, denn duplicity sagt mir wirklich zu v.a. weil es so viele verschiedene Protokolle/Dienste unterstützt

 

[Merthos]

Ja, zumindest sind schon zwei weitere durchgelaufen.

 

[Merthos]

So, es hat jetzt zwei Wochen problemlos seinen Dienst verrichtet. Kann ich also prinzipiell empfehlen.

Hier noch ein paar weitere Befehle.

Status anzeigen

duplicity collection-status --encrypt-key "XXXXXXXX" --sign-key "XXXXXXXX" ZIEL

Gibt dann sowas in der Form:

Chain start time: Thu Jan 20 19:05:05 2011
Chain end time: Sun Feb  6 04:00:17 2011
Number of contained backup sets: 22
Total number of contained volumes: 55
 Type of backup set:                            Time:      Num volumes:
                Full         Thu Jan 20 19:05:05 2011                34
         Incremental         Thu Jan 20 19:45:23 2011                 1
         Incremental         Thu Jan 20 19:49:01 2011                 1
--snip --
         Incremental         Sat Feb  5 04:00:18 2011                 1
         Incremental         Sun Feb  6 04:00:17 2011                 1

Dateien (im Backup) anzeigen

duplicity list-current-files --encrypt-key "XXXXXXXX" --sign-key "XXXXXXXX" ZIEL

Dateien wiederherstellen
Dazu muss nur die Angabe von Quelle und Ziel umgedreht werden. Z.B. für das GMX von oben:

duplicity --encrypt-key "XXXXXXXX" --sign-key "XXXXXXXX" webdavs://KUNDENUMMER:PASSWORT@mediacenter.gmx.net/ /volume1/was_auch_immer/

Wenn man nur einzelne Dateien haben möchte, kann man diese mit "--file-to-restore PFAD" angeben.

Keine Verschlüsselung
Wenn man keine Verschlüsselung benötigt, dann kann man die "--encrypt-key" und "--sign-key" weglassen und statt dessen "--no-encryption" verwenden.

Aufräumen
Ansonsten muss man bedenken, dass durch die inkrementellen Backups der Platzbedarf auf dem Ziel immer weiter wächst. Daher sollte man von Zeit zu Zeit aufräumen. Dazu ein neues vollständiges Backup erzwingen:

duplicity full ...

Und anschließend das vorhergehende Set löschen:

duplicity remove-all-but-n-full 1 --force ...

 

[Matthieu]

Ab ins Wiki damit!

MfG Matthieu

 

[Merthos]

Zu Befehl! - http://www.synology-wiki.de/index.php/Duplicity

(Wenn das Wiki nur nicht so elendig langsam wäre...)

 

[glowaq]

Ich bekomme beim 2. aufruf immer diesen fehler:

Last full backup date: Sat Feb 26 02:22:11 2011
Collection Status
-----------------
Connecting with backend: WebDAVBackend
Archive dir: /root/.cache/duplicity/c012d5b507da450e4ac0f2f7b40a1a37

Found 0 secondary backup chains.

Found primary backup chain with matching signature chain:
-------------------------
Chain start time: Sat Feb 26 02:22:11 2011
Chain end time: Sat Feb 26 02:22:11 2011
Number of contained backup sets: 1
Total number of contained volumes: 1
Type of backup set: Time: Num volumes:
Full Sat Feb 26 02:22:11 2011 1
-------------------------
No orphaned or incomplete backup sets found.
Retrieving /ds409/duplicity-full.20110226T012211Z.manifest.gpg from WebDAV server
Deleting /volume1/@tmp/duplicity-d7X9Td-tempdir/mktemp-22MuIv-2
Manifests not equal because different volume numbers
Fatal Error: Remote manifest does not match local one. Either the remote backup set or the local archive directory has been corrupted.

Irgendwas scheint mit dem "manifest" nicht zu stimmen. Das full läuft ohne fehler durch. Was kann das sein?

 

[Merthos]

Hast Du die GnuPGInterface.py ersetzt?

 

[glowaq]

Jau, das wars. Danke.

 

[Merthos]

Neuer Bug bei der Verwendung von Webdav, für den Fall, dass es bei jemand anderem auftritt. Ab einer bestimmten Menge an Dateien schlägt das Backup fehl, bei mir so ca. 130 beim GMX Media Center. Also regelmäßig ein volles Backup erzwingen und die inkrementellen löschen.

 

[Merthos]

Für das kostenlose HiDrive ist die URL:

webdavs://USERASSWORT@USER.webdav.hidrive.strato.com/users/USER​

USER und PASSWORT entsprechend mit den eigenen Daten ersetzen.