WE ARE ROOT

ftplicity: inkrementelle Backups sicher ablegen

ACHTUNG: Die in diesem Artikel besprochenen Versionen sowohl von ftplicity als auch duplicity sind bereits veraltet. Die grundsätzlichen Erklärungen sind zwar weiterhin valid, aber die Syntax oder Konfigurationsparameter könnten sich geändert haben. Bitte verwendet den Such-Tag “duplicity” bzw. den Such-Tag “ftplicity” und die Kommentare, um aktuelle Informationen zu finden.

Nachdem ich durch einen Beitrag von Matthias wieder mal erinnert wurde, dass nicht Jeder Backups macht bzw. sie aktuell hält, dachte ich, dass ich mal kurz einen Teil meiner Backuplösung vorstelle:

Vorteile

In einem (schon älterem) Artikel der c’t (13/2006) wurde ein Tool vorgestellt mit dem man eine einfache und sichere Backup-Strategie für z.B. Root-Server fahren kann. Das Tool heißt ftplicity und ist im Prinzip nur ein Wrapper für das umfangreichere duplicity. Wie der Name schon sagt, kann möchte ftplicity nur via FTP kommunizieren, denn dies ist laut c’t (und auch meiner Erfahrung nach) der häufigste und simpelste Weg einen Backupspace zu erreichen.

Nun beseitigt ftplicity bzw. das dahinterliegende duplicity gleich mehrere Probleme, die bei dem “plain old Dir-to-FTP-sync” enstehen:

• Übertragungsqualität: FTP tendiert bei längeren durchgehenden Übertragungen (= eine große Datei) zu Fehleranfälligkeit und der ganze Upload muss noch einmal begonnen werden oder (was viel schlimmer ist) die Backupdatei ist zerstört/ fehlerhaft und lässt sich im Ernstfall nicht mehr richtig wiederherstellen.
  

  Lösung: kleine Dateien übertragen durch Erstellung von Volumes

• Vertraulichkeit: Wer einen zweiten Server mit guter Anbindung hat braucht sich um diesen Punkt nicht zu sorgen, aber alle anderen, die entweder etwas Platz bei einem Bekannten in Anspruch nehmen oder von Ihrem Provider einen gewissen Platz an FTP-Space zur Verfügung gestellt bekommen (z.B. Strato, Hetzner) müssen sich schon fragen, ob denn der jeweilige Serveradmin nicht nachts mal aus Interesse sich durch das Mailbackup wühlt.
  

  Lösung: Verschlüsselung der Daten mittels GPG

• Authentizität: Das oben genannte Problem wirft ebenfalls die Frage auf, wie weit man den so gesicherten Daten noch vertrauen kann, wenn “Unbekannte” auf die Daten Zugriff hatten. Nichts wäre wohl schlimmer, als dass man sich mit dem Restore auch gleich eine passwd-Datei mit neuen SSH-Usern runterzieht (nette Idee, btw).
  

  Lösung: Die Signatur der Daten mittels GPG, welche auch beim Restore geprüft werden.

• Datenvolumen: Je mehr Daten man gesichert hat, desto leichter findet ein Restore statt. Allerdings nimmt damit auch das Übertragungsvolumen zu, was erstens mehr Backupzeit kostet und zweitens in den meisten Hosterverträgen auch begrenzt ist.
  

  Lösung: Inkrementelle Backups (nur geänderte Daten) unter Nutzung der erprobten rsync-Bibliothek

Diese Probleme werden also von der hier vorgestellten Lösung bereits vermieden. Aber – richtig eingerichtet – kann es noch mehr:

Weitere Vorteile

• Einzelrestore: Wer kennt das nicht: Schnell mal die Config vom Mailserver bearbeitet und statt die alte Zeile auszukommentieren löscht man sie… und siehe da, rien ne va plus! Der Mailserver startet nicht mehr und man kann sich partout nicht mehr an die besagt Zeile erinnern. Wohl dem, der ein Backup von den Configdateien hat und noch wohler dem, der nicht das ganze Backup wiederherstellen muss, um die Einzeldatei zu erhalten.
  

  Lösung: ftplicity besitzt einen Befehl, mit dem man Einzeldateien oder -ordner an einen beliebigen Ort wiederherstellen kann

• Versionierung: Manchmal wäre es schön, wenn man eine Datei nicht nur in dem Zustand des nächtlichen Backups erhielte, sondern sich auch mal die Config ansehen könnte, wie sie vor zwei Wochen war.
  

  Lösung: Ein Argument des oben erwähnten Befehls ermöglicht es, ein Datum oder einen Zeitraum für die wiederherzustellende Datei anzugeben.

So, als ich diese Punkte damals alle las, war für mich klar: Das will ich haben! Wenn es DIR jetzt auch so geht, dann lies jetzt weiter, denn ein kleines Howto folgt. Es basiert auf Debian (zuerst Sarge, nun Etch), aber sollte wohl auch auf anderen (Linux-) Systemen laufen, da duplicity in Python geschrieben ist und ftplicity nur ein Shellscript ist.

Installation

So, wie fangen wir an? Wir ziehen uns das duplicity-Paket mittels apt oder aptitude.

apt-get install duplicity

Wer z.B. noch kein gnupg (= GPG) installiert hat, wird sich freuen, dass die Abhängigkeiten vernünftig definiert sind und es somit gleich mit geladen wird.

Alternativ kann man sich auch das tgz von der Projektseite herunterziehen. Ich bevorzuge aber aus Sicherheitsgründen die Debian-Pakete.

Dann laden wir uns das File mit ftplicity von dem heise-Server.

wget ftp://ftp.heise.de/pub/ct/listings/0613-216.tar.gz

Auspacken…

tar -xzf 0613-216.tar.gz

…und in das Verzeichnis wechseln, …

cd ftplicity-1.1.1/

… und einfach mal die Datei ausführen:

./ftplicity

Diese Ausgabe sollte erscheinen:

Offenbar benutzen Sie ftplicity zum ersten Mal. Eine vorlaeufige
Konfigurationsdatei wurde unter /root/.ftplicity/conf erstellt.
Sie muessen dort die Daten des verwendeten GPG-Schluessels sowie
die Zugangsdaten fuer den FTP-Server eintragen, bevor Sie mit dem
Backup fortfahren koennen.

WICHTIG:
Sichern Sie das komplette Konfigurationsverzeichnis nach dem
ersten erfolgreichen Backup unbedingt auf einen vertrauenswuerdi-
gen externen Rechner und schuetzen Sie es vor unbefugtem Zugriff.

Konfiguration

So, das ist zwar schön, aber nicht wirklich sinnvoll. Als guter Admin möchte man seine Configdateien ja alle unter /etc wissen. Also machen wir ein wenig Kosmetik:

Wir verändern den Ort, wo ftplicity nach der config sucht:

edi ftplicity

Zur leichteren Trennung der verschiedenen Dateien, hänge ich auch noch Endungen an.

CONFDIR="/etc/ftplicity"
CONF="$CONFDIR/main.conf"
PRE="$CONFDIR/pre.sh"
POST="$CONFDIR/post.sh"
EXCLUDE="$CONFDIR/exclude.conf"
KEYFILE="$CONFDIR/gpg.key"

F10 – Speichern und beenden.

Dann das besagte Config-Dir erstellen:

mkdir /etc/ftplicity

Damit ftplicity im Pfad zu finden ist kopieren wir es nach /usr/sbin – für mich ist dies der richtige Ort, denn nur der root soll dieses Script mit der Konfiguration ausführen dürfen.

cp ftplicity /usr/sbin/

und damit wir u.U. das Skript schnell bearbeiten können, sollte dies nochmal nötig sein, erstellen wir noch einen Link ins Confdir (optional):

ln -s /usr/sbin/ftplicity /etc/ftplicity/ftplicity

Danach entweder einfach nochmal

ftplicity

aufrufen oder die Musterconfig aus dem ersten Aufruf an die richtige Stelle kopieren.

cp ~/.ftplicity/conf /etc/ftplicity/main.conf

Bevor wir nun die Config bearbeiten, benötigen wir zunächst einen GPG-Key, der zum Signieren und Verschlüsseln dient.

gpg --gen-key

Die Voreinstellungen sind alle sinnvoll und können mit <Enter> bestätigt werden, aber den Namen, Mailadresse und Kommentar sollte man so sinnvoll ausfüllen, dass man den Key in der GPG-Keyliste dann auch wiederfindet.

Das Passwort sollte natürlich Sicherheitsansprüchen genügen (Klein- und Großbuchstaben + Sonderzeichen + Zahlen).

Es kann sein ist sehr wahrscheinlich, dass bei Key-Erstellung folgendes kommt:

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 282 more bytes)

Wie auch immer das genau funktioniert, nutzt GPG die Systemvorgänge als Zufallsinput. Also mach z.B. folgendes in einer zweiten Shell:

while /bin/true; do cat /var/log/syslog > ~/temp.txt; sleep 1; done;

Dies erzeugt eine Kopie des Syslogs (= große Datei) in deinem Homeverzeichnis und das zwar endlos, solange du es nicht via Ctrl+C abbrichst bzw. die Sitzung schließt. Damit erzeugst Du genügend Festplattenaktivität. Du kannst natürlich auch andere Dinge tun oder einfach warten – je nach Systemaktivität könnte dies aber eine Weile dauern.

Wie auch immer Du es erreichst, es erscheint dann:

gpg: key 1B6B8FAF marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
pub 1024D/1B6B8FAF 2007-08-17
Key fingerprint = 2B2E DA54 4E2C 08B4 677D 4EC9 1AC5 3DE5 1B6B 8FAF
uid Stevie (Backup-GPG-Key) <admin@domain.tld>
sub 2048g/C4BCAD3E 2007-08-17

wobei uns nur diese Zeile interessiert,

pub 1024D/1B6B8FAF 2007-08-17

denn 1B6B8FAF wäre in diesem Fall die Key-ID, die wir in die ftplicity-Config eintragen müssen. Das merken wir uns also schon mal. Dann können wir jetzt die Config-Datei von ftplicity bearbeiten.

edi /etc/ftplicity/main.conf

Meine Datei sieht so aus:

# Daten fuer GPG-Schluessel
GPG_KEY=<em>KEYID</em>
GPG_PW='_MEINPW_'
 
# Zugangsdaten fuer FTP-Server (URL-Format)
# subdir ist natürlich optional, aber strengstens empfohlen!
ZIEL='ftp://username@ftphost.tld/subdir/'
ZIEL_PW='_FTPPASSWORT_'
 
# Basisverzeichnis fuers Backup
QUELLE='/'
 
# aeltester Wiederherstellungszeitpunkt
# Linux-übliche Abkürzungen, ich habe vorerst 6 Monate eingestellt,
# da ich noch genügend freien Platz habe
# - je nach Speicherplatz und Backuphäufigkeit zu entscheiden
HOECHSTALTER=6M 
 
# Ausfuehrlichkeit der Bildschirmausgaben (9 fuer Fehlersuche)
# WARNUNG: "9" erstellt Logs/Ausgaben in der Größenordnung von 200MB (je nach Dateianzahl)
VERBOSITY=3 
 
# Verzeichnis fuer temporaere Dateien. Beim Restore muss dort
# mindestens Patz fuer die groesste Datei im Backup sein
TEMP_DIR=/tmp

So, eigentlich wären wir nun fertig. ABER eben nur eigentlich. Bei der Erstellung des Backups würde duplicity auf einige Probleme stoßen, somit sind einige Pfade vom Backup auszuschließen in der exclude.conf:

edi /etc/ftplicity/exclude.conf

+ /backups/mysql/latest
/backups/**
/var/run/**
/var/tmp/**
/tmp/**
/dev/**
/sys/**
/proc/**
/floppy/**
/cdrom/**
/var/lib/mysql/**

Der Selektor “**” steht für alle Dateien und Unterverzeichnisse in diesem Ordner. Der Selektor “+” vor dem Ordner gibt an, dass es explizit gesichert werden soll, auch wenn es eigentlich in einem Exclude-Dir liegt (siehe 1. & 2. Zeile). Wie man sieht, schließe ich die MYSQL-Dateien aus. Während der Server läuft, kann man die Dateien auch nicht sichern. Entweder man beendet den Mysql-Server während des Backups oder man dumpt die DBs. Das Script zum Dumpen der MYSQL-Tabellen habe ich hier kurz vorgestellt.

Wer noch andere vorbereitende Schritte zur Sicherung vornehmen möchte, wie z.B. das o.g. MySQL-Dump-Script oder das Beenden des MySQL-Servers, kann diese in der pre.sh einstellen. Nachbereitende Schritte, z.B. Start von Mysql, kann ist der post.sh erfolgen. (Beide Dateien müssen erst erstellt werden, sofern sie benötigt werden.)

Absichern

Zur Sicherheit sichern wir nun noch das gesamte Confdir, damit uns niemand das Key-PW auslesen kann:

chown -R root:root /etc/ftplicity
chmod -R o-rwx /etc/ftplicity

So, fertig. Nun ist alles konfiguriert und bereit zum Test. Auf manchen FTP-Servern hat duplicity Probleme zu starten, wenn der Ordner leer ist (wie es beim ersten Mal der Fall sein wird). Wo das der Fall ist, genügt es, eine leere Datei in dem Verzeichnis zu platzieren.

Test

Nun wird es ernst. Die Verwendungshinweise erhält man nun, in dem man einfach

ftplicity

aufruft und es wäre sinnlos alles zu wiederholen. Nur ein paar Hinweise:

Beim “fetch” einzelner Dateien darf man keinen führenden Slash und muss eine Zieldatei angeben:

ftplicity fetch etc/passwd  /root/restoretest/passwd now

Lädt aus dem Backup die letzte Version der Datei passwd, die aus /etc gesichert wurde und speichert sie nach /root/restoretest/passwd.

Bevor man sich nun darauf verlässt, dass alles funktioniert, sollte man mittels

ftplicity full

ein Vollbackup machen und es mittels

ftplicity restore /root/restoretest/

zurückspielen und untersuchen. Wenn alles geklappt hat, kann man sich beruhigt auf die Schulter klopfen.

Cron

So, nun ist alles bereit für den Regelbetrieb. Damit man von nun an keine Kopfschmerzen mehr mit dem Backup hat, richten wir noch cronjobs ein, die wöchentlich ein komplettes Backup und an den anderen Tagen eine inkrementelle Sicherung erstellen. Richtig eingerichtet sollte der Cron-Daemon die Ausgabe des Cronjobs via E-Mail an den root senden. Als root führen wir also aus:

crontab -e

und tragen dort ein:

# FTP-Backup ... jede Nacht um 2:05 Uhr (außer Montags)
5 2 * * 2-7 /usr/sbin/ftplicity cleanup --force ; /usr/sbin/ftplicity backup
 
# FTP-Backup ... um 1:30 Uhr jeden Montag
30 1 * * 1 /usr/sbin/ftplicity cleanup --force; /usr/sbin/ftplicity full ; /usr/sbin/ftplicity purge --force

Zusätzlich wird so dafür gesorgt, dass vor jedem Backup das Verzeichnis von fehlerhaften Backups bereinigt wird und Montags nach dem vollständigen Backup veraltete Dateien ebenfalls gelöscht werden. (Anmerkung: Es werden nur veraltete Dateien gelöscht, wenn es eine neuere Version gibt, die innerhalb des konfigurierten Höchstalters liegt. Es gibt also immer mindestens eine Version der Datei … irgendwie sinnvoll )

Backup des Backups

Nach dem ersten Lauf existiert ein gpg.key im Config-Dir. Der muss unbedingt die Rechte 400 oder 600 haben und sollte an einem sicheren Platz fernab vom Server gesichert werden. Nur mit diesem Key (und dem PW) ist eine Wiederherstellung des Backups möglich, sollte der Keyring nach einem Totalabsturz nicht mehr verfügbar sein. Sicherlich kann es auch nicht schaden, die Configs zu sichern. So hat man gleich die perfekte Voraussetzung, um das ganze erneut aufzusetzen.

Das war’s, we are done. Wir sind nun sowas von auf der sicheren Seite… wow!

Fragen? Hinweise? Optimierungen? –> Bitte hinterlasse einen Kommentar!

Geschrieben am 17. August 2007 um 17:54 Uhr stevie vergab folgende Tags: apps+tools • backup • debian • duplicity • ftplicity • howto • linux • python