Aus Linux-Magazin 08/2013

Verschlüsselte Cloudbackups mit Duplicity

© Maksim Kabakou, 123RF.com

Wer wertvolle Daten archiviert oder sichert, sollte sich eine Strategie zurechtlegen, die auch deren Sicherheit berücksichtigt. Die Backupsoftware Duplicity erlaubt das Archivieren verschlüsselter Daten auf unsicherem Terrain.

Duplicity ist das Kommandozeilentool der Wahl, wenn es darum geht, Backups in potenziell unsicheren Umgebungen abzulegen, denn es verschlüsselt Daten standardmäßig. Chiffriert dürfen Backups zur Not auch Dritten in die Hände fallen und sie lassen sich sowohl auf FTP- und SSH-Servern als auch in den Cloudspeicher von Amazon (S3) oder Ubuntu (U1) lagern. Das bringt nicht nur zusätzlich Redundanz ins Backup, sondern macht es zugleich weltweit verfügbar.

Duplicity erzeugt nach dem ersten Start ein vollständiges Backup und speichert spätere Veränderungen inkrementell in Form so genannter Volumes. Platzsparende Hardlinks verweisen dann auf jene Dateien, die bereits im Vollbackup stecken, während die inkrementellen Backups nur noch aus den veränderten Daten (Deltas) bestehen.

Im Prinzip genügt es also, ein Vollbackup zu erstellen und von da an alle Änderungen nur noch inkrementell zu sichern. Doch davor warnen die Duplicity-Entwickler: Nicht nur kann ein Fehler in einem inkrementellen Teil womöglich die komplette Sicherung ruinieren [1], sondern das Wiederherstellen von Dateien nimmt auch recht viel Zeit in Anspruch, wenn sich die Software durch alle inkrementellen Backups wühlt.

Für erklärte Mausschubser gibt es mit Déjà Dup übrigens eine grafische Oberfläche für Duplicity, die sich sehr einfach bedienen lässt und viele wesentliche Funktionen abbildet. Sie ist Teil von Gnome, steckt zum Beispiel in Distributionen wie Ubuntu und Fedora, lässt sich aber auf Systemen ohne grafische Oberfläche nicht einsetzen. Daneben gibt es noch zahlreiche Kommandozeilentools wie Duply, Backupninja und Dupinanny, die den Umgang mit Duplicity vereinfachen wollen [2].

Schlüsselfertig

Verfügt der Admin noch nicht über einen eigenen GPG-Schlüssel oder möchte er für die Sicherung einen eigenen anlegen, erzeugt er ihn über »gpg –gen-key« (Abbildung 1). Im Kommentar hinterlässt er – falls gewünscht – den Zweck des Schlüssels, die Passphrase benötigt er später beim Anlegen und Entschlüsseln eines chiffrierten Backups. Wer will, kann seine Archive zusätzlich signieren und dazu über »gpg –sign-key Schlüssel-ID« eine digitale Signatur erstellen.

Die Passphrase schützt den Schlüssel, falls er in fremde Hände gerät. Ihn sollte der Admin ohnehin gut sichern, sonst kommt er später nicht mehr an seine Daten. Mitunter hilft es, den öffentlichen und den geheimen Schlüssel auf einem externen Medium zu sichern, etwa einem USB-Stick. Die Befehle »gpg -k« beziehungsweise »gpg -K« zeigen den öffentlichen respektive geheimen Key an. Über

$ gpg --output /media/user/USB-Stick/backup key_pub.gpg --armor --export Schlüssel-ID$gpg --output /media/user/USB-Stick/backupkey_sec.gpg --armor --export-secret-keys Schlüssel-ID

lassen sich die beiden Schlüssel exportieren. Über »gpg –import« spielt der Schlüsselmeister die Keys auf einem anderen System wieder ein.

Abbildung 1: Ein Schlüssel für das Backup lässt sich mit »gpg --gen-key« recht schnell und einfach erzeugen.

Abbildung 1: Ein Schlüssel für das Backup lässt sich mit »gpg –gen-key« recht schnell und einfach erzeugen.

Vier Ziele

Das Skript aus Listing 2 erzeugt nun verschlüsselte Backups aller Homeverzeichnisse für vier verschiedene Ziele: ein lokales Verzeichnis, einen SSH-Server (über das Paramiko-Backend), Ubuntu One sowie Amazons S3 (Abbildung 2).

Hierbei gibt es einiges zu beachten. So erwartet Duplicity bei lokalen Backups absolute Pfade. Ist das Backupziel hingegen ein SSH-Server, folgt nach dem Hostnamen ein relativer Pfad zum Homeverzeichnis des angemeldeten Benutzers – in Listing 2 landet das Backup daher unter »/home/user/backup« .

Abbildung 2: Wer in Amazons Cloudstorage S3 ein Bucket anlegt, kann dort mit Duplicity verschlüsselte Backups lagern.

Abbildung 2: Wer in Amazons Cloudstorage S3 ein Bucket anlegt, kann dort mit Duplicity verschlüsselte Backups lagern.

Listing 2

backup.sh

01 #!/bin/bash
02 # Passphrase für den GPG-Key
03 export PASSPHRASE=Passphrase
04
05 # Schlüssel-ID des GPG-Key
06 export GPG_KEY=Schlüssel-ID
07
08 # Amazons Zugangsdaten
09 export AWS_ACCESS_KEY_ID=Schlüssel-ID
10 export AWS_SECRET_ACCESS_KEY=Geheimer Schlüssel
11
12 # Backup-Quelle
13 QUELLE=/home
14
15 # Backup-Ziele
16 # Lokales Backup
17 LOKAL_BACKUP=file:///home/user/backup
18 # Backup über SSH
19 SSH_BACKUP=sftp://user@remote/backup
20 # Backup in Ubuntu One
21 UBUNTU_ONE=u1+http://Zielordner
22 # Amazon S3
23 AMAZON_S3=s3+http://Bucket-Name
24
25 # Duplicity-Kommandos
26 # Lokal
27 duplicity --encrypt-key ${GPG_KEY} ${QUELLE} ${LOKAL_BACKUP}
28 # SSH
29 export FTP_PASSWORD=SSH-Passwort
30 duplicity --encrypt-key ${GPG_KEY} ${QUELLE} ${SSH_BACKUP}
31 unset FTP_PASSWORD
32 # Ubuntu One
33 duplicity --encrypt-key ${GPG_KEY} ${QUELLE} ${UBUNTU_ONE}
34 # Amazon S3
35 duplicity --encrypt-key ${GPG_KEY} --s3-use-new-style --s3-european-buckets ${QUELLE} ${AMAZON_S3}
36
37 # Passwörter zurücksetzen
38 unset AWS_ACCESS_KEY_ID
39 unset AWS_SECRET_ACCESS_KEY
40 unset PASSPHRASE

Sicher in die Wolken

Wer Ubuntu One (U1) verwenden will, braucht für den Einsatz von Duplicity eine laufende X-Session, weil ein Fenster mit der Passwortabfrage erscheint. Insofern ist diese Option in erster Linie für Nutzer von Déjà Dup interessant. Für den in Duplicity angegebenen Pfad legt Ubuntu One relativ zum Homeverzeichnis des Nutzers einen Zielordner an. Wer Amazons S3-Cloudstorage verwendet (auch hier gibt es ein kostenloses Kontingent), erzeugt dort zunächst einen User, um die Zugangsdaten zu erhalten, und dann einen so genannten Bucket. Als Pfad verlangt Duplicity nach dem Namen des Bucket. Befindet er sich in Amazons europäischer Availability Zone (AZ), erwartet Duplicity zudem die Parameter »–s3-use-new-style« und »–s3-european-buckets« .

Wer den Backupmechanismus zunächst testen will, greift zu den Schaltern »-v8« und »-v9« , die Duplicity ausführlichere Infos entlocken. Wer für seine Sicherungen einen SSH-Server oder Ubuntu One verwendet, braucht zudem das Paket »python-paramiko« , Nutzer von S3 installieren zusätzlich »python-boto« .

Die Passwörter übergibt der Admin im Listing 2 als Umgebungsvariablen, um sie nach dem Vorgang wieder zu löschen. FTP- und SSH-Passwörter erwartet Duplicity in der Variablen »FTP_PASSWORD« . Wer eine unverschlüsselte Sicherung bevorzugt, verwendet den Parameter »–no-encryption« .

Feintuning

Will der Admin nicht alle Homeverzeichnisse (Listing 2) sichern, muss er Dateien vom Backup ausnehmen. Die Parameter »–include=${QUELLE}/karl« , »–include=${QUELLE}/lenny« sowie »–exclude=’**’« sorgen dafür, dass nur die Homeverzeichnisse »karl« und »lenny« im Backup landen.

Duplicity speichert Dateien zudem in Form von Volumes ab, die standardmäßig etwa 26 MByte groß sind. Sichert der Admin Daten im GByte-Bereich, entsteht hier schnell eine stattliche Dateisammlung. Es lohnt sich eventuell, die Volumes über »–volsize 250« etwa auf 250 MByte zu vergrößern. Die Option ist aber mit Vorsicht zu genießen, weil sie den Arbeitsspeicher arg strapaziert.

Check it out

Im nächsten Schritt prüft Duplicity, ob die Signaturen der gesicherten Dateien noch mit denen der Originale übereinstimmen. Trifft das nicht zu, gibt die Software eine Fehlermeldung aus. Die lässt sich per Skript auswerten, wobei »-v« die Gesprächigkeit von »verify« erhöht:

$ duplicity verify -v4 --s3-use-new-style --s3-european-buckets --encrypt-key ${GPG_KEY} ${AMAZON_S3} ${QUELLE}

Dass der Duplicity-Nutzer hier kein GPG-Passwort eingeben muss, liegt daran, dass die Software es sich meist aus ».cache/duplicity« holt. Den Report kann sich der Admin in eine Datei schreiben lassen (»–log-file« ), die im Falle einer Unregelmäßigkeit per E-Mail oder Sync-Software bei ihm landet. So ist der Backup-Ersteller stets informiert, falls eine Sicherung misslingt, und kann gegensteuern.

Bei dieser Gelegenheit sollte er auch einen Gedanken darauf verwenden, eine Routine einzurichten, die den freien und/oder den belegten Speicherplatz auf dem externen Storage regelmäßig kontrolliert und Engpässe meldet.

Will der Admin eine bestimmte Datei wieder aus dem Backup holen, lässt er sich zunächst alle Dateien aus der letzten Sicherung anzeigen:

$ duplicity list-current-files --s3-use-new-style --s3-european-buckets--encrypt-key ${GPG_KEY} {AMAZON_S3}

Soll die Liste den Zustand zu einem bestimmten Zeitpunkt widerspiegeln, hilft der Parameter »–time« , der die Zeitangabe im Datetime-Format [3] entgegennimmt (etwa 1997-07-16T19:20:30+01:00) oder als YYYY/MM/DD.

Dieser Parameter kommt auch beim Wiederherstellen von Dateien zum Tragen:

$ duplicity --time 2013/06/08 --s3-use-new-style --s3-european-buckets--file-to-restore Pfad/zur/Quelldatei ${AMAZON_S3} Pfad/zu/Zielordner/Quelldatei

Wichtig ist, dass die »–time« -Angabe vor dem Restore-Befehl steht. Neben dem Wiederherstellungsordner darf auch der Name der Quelldatei nicht fehlen, die erste Pfadangabe verweist auf die Quelldatei in Amazons Bucket.

Backupzyklen

Weil Vollbackups viel Platz in Anspruch nehmen, sollte der Sicherungsbeauftragte im Vorfeld überlegen, wie häufig er Komplettsicherungen wünscht. Das hängt unter anderem davon ab, wie oft sich die Daten seiner User ändern und wie viel Speicherplatz bereitsteht.

Die Option »–full-if-older-than 1M« lässt Duplicity Vollbackups erzeugen, falls die letzte Komplettsicherung schon mehr als einen Monat zurückliegt. Das erspart es dem Admin, umständliche Skripte zu schreiben oder mehrere Cronjobs anzulegen, um zwischen vollen und inkrementellen Backups zu wechseln.

Für die automatische Sicherung lassen sich die Befehle aus Listing 2 sowie eine Verifizierungsroutine in ein Skript einbauen, das ein Cronjob regelmäßig ausführt – in Listing 1 beispielsweise jede Nacht um 2 Uhr. Läuft der Backuprechner nicht permanent, greift der Admin zu Anacron, das Backups notfalls nachholt, wenn der Rechner zum geplanten Zeitpunkt nicht auf dem Posten war.

Um alte Backups ohne manuelle Eingriffe zu löschen, passt der Admin Listing 2 einfach an. Der Befehl

$ duplicity --s3-use-new-style --s3-european-buckets --encrypt-key ${GPG_KEY} remove-older-than 6M --force ${AMAZON_S3}

löscht automatisch solche Backups aus dem S3-Speicher von Amazon, die älter als sechs Monate sind.

Listing 1

Cronjob für Duplicity

01 2 * * * /Pfad/zum/Backup-Skript >> /Pfad/zur/Logdatei

Infos

  1. Inkrementelle Backups vs. Vollbackups: http://lists.gnu.org/archive/html/duplicity-talk/2013-04/msg00041.html
  2. Duplicity-Frontends: http://duply.net
  3. Datetime nach W3C: http://www.w3.org/TR/NOTE-datetime
DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 3 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben