Duplicity: Inkrementelles Backup

Zum Thema Backup gibt es doch eigentlich schon diesen Post hier, warum also das Thema nochmal behandeln?
Weil Rsync wie RAID 1 ist: Kein Backup.

Ich kann nicht in der Zeit zurückgehen und beispielsweise die Version eines Config-Files von vor zwei Wochen wiederherstellen.
RAID 1, abgesehen davon, dass der Server hier nur eine Festplatte hat, würde Fehler sofort replizieren.
Rsync müsste ich dann hoffen, einen eventuellen Fehler zu entdecken, bevor das nächste Backup losläuft, was ja das Alte überschreibt.

Auf meiner Suche nach geeigneten Tools für inkrementelles Backup haben mich zwei näher angesprochen: Rsnapshot und Duplicity.

rsnapshot benutzt rsync mit --backup-dir, dabei ist immer der Stand vom letzten Backup verfügbar, ohne irgendwelche Tools benutzen zu müssen. Frühere Backups sind auf das aktuellste mit Hardlinks verknüpft.
Bedeutet, wenn sich eine Datei ändert, muss diese immer komplett übertragen werden.
Primitiver geht es nicht mehr, wenn man auch in 20 Jahren noch an seine Backups kommen möchte, ist das die richtige Wahl. Auch Apples "Time Machine" soll unter der Haube rsync benutzen.
Hat man eigene, vertrauenswürdige Maschinen zur Verfügung, würde ich wegen der Einfachheit klar rsnapshot bevorzugen.

Ich habe mich jedoch für Duplicity entschieden.
Duplicity generiert bei Bedarf verschlüsselte Tarballs, die ein Full-Backup enthalten oder später immer nur Diffs der Dateiänderungen. Hier muss alle paar Wochen-/Monate ein neues Full Backup gemacht werden, sonst dauert die Wiederherstellung zu lange oder die Gefahr der Korruption wird zu groß - geht nämlich ein inkrementelles Archiv kaputt/verloren, hat man Pech gehabt.

Die Stärken von Duplicity sind erstens die eingebaute Verschlüsselung, zweitens die Vielseitigkeit der Backupmedien: Ob Amazon S3, SFTP, FTP oder Dropbox, praktisch überall kann Duplicity Backups speichern.
Ob ich meine Daten dann in den USA oder Osteuropa sichere, dem Hoster muss ich nicht vertrauen, dank Verschlüsselung.

Das Setup
Ohne Verschlüsselung: --no-encryption

Mit Verschlüsselung:
Zuerst muss mit GnuPG ein separater Schlüssel, ohne Passphrase, erstellt werden.
haveged würde ich vorher noch installieren, damit das Sammeln von Zufallsbits nicht zu lange auf sich warten lässt.
gpg --gen-key - neuen Key erstellen, Gültigkeit unbegrenzt.
gpg --list-keys - hier die Key ID (hex) notieren


Beispiel
gpg --list-keys
-----------------------------
pub 2048R/916993F4 2016-06-14
uid duplicity_test
sub 2048R/135034B1 2016-06-14


duplicity --encrypt-key 916993F4

Bei Verschlüsselung muss dieses Argument bei jedem Aufruf von Duplicity angegeben werden.

An dieser Stelle nicht vergessen, ein Backup des Keys anzufertigen, ohne den die Backups nutzlos sind.
gpg --export-secret-key 916993F4 > duplicity.key

Ab damit ins Bankschließfach, Ausdrucken o.ä.- ohne Key sind die verschlüsselten Backups wertlos.
Import des Schlüssels, bei Wiederherstellung von anderer Maschine aus, falls die lokale GPG-Schlüsseldatenbank nicht mehr existiert:
gpg --import duplicity.key


Backup
duplicity --encrypt-key 916993F4 --full-if-older-than 30D /tmp/dupl *noch mehr argumente, exclude inculd etc* file:///tmp/dupltest
duplicity --encrypt-key 916993F4 remove-older-than 3M --force file:///tmp/dupltest

Zwei Zeilen und ich bin fertig. 1. Macht ein neues Full-Backup alle X Tage. 2. Löscht ältere Backups, sofern keine Abhängigkeiten mehr bestehen, wenn diese älter als X Tage sind.

Sicherer ist es wohl, statt zeitbasiert nur auf die Anzahl Backups bezogen zu löschen:
remove-all-but-n-full count

Falls das Backup aus irgendeinem Grund fehlschlägt, wird hier nicht nach Alter des letzten Backups gelöscht, sondern nach Anzahl Backups. Beides mit && verkettet für zusätzliche Sicherheit.

Für Lokalbackups kann file:// verwendet werden. Für Backup auf FTP lautet das Stichwort FTP_PASSWORD.

Statusanzeige - Anzahl Backups:
duplicity collection-status file:///tmp/dupltest 


Folgende Optionen sind noch nützlich:
--numeric-owner bei Restore
--volsize 200 Größe eines tar-Archivs, default 25M
--dry-run simulierter Durchlauf, macht nichts
--exclude={a,b,c}
--include={e,f,g}


Die gute Nachricht, es unterstützt bei den Include/Exclude-Patterns die selbe Syntax wie rsync
Für alles Weitere gibt es die Man-Page, Restore könnte einfacher nicht sein, mit dem -t Switch entweder per relativer oder absoluter Zeitangabe:
duplicity sftp://user@host.tld/backup_dir /dir_to_restore # Restore vom letzten Backup
duplicity -t 3D --file-to-restore Relative/path sftp://uid@host.tld/backup_dir destination_path_to_restore_files_to # Restore vom Stand von vor drei Tagen


Abschließend ein Beispiel für ein volles, verschlüsseltes Systembackup auf Offsite FTP:
KEY_ID=my_key_id
export FTP_PASSWORD=secret
duplicity --encrypt-key $KEY_ID --full-if-older-than 1M --volsize=200 \
--exclude={"/dev/**","/proc/**","/sys/**","/tmp/**","/run/**","/mnt/**","/media/**","/lost+found","/var/log/**","/home/*/.cache/**"} \
/ \
ftp://user@host.tld/

duplicity remove-all-but-n-full 3 --force ftp://user@host.tld/
duplicity remove-all-inc-of-but-n-full 1 --force ftp://user@host.tld/
export FTP_PASSWORD= # delete password

Bei täglichem Aufruf via Cron würden hier gründsätzlich die letzten 3 Full-Backups samt inkrementellen Ständen aufgehoben werden, im nächsten Schritt die inkrementellen Stände bei allen, bis auf den aktuellen Stand (seit letztem Full-Backup) entfernt werden.

Linux

694 Words

2016-06-19