Backups in die Cloud (duply und S3)
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!
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt