Netz - Rettung - Recht (Artikel mit Tag duplicity)

Backups in die Cloud (duply und S3)

nospam@example.com (Thomas Hochstein) — Tue, 29 Mar 2016 13:00:00 +0000

Eigentlich wollte ich schon vor gut drei Jahren, im Januar 2013, über dieses Thema schreiben, als ich die ersten Backup-Jobs dieser Art eingerichtet habe, aber irgendwie ist aus dem angefangenen Entwurf nie ein fertiger Blogeintrag geworden. - Nun denn, auf ein neues.

Nicht nur der heimische Rechner will regelmäßig gesichert werden; auch bei dedizierten Servern oder vServern ist ein regelmäßiges Backup vonnöten, um im Falle eines Falles nicht ohne (Code und) Daten dazustehen. Früher war es üblich, dass zu einem Server auch ein - meist per FTP zugänglicher - Backupplatz gehörte, der genügend Raum für ein Backup (auch über mehrere Generationen) bot. Mittlerweile müssen solche Angebote aber nicht selten kostenpflichtig hinzugebucht werden oder stehen gar nicht mehr zur Verfügung. Zwar ist es natürlich möglich, die Datensicherung auf einen anderen (eigenen oder fremden) Server durchzuführen, wobei sich die Maschine im heimischen Keller in der Regel wegen der geringen Upload-Bandbreiten nicht anbietet - schließlich will man nicht nur sichern, sondern notfalls auch wiederherstellen können. Eine Alternative ist aber Cloud-Speicher, bspw. Amazons S3 (Simple Storage Service). Die Kosten sind bei inkrementiellen Backups überschaubar: ein Gigabyte Speicherplatz kostet pro Monat ungefähr 3 Cent, dazu kommen noch geringen Kosten für Zugriffsoperationen in der Größenordnung von einem halben Cent pro 1.000 Zugriffe und für den ausgehenden Traffic - also vor allem für einen Restore - 9 Cent pro GB, jeweils zzgl. MWSt. Wöchentliche inkrementielle Backups mit monatlichen Vollbackups für vier Server kommen auf gut 10$.

Backup mit duply in einen AWS S3-“Bucket”

Für verschlüsselte und komprimierte Backups bieten sich duplicity und duply an; die grundsätzliche Einrichtung von duply habe ich bereits 2011 beschrieben. Zusätzlich benötigen wir für das Cloud-Backup noch dreierlei: einen S3-“Bucket”, in dem die Backups landen sollen, Zugangsdaten für diesen “Bucket”, und eine Anpassung der duply-Konfiguration.

Für die Nutzung der Amazon Web Services (AWS) ist eine Anmeldung dort erforderlich. Außerdem empfiehlt es sich sehr, nicht mit den Daten des Haupt-Accounts auf unseren S3-“Bucket” zuzugreifen, sondern mit einem extra dafür erzeugten Nutzeraccount, der dann auch nur auf diesen “Bucket” zugreifen kann. Dazu dient das Identity and Access Management (IAM).

AWS-Konfiguration

Fangen wir an mit der Anlage des S3-Speicherplatzes. Dazu genügt es, in der S3 Console mit Klick auf Create einen neuen “Bucket” anzulegen. Der vergebene Name muss AWS-weit eindeutig sein, es empfiehlt sich daher etwas in der Form accountname-backup-servername o.ä. Dabei muss dieser Name eine gültige Subdomain darstellen (vgl. die AWS-Dokumentation) und er sollte - um spätere Schwierigkeiten beim Zugriff zu vermeiden - keine Punkte enthalten. (Mit duplicity und den zugehörigen Libraries unter Debian Wheezy hatte ich keine Zugriffsprobleme auf Buckets, die Punkte im Namen haben, mit den Versionen in Debian Jessie jedoch sehr wohl. Better safe than sorry … ) Außerdem kann die geographische Region ausgewählt werden, in der der “Bucket” angelegt werden soll. Neben Irland ist hier nun auch Frankfurt als Standort auswählbar; für den Zugriff dort wird aber nur die Protokollversion 4 unterstützt, was wiederum zu Schwierigkeiten führen kann. Ich empfehle daher eu-west-1 (Irland) als Region.

Jetzt brauchen wir noch einen Benutzer, der auf den Bucket zugreifen kann. Ein solcher lässt sich in der IAM Console anlegen. Die dabei erzeugte Access-Key-ID und der zugehörige Secret Key müssen unbedingt heruntergeladen und sicher aufbewahrt werden.

Danach bekommt der neu erzeugte Benutzer noch eine Policy mit den nötigen Zugriffsrechten verpasst. Dazu wählen wir ihn in der Benutzerliste aus, wählen den Tab Permissions an und klicken unter Inline Policies auf Create User Policy. Diese Policy sollte dann wie folgt aussehen:

{
    "Statement": [
        {
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Action": "s3:*",
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::accountname-backup-servername",
                "arn:aws:s3:::accountname-backup-servername/*"
            ]
        }
    ]
}

Statt accountname-backup-servername ist der Name des vorher neu angelegten S3-Buckets zu verwenden. Dieser Benutzer darf sich also eine Liste aller “Buckets” anzeigen lassen und auf den genannten “Bucket” und alle Dateien darin zugreifen.

duply-Konfiguration

Update: Die Beschreibung der Konfiguration gilt für Debian 8.0 Jessie und Debian 9.0 Stretch.

In der duply-Konfiguration (Datei conf) treffen wir jetzt noch folgende Einstellungen:

TARGET='s3://s3-eu-west-1.amazonaws.com/accountname-backup-servername'
TARGET_USER='AccessKeyID'
TARGET_PASS='SecretAccessKey'

Update: Ab Debian Stretch muss es statt TARGET_USER und TARGET_PASS wie folgt heißen:

export AWS_ACCESS_KEY_ID='AccessKeyID'
export AWS_SECRET_ACCESS_KEY='SecretAccessKey'

Für s3-eu-west-1 (Region Irland), accountname-backup-servername, AccessKeyID und SecretAccessKey sind jeweils die passenden Werte zu verwenden; AccessKeyID und SecretAccessKey wurden bei der Einrichtung des IAM-Benutzers erzeugt.

Außerdem müssen duplicity noch einige zusätzliche Parameter übergeben werden:

DUPL_PARAMS="$DUPL_PARAMS --s3-use-new-style --s3-european-buckets --s3-use-multiprocessing "

Update: Ab Debian Stretch benötigt auch gpg zusätzliche Parameter:

GPG_OPTS='--pinentry-mode loopback'

Jetzt kann der erste Backuplauf mit duply NAME backup gestartet werden. Nach dem Abschluss des Backup-Laufs finden sich im “Bucket” in der S3 Console die gesicherten Dateien.

Fertig!

Backup mit duply und duplicity

nospam@example.com (Thomas Hochstein) — Thu, 13 Jan 2011 17:18:15 +0000

Niemand will Backup. Alle wollen Restore.

(Kristian Köhntopp zitiert einen Vertriebler - Fachbegriffe der Informatik #125)

Regelmäßige Backups sind wichtig und auch durch redundante Systeme wie RAIDs nicht zu ersetzen; ganz abgesehen davon, daß bei einem RAID 1 gerne die - meistens ja zum selben Zeitpunkt wie die erste in Betrieb genommene - zweite Platte beim notwendigen Rebuild zusammenbricht, schützt ein RAID auch nur gegen Datenverlust durch Ausfall einer Festplatte, aber weder gegen versehentliches oder böswilliges Löschen, Überschreiben oder Verändern von Daten, noch kann es gegen einen fatalen Schaden des gesamten Systems (Brand, Diebstahl, …) schützen. Backups sollten daher

regelmäßig durchgeführt werden,
versioniert sein (so daß man einen längeren Zeitraum zurückgehen kann) und
off-site transferiert werden können.

Zumindest dann, wenn man keine Kontrolle über die Infrastruktur hat, auf der die Backups gespeichert und über die sie transportiert werden, sollten Backups auch verschlüsselt sein. Diese letzte Anforderung ist typisch für sog. "Rootserver", also Mietserver, zu denen bei üblichen Angeboten auch ein sog. "Backupspace", also Speicherplatz auf einem Storage gehört, auf den zumeist nur per (unverschlüsseltem) FTP zugegriffen werden kann. Selbst wenn man dem Provider und seinen Mitarbeitern vertraut, kann man nicht ausschließen, daß auch Dritte - andere Kunden, … - zumindest den unverschlüsselten Datenverkehr zwischen dem zu sichernden Server und dem Storage "belauschen" können. Wenn man seine Backups also unverschlüsselt überspielt, kann die gesamte Konfiguration samt aller Paßworte usw. usf. mitgelesen werden.

Schließlich gibt es eine letzte Anforderung für sinnvolle Backups: sie sollten, einmal eingerichtet, möglichst wenig Aufwand bedeuten, optimalerweise automatisiert sein, denn nur dann werden sie auch wirklich regelmäßig durchgeführt.

Alle zuvor genannten Anforderungen erfüllt das Tool duplicity, für das die c’t bereits anno 2006 ein Frontend namens ftplicity entwickelt hat, das nunmehr unter dem Namen duply weiterentwickelt wird. duply unterscheidet sich u.a. dadurch von ftplicity, daß es nicht nur die Konfiguration der Übertragung via FTP unterstützt, sondern auch auf anderem Weg (was dann auch die Namensänderung erklärt).

duplicity sichert Dateien und Verzeichnisse in (nicht gepackte!) tar-Archive, verschlüsselt diese vermittels GnuPG und überträgt die Sicherungen in kleinen Häppchen auf verschiedenen Wegen (lokal, FTP, SCP, rsync, …) auf das Sicherungsmedium; dabei werden inkrementielle Backups über den rsync-Algorithmus erstellt, d.h. nicht alle veränderten Dateien gesichert, sondern ggf. nur ein diff, was wiederum Platz und Bandbreite spart. duplicity dürfte in den meisten Distributionen paketiert sein, duply ist es in Debian ab Squeeze, kann aber in jedem Fall trivial installiert werden.

Eine mögliche Umsetzung für einen Mietserver sieht - unter Debian Lenny - so aus:

duplicity und ncftp installieren: aptitude -r install duplicity ncftp

duply (in /usr/local/bin) installieren:

cd /tmp
wget -O duply_1.5.4.2.tgz http://sourceforge.net/projects/ftplicity/files/duply%20%28simple%20duplicity%29/1.5.x/duply_1.5.4.2.tgz/download
tar -xzf duply_1.5.4.2.tgz 
cp duply_1.5.4.2/duply /usr/local/bin/
rm duply_1.5.4.2.tgz 
rm -r duply_1.5.4.2

Alternativ (Debian Squeeze): aptitude -r install duply

Da der gesamte Server gesichert werden soll, läuft der Backupprozess am besten mit Root-Rechten. Wir brauchen jetzt also einen GPG-Key für root und richten dann das Backup ein:

cd /root
gpg --gen-key

Wenn nicht genug Entropie vorhanden ist, um den Key zu erzeugen, empfiehlt es sich, bspw. durch mehrere größere Downloads für Netzwerkverkehr und Belastung der Festplatten zu sorgen, um den Pool aufzufüllen. Key-ID und Paßwort des erzeugten Schlüssels benötigt man im nächsten Schritt zur Einrichtung des Backups; der Name des Backups kann frei gewählt werden:

duply *NAME* create
vim .duply/*NAME*/conf

In der Konfigurationsdatei sind nun zumindest einzutragen
- die ID des erzeugten GPG-Schlüssels (GPG_KEY),
- das Paßwort desselben (GPG_PW),
- das Backup-Ziel (FTP-Server und ggf. Verzeichnis, Benutzername, Kennwort: TARGET, TARGET_USER, TARGET_PASS) und
- den Pfad, der gesichert werden soll (im Zweifel "/": SOURCE).
Für die Einzelheiten und fortgeschrittene Konfigurationsmöglichkeiten sei auf die Kommentare innerhalb der Datei und die Dokumentation von duplicity und duply verwiesen.

Als nächstes erstellt man eine Liste der Dateien, die nicht gesichert werden sollen, die mindestens spezielle Verzeichnisse wie /dev und /proc enthalten sollte: vim .duply/NAME/exclude

/dev/\*
/proc/\*
/sys/\*
/tmp/\*
/var/tmp/\*
/var/run/\*

Danach kann man noch Scripts hinterlegen, die vor oder nach dem Backuplauf ausgeführt werden; bspw. kann es sich vor dem Backup empfehlen, Datenbanken zu dumpen. Diese Scripts heißen dementspechend pre und post, können zum Beispiel Shellscripts sein und müssen
- ausführbar sein (chmod 700 .duply/NAME/pre) und
- einen entsprechenden shebang (#!/bin/bash) enthalten.

Wenn das alles paßt, kann man nunmehr sein erstes Backup starten: duply *NAME* backup

Danach sollte man das komplette Verzeichnis .duply (das dann auch eine Kopie des GPG-Schlüssels enthält) sichern (nicht auf den Backupspace, sondern an einen sicheren Ort!).

Schließlich kann man noch in die Crontab von root einen entsprechenden Eintrag einfügen:

00 5 \* \* \* /usr/local/bin/duply *NAME* backup
00 6 1 \* \* /usr/local/bin/duply *NAME* full && /usr/local/bin/duply *NAME* purge --force

Fertig. Viel Erfolg!

In gleicher Weise ist es möglich, weitere Backups zu definieren, die bspw. nur /home oder /etc (oder /var/mail …) sichern, das dann aber häufiger.