Xen auf Debian. Teil 5

Mit Backups ist es wie mit dem Sport: Jeder weiß, wie wichtig Backups sind, aber kaum jemand macht’s. Und wenn doch, dann meist nicht regelmäßig. Entsprechend haben viele auch ein schlechtes Gewissen, wenn man auf das Thema kommt. Allerdings gibt es einen Unterschied: Backups lassen sich automatisieren, Sport leider nicht. Und das ist zumindest für Backups eine gute Nachricht. Außerdem sind heute Programme wie rdiff-Backup so einfach zu bedienen, dass es kaum einen Grund gibt, kein Backup zu haben.

In diesem vorerst letzten Teil werden wir sämtliche virtuellen Xen-Domains erst täglich (oder nächtlich) auf dem Wirt sichern und diese Daten dann als differenzielles Backup auf einen anderen Server ziehen. Schematisch also:

Domain1, Domain2, Domain3 –> Wirt –> Backup-Server.

Wir haben also immer ein komplettes aktuelles Backup auf dem Wirt und beliebig lange in die Vergangenheit reichende differenzielle Backups auf dem Backupserver. So können jederzeit Verzeichnisse oder Dateien wiederherstellen, so wie sie zu einem beliebigen Zeitpunkt waren.

Für den ersten Schritt, also das Backup der Domains auf den Wirt, bedienen wir uns eines fertigen Skripts von John Quinn.

http://www.johnandcailin.com/blog/john/backing-your-xen-domains

Das Skript speichern wir unter /usr/bin/xenBackup, setzen owner und group auf root und chmod auf 700.

Jetzt erstellen wir das Verzeichnis /backups und /mnt/xen auf dem Wirt. Dann bearbeiten wir das Skript von John in einem Punkt: Wir ändern den Wert von xenDiskArea und wählen unsere LVM Volume Group, in meinem Fall wäre das vg0.

Nun müssen wir noch rsync und rdiff-backup installieren
# apt-get install rsync rdiff-backup

Wir probieren einmal, ob auch alles funktioniert, wie gedacht:

# xenBackup -a -t /backups -e rsync -s

Mit -a werden alle Domains gesichern, mit -d können einzelne Domains gewählt werden. Mit dem Schalter -s werden die Domains erst runtergefahren, bevor ein Backup durchgeführt wird. So sparen wir uns die zusätzlichen Datenbank-Backups, die eigentlich nötig wären, wenn wir die Domains im laufenden Betrieb sichern würden. Natürlich muss man abwägen, ob es das Wert ist. Wenn der Server stets ausgelastet ist und man auf die eine Minute Downtime pro Tag verzichten möchte, muss man eben noch die Datenbank-Backups separat durchführen.

Wenn das Skript problemlos durchgelaufen ist, können wir noch einen Versuch starten, um zu schauen, ob das Backup auch geklappt hat. Wir fahren eine Domain runter und starten eine neue mit Xen:
# xen-create-image --copy=/backups/sicherungsordner --ip=192.168.1.10 --hostname=mymachine

Auf diese Weise kreiert Xen aus den Backup einen Server, der identisch sein sollte mit dem Backup und auch voll funktionsfähig sein müsste.

Wenn also die Integrität des Backups geklärt ist, können wir das Skript in die Crontab eintragen:

5 4 * * * root /usr/bin/xenBackup -q -a -t /backups -e rsync -s

Damit wird jede Nacht um 5 nach 4 ein Backups aller Domains durchgeführt. Und der erste Schritt des Backups ist eingerichtet. Natürlich haben wir noch nicht viel gewonnen. Das Backup wird auf dem selben Server durchgeführt, auf dem die Daten liegen und es wird immer nur der aktuelle Zustand festgehalten. Wenn man feststellt, dass man vorgestern eine wichtige Datei gelöscht hat, hat man keine Chance, die Datei wieder zu bekommen. Um beide Schwachstellen auszuschalten, werden wir ein differenzielles Backup auf einem separaten Server durchführen.

Die folgende Anleitung ist eine schamlose Kopie von Dean Gaudet: http://arctic.org/~dean/rdiff-backup/unattended.html

Auf dem Backup-Server kreieren wir einen neuen Nutzer Namens backups. Der Nutzer sollte keine Shell und kein Passwort haben und /backups als Heimatverzeichnis:
# useradd -m -d /backups -s /bin/false backups

Dann übergeben wir das Verzeichnis dem neuen User:
# chown backups:backups /backups/

Als nächstes installieren wir rdiff-backup auf dem Backup-Server:
# apt-get install rdiff-backup

jetzt erstellen wir einen Passphrase-freien SSH-Key für diesen User:

# su
# su -m backups
% ssh-keygen -t rsa

Bei der Frage nach dem Dateinamen und Speicherort wählen wir /backups/.ssh/id_rsa_backup
Wir vergeben wie erwähnt keine Passphrase.

Jetzt erstellen wir die Datei /backups/.ssh/config mit folgendem Inhalt

host Name-des-Wirts
hostname Name-des-Wirts
user root
identityfile /backups/.ssh/id_rsa_backup
compression yes
protocol 2

Damit geben wir an, wie der Wirt von diesem Backup-Server aus kontaktiert werden soll. Jetzt müssen wir noch den SSH-Ordner absichern:

% chmod -R go-rwx /backups/.ssh

Der nächste Schritt ist, dass wir auf dem Wirt den Zugang vom Backupserver aus erlauben.

Erst geben wir auf dem Backupserver den öffentlichen Key aus und speichern ihn in der Zwischenablage:

# cat /backups/.ssh/id_rsa_backup.pub

Jetzt wechseln wir auf den Wirt und erstellen die Datei /root/.ssh/authorized_keys2
Die Datei bekommt folgenden Inhalt (vorsicht, alles muss in einer Zeile stehen):

command="rdiff-backup --server --restrict-read-only /backups",from="Backupservername",no-port-forwarding,no-X11-forwarding,no-pty [öffentlicher Schlüssel]

Der öffentliche Schlüssel wird direkt hinter “no-pty” mit einem Leerzeichen Abstand eingefügt. Auf diese Weise kann sich ein User zwar als zwar als Root auf dem Wirt anmelden, allerdings nur mit Leserechten für /backups und nur vom Backupserver aus und nur, wenn er den passenden privaten Schlüssel zum angegebenen öffentlichen Schlüssel hat.

jetzt müssen wir auch hier den SSH-Ordner absichern:
# chmod -R go-rwx /root/.ssh

Außerdem muss auch auf dem Wirt rdiff-backup installiert sein. Zwar darf der User mit diesem root-Zugang nur das Verzeichnis /backups lesen, aber es ist trotzdem nicht schön, den Root-Zugriff von überall aus zu erlauben, wir sollten daher den Zugriff auf den Backups-Server einschränken. Dazu öffnen wir auf dem Wirt die Datei /etc/ssh/sshd_config und fügen noch eine Zeile hinzu:
AllowUsers root@name-oder-ip-des-backup-server [weitere user]

Ganz wichtig: jeder weitere User muss explizit genannt werden, ansonsten wird er nicht mehr auf den Server gelassen. Man kann sich auf diese Weise sehr schnell selbst ausschließen.

Dann müssen wir den ssh-Daemon neustarten:
/etc/init.d/ssh restart

Wir probieren das einmal aus, indem wir angemeldet als User backups auf dem Backup-Server rdiff laufen lassen:

% rdiff-backup Name-des-Wirts::/backups /backups/name-des-wirts

Hier müsste SSH einmal anfragen, ob der Wirt akzeptiert werden soll. Wenn nach einem Passwort gefragt wird, ist etwas schief gelaufen. Falls das Backup in Ordnung ist, können wir auch hier einen Croneintrag vornehmen, diesmal allerdings nicht für Root, sondern für den User backup:

# crontab -e -u backups

Der Inhalt lautet:
30 4 * * * rdiff-backup name-des-wirts::/backups /backups/name-des-wirts

Damit hätte der Wirt etwa 25 Minuten, um ein Backup der Domains vorzunehmen, bevor sich der Backupserver anmeldet, um die Sicherung auf die eigene Festplatte zu ziehen. Wenn man nicht gerade einen Fileserver betreibt, sollte die Zeit recht großzügig bemessen sein. Bei inkrementellen Backups und wenigen Veränderungen auf den Domains sollte das Backup etwa 2-3 Minuten maximal betragen.

Auf diese Weise haben wir ein recht ordentliches Backup-System. Zwar ist es bei weitem nicht perfekt. Schöner wären rotierende Backups, mit vollen Backups einmal in der Woche und täglichen differenziellen Backups, aber in diesem Bereich sind der Paranoia ohnehin keine Grenzen gesetzt. Ich begnüge mich mit diesem Setup und sichere die Daten auf dem Backup-Server gelegentlich noch auf eine externe Festplatte zu Hause.

Damit ist der vorerst letzte Teil dieser Anleitung abgeschlossen. Im ersten Teil hatten wir einen einfachen Server aufgesetzt, im zweiten den Mailserver eingerichtet, im dritten Teil den Webserver und im vierten Teil das CMS Drupal.

Eigentlich habe ich die Anleitung mehr für mich selbst geschrieben. Denn in ein paar Wochen werd ich die meisten Schritte hier wieder vergessen haben und müsste sie mir sonst wieder mühsam zusammensuchen, aber vielleicht geht es ja dem ein oder anderen genauso und ich kann helfen, ein bisschen Zeit zu sparen. Deswegen steht die Anleitung im Blog und nicht bei mir auf der Festplatte. Natürlich kann ich keine Garantie dafür übernehmen, dass bei der Anwendung der Anleitung nicht alles kaputt geht, die Daten gelöscht werden und der Server explodiert, aber zumindest kann ich versichern, dass ich alle Schritte genauso selbst durchgeführt habe 🙂

PS: Ich hab inzwischen noch ein Addendum zum Monitoring und Statistiken verfasst.

3 thoughts on “Xen auf Debian. Teil 5”

  1. Hi Kadir,

    Danke fuer die Anleitung. Hier noch zwei Bemerkungen:

    1. Das Script solltest du in /usr/local/bin legen, damit es nicht mit Programmen aus dem Debian-Repository kollidiert.

    2. Beim Backup der VMs solltest du nicht mit rsync arbeiten. Hier ist ein Backup direkt mit rdiff-backup moeglich. Dadurch hast du bereits auf dem Server inkrementelle Backups zur Verfuegung. Ich speichere somit immer nur dieses Verzeichnis gepackt und verschluesselt auf dem FTP and richte gleichzeitig daheim ein rdiff-backup Remote-Speicher als Backup ein.

    Ausserdem wundere ich mich, warum direkt nach dem Herunterfahren der VM und dem Anlegen des Snapshots die VM nicht gleich wieder hochgefahren wird. Mit einer genuegend grossen Snapshot-Partition sollte das eigentlich kein Problem sein. Ich werde die Tage jedoch noch versuchen herauszufinden, wie MySQL Backups auch ohne herunterzufahren von dom0 aus machbar sind.

Leave a Reply

Your email address will not be published. Required fields are marked *