37.8Backups auf S3-Speicher

S3 steht für Simple Storage Service und ist ein Puzzlestück der Amazon Web Services (AWS). S3 ist ein vergleichsweise kostengünstiger Cloud-Dienst von Amazon zur Speicherung von Dateien. S3 ist vor allem als externer Backup-Speicher sehr beliebt, besonders wenn es darum geht, zusätzlich zu einem lokalen Backup auch ein geografisch vom Server getrenntes Backup durchzuführen. Das gibt Ihnen die Gewissheit, auf Ihre Daten selbst dann noch zugreifen zu können, wenn Ihre Hosting-Firma pleitegegangen ist oder deren Rechenzentrum durch eine Naturkatastrophe zerstört wurde.

Das Preismodell von Amazon S3 ist außergewöhnlich unübersichtlich. Sie bezahlen nicht nur für die gespeicherten Datenmengen an sich, sondern auch für Transfers, wobei zwischen GET- und PUT-Anforderungen unterschieden wird, also Down- und Uploads. Lassen Sie sich von der verwirrenden Darstellung des Preismodells aber nicht irritieren: Im Vergleich zu Diensten wie Dropbox ist S3 bei einer vernünftigen Nutzung ausgesprochen billig. Sie sollten aber bei der Programmierung von Backup-Scripts darauf achten, unnötige Transfers zu minimieren.

S3-Speicher einrichten

Sie können Amazon S3 mit Datenmengen bis zu 5 GByte für ein Jahr kostenlos testen. Sie müssen sich allerdings auch für den Test mit Name, Adresse, einer funktionierenden Telefonnummer und einer Kreditkarte anmelden. Die Kontoeinrichtung dauert nur wenige Minuten. Anschließend müssen Sie in der S3-Weboberfläche zumindest einen sogenannten »Bucket« (wörtlich »Eimer«) anlegen, gewissermaßen ein Grundverzeichnis innerhalb von S3. Der Bucket-Name muss innerhalb der gesamten S3-Cloud eindeutig sein. Es empfiehlt sich deswegen, den Firmen- oder Domainnamen miteinzubeziehen, z. B. meinefirma.erster.test oder info.kofler.backup.

Nach diesen ein wenig langwierigen Vorbereitungen können Sie nun endlich im Terminal loslegen. Dort brauchen Sie das Python-Kommando aws. Zu diesem kommen Sie, indem Sie zuerst das Python-Paketverwaltungswerkzeug pip installieren und damit dann das Paket aswcli:

root# apt-get/dnf/yum/zypper install python-pip root# pip install awscli

Wenn Sie bei der Script-Programmierung Python 3 vorziehen, sieht die Vorgehensweise so aus:

root# apt-get/dnf/yum/zypper install python3-pip root# pip3 install awscli

Die Verbindung zu S3 erfolgt verschlüsselt. Bevor Sie im Terminal das Kommando aws für die weitere Nutzung konfigurieren können, müssen Sie sich auf der AWS-Seite Identity & Access Management (IAM) einen Benutzer und eine Gruppe einrichten. Die Gruppe verbinden Sie mit der Policy AmazonS3FullAccess und mit dem neuen Benutzer.

https://console.aws.amazon.com/iam

Im Terminal führen Sie nun aws configure aus und geben dabei die Access Key ID und den Secret Access Key an, den Sie beim Einrichten des Benutzers erhalten haben. aws speichert diese Daten und die weiteren Optionen in .aws/credentials und .aws/config.

root# aws configure AWS Access Key ID [None]: AKxxxxxxx AWS Secret Access Key [None]: ZRxxxxxxxxxxxxxxxx Default region name [None]: eu-central-1 Default output format [None]:

Nicht ganz einfach ist die korrekte Angabe der Region. Beim Anlegen neuer Buckets können Sie wählen, wo diese physikalisch gespeichert werden sollen. Für S3-Kunden in Deutschland ist Frankfurt der beste Ort. In welcher Form erwartet S3 nun aber die Angabe der Region? Am besten ist es, die Region vorerst leer zu lassen. Anschließend ermitteln Sie mit aws s3api get-bucket-location die Region und wiederholen dann aws configure:

root# aws s3api get-bucket-location --bucket meinefirma.erster.test "LocationConstraint": "eu-central-1"

Das aws-Kommando

aws s3 ls liefert eine Liste aller eigenen Buckets:

root# aws s3 ls 2015-10-05 21:53:08 meinefirma.erster.test 2015-10-06 07:58:11 linux.buch.test

Mit aws s3 cp laden Sie eine lokale Datei hoch. Die folgenden Zeilen erstellen zuerst ein komprimiertes Backup des /etc-Verzeichnisses und übertragen dieses dann in einen Bucket, der in der Form s3://bucketname angegeben wird. Natürlich ist auch ein Transfer in die umgekehrte Richtung möglich (drittes Kommando).

root# tar czf etc.tgz /etc root# aws s3 cp etc.tgz s3://linux.buch.test upload: ./etc.tgz to s3://linux.buch.test/etc.tgz root# aws s3 cp s3://linux.buch.test/etc.tgz etc-copy.tgz download: s3://linux.buch.test/etc.tgz to ./etc-copy.tgz

Ein wenig verwirrend ist der Umgang mit Verzeichnissen. Innerhalb eines S3-Buckets gibt es offiziell nämlich gar keine Verzeichnisse. Vielmehr befinden sich alle Dateien ohne eine hierarchische Ordnung direkt im Bucket. Daher fehlen Kommandos wie mkdir, rmdir oder cd.

Bucket-Dateien dürfen aber Namen in der Form von v1/v2/name haben. ls verarbeitet derartige Dateinamen so, als würde es sich dabei um Verzeichnisse handeln. Auch die S3-Weboberfläche zerlegt derartige Dateinamen in virtuelle Verzeichnisse.

root# touch tst.txt root# aws s3 cp tst.txt s3://linux.buch.test/v1/v2/tst.txt root# aws s3 ls s3://linux.buch.test --recursive 2015-10-06 08:12:47 2595826 etc.tgz 2015-10-06 08:30:23 0 v1/v2/tst.txt root# aws s3 ls s3://linux.buch.test/v1/v2/ 2015-10-06 08:30:23 0 tst.txt

Anstatt einzelne Dateien hochzuladen, können Sie mit aws s3 sync ganze Verzeichnisbäume synchronisieren:

root# aws s3 sync ein_lokales_verzeichnis/ s3://linux.buch.test

Wenn Sie das Kommando zum ersten Mal ausführen, werden alle Dateien des lokalen Verzeichnisses hochgeladen. Wiederholen Sie das Kommando später, werden nur noch die Änderungen durchgeführt, wobei lokal gelöschte Dateien im S3-Bucket standardmäßig erhalten bleiben (es sei denn, Sie verwenden die Option --delete).

Neben ls, cp und sync gibt es nur fünf weitere Kommandos: mv verschiebt eine Datei, rm löscht eine Datei, mb erzeugt einen Bucket und rb löscht ihn wieder. Mit website können Sie schließlich aus einem Bucket eine statische Webseite machen. Das ist dann zweckmäßig, wenn Sie Dateien öffentlich zum Download anbieten möchten. Eine detaillierte Beschreibung der aws-s3-Kommandos mit all ihren Optionen finden Sie hier:

http://docs.aws.amazon.com/cli/latest/reference/s3/index.html

Verschlüsselung und Beispiel

Nach den Enthüllungen von Edward Snowden müssen Sie leider davon ausgehen, dass die NSA und andere Geheimdienste uneingeschränkten Zugriff auf Ihre Daten in der Cloud haben – ob das den Cloud-Betreibern nun passt oder nicht. Dass Ihre Daten beim Upload verschlüsselt übertragen werden, ist zwar an sich erfreulich, aber letzten Endes irrelevant. Wenn Sie Wert darauf legen, dass Ihre Dateien nur von Ihnen gelesen werden können, müssen Sie sie vor dem Upload verschlüsseln.

Ich gehe dabei oft so vor, dass ich auf einem Server zuerst ein lokales Backup-Verzeichnis erstelle. Dort führe ich die Backups durch, die mir zweckmäßig erscheinen, wobei ich bei dieser Gelegenheit bereits alle Backup-Dateien verschlüssele. In einem zweiten Schritt synchronisiere ich dann das lokale Backup-Verzeichnis in einen S3-Bucket, auf einen FTP-Server des Hosting-Providers etc.

Im folgenden Beispiel gehe ich davon aus, dass es das lokale Backup-Verzeichnis /local-backup gibt. Es ist zweckmäßig, dieses in einem eigenen Logical Volume mit einem eigenen Dateisystem einzurichten. Alle Backup-Scripts und Schlüssel befinden sich in /etc/myscripts. Zum Ver- und Entschlüsseln wird eine Pass Phrase aus einer Datei verwendet.

root# makepasswd --chars 100 > /etc/myscripts/key root# chmod 400 /etc/myscripts/key root# cat /etc/myscripts/key ISMLX...AaxdI

Zum Verschlüsseln verwende ich das Kommando gpg, das in die Scripts mycrypt und myuncrypt verpackt ist. Die Verschlüsselung erfolgt der Einfachheit halber symmetrisch.

#!/bin/sh -e # Datei /etc/myscript/mycrypt # Verwendung: mycrypt < plain > crypted gpg -c --batch --no-use-agent --cipher-algo AES256 --compress-algo none \ --passphrase-file /etc/myscripts/key --passphrase-repeat 0 #!/bin/sh -e # Datei /etc/myscript/myuncrypt # Verwendung: myuncrypt < crypted > plain gpg -d --batch --no-tty -q --no-use-agent --cipher-algo AES256 \ --compress-algo none --passphrase-file /etc/myscripts/key \ --passphrase-repeat 0

Die hohe Kunst des Verschlüsselns

Das hier präsentierte Verschlüsselungskonzept ist einfach, aber sicherheitstechnisch alles andere als perfekt. Solange die Datei /etc/myscripts/key nicht in falsche Hände gerät, ist die so errichtete Hürde ein ausreichender Schutz vor Gelegenheits-Hackern – mehr nicht! Wenn Sie höhere Sicherheitsansprüche stellen, müssen Sie entsprechende Fachliteratur konsultieren.

Das täglich um 2:00 Uhr ausgeführte Cron-Script backup-cms erstellt ein Backup der MySQL-Datenbank cms, komprimiert und verschlüsselt dieses und speichert es in /local-backup/mysql unter dem Namen cms-nn.sql.gz.crypt. Dabei ist nn der Tag im Monat (1 bis 31). Damit gibt es immer individuelle tägliche Backups, die einen Monat zurückreichen.

#!/bin/sh -e # Datei /etc/myscripts/backup-cms db=cms opts='--skip-opt --single-transaction --create-options --quick \ --extended-insert --disable-keys --add-drop-table' day=$(date "+%d") fname="/local-backup/$db-$day.sql.gz.crypt" mysqldump --defaults-file=/root/.my.cnf $mysqlopt $db \ | gzip -c \ | /etc/myscripts/mycrypt > $fname

Ein weiteres Cron-Script, das täglich um 3:00 Uhr ausgeführt wird, muss nun nur noch die Backup-Dateien in /local-backup in einen S3-Bucket synchronisieren:

#!/bin/sh -e aws s3 sync /local-backup/ s3://meine.firma.backups

Jetzt müssen Sie die Prozedur natürlich testen: Funktionieren die automatischen Backups? Sind Sie auch auf einem anderen Server in der Lage, die Backup-Datei aus dem S3-Speicher herunterzuladen, zu entschlüsseln, zu entkomprimieren und dann in einen MySQL-Server hochzuladen? Wichtig ist natürlich, dass Sie über sichere Kopien der S3-Zugangsdaten sowie der Schlüsseldatei /etc/myscripts/key verfügen!