backup – Finn Christiansen

Inkrementelle Remote-Backups mit rsnapshot

Finn Christiansen — Sun, 27 Mar 2016 08:45:47 +0000

Dass regelmäßige Backups unerlässlich sind, ist kein neues Thema. Seit mehreren Jahren setze ich das zuverlässige rsnapshot ein, welches mit Hilfe von rsync und SSH inkrementelle, rotiernde Backups anderer Server ausführen kann. Ein einziges regelmäßiges Voll-Backup ist keine gute Idee, da eine zu wiederherstellende Datei vielleicht zu spät bemerkt und in das Backup übernommen wird. Der zusätzliche benötigte Speicherplatz hält sich in Grenzen, da rsnapshot unveränderte Dateien nicht erneut sichert, sondern einen Hardlink erzeugt. Ich zeige euch kurz meine Konfiguration, welche Backups per SSH ausführt und jeweils Backups der Tage, Wochen und Monate aufhebt.

Der Backup-Server selbst läuft mit Ubuntu 14.04 LTS, die übrigen Server sind Debian 8 Server. Es gibt leider ein kleines Problem mit rsnapshot bei Ubuntu 14.04, weshalb die manuelle Installation der aktuelleren rsnapshot Version ignoriert werden kann, falls kein Ubuntu 14.04 als Backup Server eingesetzt wird. Die Befehle und Konfiguration sollten aber im Prinzip ziemlich identisch bzw. austauschbar sein. Alle folgenden Befehle werden als Root ausgeführt.

Konfiguration des Backup-Servers

Serverseitig sind abgesehen von der Installation und Konfiguration von rsnapshot weniger Vorbereitungen notwendig.

# rsnapshot installieren (oder manuell installieren, falls vom Bug in rsnapshot 1.3.1-4 betroffen)
apt-get install rsnapshot
# SSH Schlüsselpaar erzeugen
ssh-keygen
# Falls vom rsnapshot Bug betroffen, aktuellere Version installieren
wget https://launchpad.net/ubuntu/+archive/primary/+files/rsnapshot_1.4.0-1_all.deb
dpkg -i rsnapshot_1.4.0-1_all.deb
# rsnapshot Konfiguration vornehmen ...
vim /etc/rsnapshot.conf

Ich habe aus meiner rsnapshot.conf mal alle Kommentare und leere Zeilen entfernt, so dass die wesentliche Konfiguration übrig bleibt. Ein paar Zeilen habe ich zwecks Erläuterung wieder kommentiert:

config_version	1.2
snapshot_root	/home/rsnapshot/
cmd_cp		/bin/cp
cmd_rm		/bin/rm
cmd_rsync	/usr/bin/rsync
cmd_ssh		/usr/bin/ssh
cmd_logger	/usr/bin/logger
cmd_du		/usr/bin/du
# Die Bezeichnungen daily, weekly und monthly dienen nur der besseren Zuordnung.
# Die regelmäßige Ausführung wird über einen entsprechenden Cronjob erreicht.
retain		daily	7
retain		weekly	4
retain		monthly	3
verbose		2
loglevel	3
logfile		/var/log/rsnapshot.log
lockfile	/var/run/rsnapshot.pid
# rsync soll auf den Backup-Clients mit sudo aufgerufen werden.
rsync_long_args		-evpE --rsync-path='sudo rsync'
# Der SSH Schlüssel des root Benutzer soll verwendet werden
ssh_args	-i /root/.ssh/id_rsa
# Die zu sichernden Server / Verzeichnisse (nur ein paar Beispiele)
# Format: backup Quelle Ziel (Ziel = snapshot_root + [daily|weekly|monthly] + Pfad)
backup	rsnapshot@mail.finnchristiansen.de:/etc/	mail.finnchristiansen.de/etc/
backup	rsnapshot@mail.finnchristiansen.de:/home/	mail.finnchristiansen.de/home/
# Einzelne Verzeichnisse können ignoriert werden
backup	rsnapshot@mail.finnchristiansen.de:/var/	mail.finnchristiansen.de/var/	+rsync_long_args=--exclude=/var/cache/ --exclude=/var/lock/ --exclude=/var/run/
backup	rsnapshot@data.finnchristiansen.de:/etc/	data.finnchristiansen.de/etc/

Vorbereitungen auf dem zu sicherenden Server (Backup-Client)

Rsnapshot führt die Sicherung per SSH durch, weshalb ein User angelegt werden muss. Dieser wird sich einloggen und rsync mit sudo aufrufen, weshalb noch ein entsprechender sudoers Eintrag erforderlich ist.

# Falls noch nicht geschehen, sudo installieren
apt-get install sudo
# Nutzer für das Backup anlegen
useradd -m -s /bin/bash rsnapshot
# Dem Nutzer erlauben, rsync mit sudo aufzurufen
echo "rsnapshot ALL=NOPASSWD: /usr/bin/rsync" > /etc/sudoers.d/rsnapshot
# Anmeldung per SSH-Schlüssel ermöglichen
mkdir /home/rsnapshot/.ssh
# Auf dem Backup-Server mit "cat /root/.ssh/id_rsa.pub" den öffentlichen Schlüssel anzeigen und kopieren (da rsnapshot als root ausgeführt wird)
echo "<Öffenterlicher Schlüssel des root-Nutzers des Backup-Servers>" >> /home/rsnapshot/.ssh/authorized_keys
# Eigentümer und Berechtigungen des .ssh Verzeichnisses und der Datei authorized_keys anpassen
chown -R rsnapshot: /home/rsnapshot/.ssh/
chmod 700 /home/rsnapshot/.ssh/
chmod 600 /home/rsnapshot/.ssh/authorized_keys

Zurück zum Backup-Server

Nachdem die Vorbereitungen auf den Backup-Clients vorgenommen wurde, wird der SSH Fingerprint des Backup-Clients zur Liste bekannter Hosts hinzugefügt, rsnapshot einmal manuell getestet und anschließend ein Cronjob angelegt.

# SSH Login testen und SSH Fingerprint mit "yes" bestätigen, mit "exit" Verbindung wieder trennen
ssh rsnapshot@server.tld
# rsnapshot manuell testen
rsnapshot daily
# Wenn rsnapshot fehlerfrei ausgeführt wird, Cronjob erstellen:
vim /etc/cron.d/rsnapshot
# und folgenden Inhalt einfügen
30 3 1 * * root /usr/bin/rsnapshot monthly
40 3 * * 0 root /usr/bin/rsnapshot weekly
50 3 * * * root /usr/bin/rsnapshot daily

Bei Backups ist es wichtig, dass der Backup-Server unabhängig von den zu sichernden Servern ist. Zu Hause erledigt die Backups ein auf OpenMediaVault basierendes NAS mit RAID5, hier setze ich jetzt auf einen Strato vServer, um die anderen vServer bei active-servers oder Hetzner zu sichern.

Planung, Umsetzung und Pflege der neuen Infrastruktur

Finn Christiansen — Fri, 25 Mar 2016 12:52:09 +0000

Nachdem ich durch einen Storag-Ausfall inklsuive Datenverlust zu einem ungeplanten Relaunch gezwungen war, setze ich nun mein Hobby Projekt fort und habe mir ein paar Gedanken gemacht, wie ich meine kleine Infrastruktur wieder aufbaue. Ich werde die Struktur und die Gründe für meine Entscheidungen hier kurz anreißen, aber diesen Beitrag zukünftig ein wenig ergänzen, um ihn aktuell zu halten. Die Meinungen zur Umsetzung sind sicherlich unterschiedlich, aber mir dient es als Dokumentation und der eine oder andere kann vielleicht die eine andere Information gebrauchen.

Wer nur einen Web- und Mailserver benötigt und den Aufwand gering halten möchte, der greift zu den fertigen Angeboten eines der vielen Anbieter hierfür. Ich möchte aber möglichst viel Flexibilität, Dinge selbst entscheiden und festlegen können und dabei noch etwas lernen. Primär benötige ich nur Web- Mail- und XMPP-Server, aber auch die notwendigen DNS Server möchte ich selbst betreiben.

Die Wahl der Distribution

Bisher habe ich CentOS 6 eingesetzt, welches inzwischen recht eingestaubt ist. Eine Aktualisierung auf CentOS 7 war für mich ebenfalls keine Option, da mir Debian 8 inzwischen deutlich besser gefällt, aktuellere Pakete und eine größere Paketauswahl bietet. Zumindest bin ich beim Betrieb anderer Debian Installation deutlich seltener auf Probleme gestoßen, die durch fehlende oder alte Pakete verurascht wurden. Außerdem ist Debian bei mir zu Hause aufgrund diverser Raspberry Pis inzwischen deutlich in der Überzahl, was die Administration der übrigen Server ein wenig vereinheitlichen sollte.

Domain-Registrar und DNS Server

Meine Domains habe ich inzwischen zu INWX umgezogen, da diese erstens die Verwendung eigener DNS Server ermöglichen und zweitens DNSSEC unterstützen. Den notwendigen Dnskey muss man zwar (noch) per Mail übermitteln, da dies aber nur selten notwendig ist, sehe ich darin kein Problem.

Einer der DNS Server läuft (noch) bei active-servers, der zweite bei Hetzner. Als DNS Server setze ich PowerDNS mit einer klassischen Master-Slave Konfiguration und AXFR ein. Alternativ bestünde die Möglichkeit, die DNS-Server mit einer Datenbankreplikation zu synchronisieren. Zur Verwaltung setze ich Poweradmin in Version 2.1.8 ein, welches zwar noch nicht als stable released wurde, aber bereits fehlerfrei DNSSEC unterstützt.

Mailserver

Aus gutem Grund habe ich mich nicht sofort von active-servers verabschiedet. Mein alter Mailserver lief dort und ich wusste, dass meine IP Adresse auf keiner Blacklist ist. Sollte man einen neuen Mail-Server planen oder einen bestehenden umziehen, muss erstens an die Reverse-DNS Einträge, eventuelle SPF-Records und an eine Blacklist Prüfung gedacht werden. Bei einigen Hostern kann es vorkommen, dass der „Vorbesitzer“ der IP Adresse (meist unbewusst) eine Spam-Schleuder betrieben hat.

Ich setze Dovecot und Postfix jeweils mit einem PostgreSQL Backend ein. Gestützt und Verwaltet wird das ganze durch den VirtualMailManager, auf den ich vor Jahren gestoßen bin und immer noch sehr mag. Domains, Konten, Aliase und andere Einstellungen lassen sich bequem über die Konsole verwalten. Eine grafische Oberfläche besitzt der VirtualMailManager nicht, das ist in meiem Fall aber auch nicht nötig.

Für die Überprüfung der E-Mails auf Spam und Viren setze ich, wie viele andere auch, ClamAV und Spamassassin ein. Im Unterschied zum alten Server setze ich dank der hilfreichen Beiträge von Thomas Leister hierfür nun amavis ein, was für mich eine saubere und übersichtliche Lösung ergibt.

Nachdem SPF, DKIM und DMARC wieder vollständig eingerichtet und konfiguriert sind, ist das nächste große Thema, das ich angehen möchte, die Erreicheiner einer höheren Verfügbarkeit. Einen zweiten Mailserver (sprich SMTP-Server als 2. MX) einzusetzen, ist einfach. Viel interessanter finde ich die zusätzliche Synchronisation von Dovecot (dsync) und der VMM-Datenbank (PostgreSQL Replikation), wodurch eine gewisse Ausfallsicherheit erreicht werden kann.

Webserver

Ein Server mit etwas mehr Leistung bildet bei mir den Webserver, um diesen Blog, Feedreader, ownCloud und ein paar kleinere Webanwendungen und statische Webseiten zu beherbergen. Hier setze ich ganz klassisch den Apache Server ein, da ich mit dessen Konfiguration recht vertraut bin. Als performanter Nachfolger wird ja gerne nginx empfohlen. Das ist auch für mich eine interessante Option, wenn ich einmal die Zeit zur Migration habe.

Backups

Wie ich erst kürzlich feststellen musste, darf man bei Backups wohl nur sich selbst vertrauen. Momentan habe ich Server bei active-servers und Hetzner. Bei active-servers besteht gegen Aufpreis die Möglichkeit, täglich ein VM-Backup ausführen zu lassen. Bei Hetzner besteht diese Möglichkeit nicht, es kann entweder manuell ein Snapshot erstellt werden oder Backup-Speicherplatz dazugebucht werden. Ich vermute, dass Hetzner seine Storages ein wenig besser im Griff hat als active-servers, aber um auf Nummer Sicher zu gehen, führe ich dateibasierte inkrementelle Backups mit rsnapshot auf einem Strato vServer ausreichendem Speicherplatz aus.

Monitoring

Bei dem Thema komme ich momentan etwas schleppend voran. Ich möchte distribtued Monitoring einsetzen, da ich auch meine Geräte zu hause überwachen möchte. Bisher habe ich hierfür Shinken eingesetzt, was mir einen zentralen Punkt für die Konfiguration, Mail-Versand und Einsicht in die Status der Server geboten hat. Für die Überwachung der heimischen Geräte konnte dann ein Raspberry Pi eingesetzt werden. Ähnliches schwebt mir jetzt auch vor, allerdings auf Basis von Icinga2, welches ich aufgrund des anderen Konzepts im Gegensatz zu allen anderen nagioiden Systemen sehr spannend finde.

Motivation

Warum eigentlich dieser hohe Aufwand? Natürlich würde ich auch ohne all diese Dinge überleben können und eine E-Mail Adresse bei einem entsprechendenn Anbieter würde natürlich ebenso gut funktionieren. Wenn ich eine entsprechende Internetanbindung hätte, würde ich sogar (fast) alle Dienste bei mir zu Hause betreiben, was sogar einen noch höheren Aufwand bedeuten würde. Ein Grund ist der Datenschutz. Natürlich liegen in diesem Fall die Daten quer in Deutschland verteilt, aber wenigstens gibt es hier keine Automatismen, die meine Daten algorithmisch durchsuchen, auswerten oder weitergeben. Der zweite Grund ist meine Neugier und der Wunsch, etwas dazuzulernen. Ich lerne am besten etwas, wenn ich es selbst mache.

Datenverlust inklusive Backups und Neustart

Finn Christiansen — Sat, 12 Mar 2016 12:09:12 +0000

Am Sonntag, dem 06. März, bemerkte ich Probleme mit meinem virtuellen Servern. Webseiten und Dienste waren nicht mehr erreichbar oder haben fehlerhaft geantwortet. Zuerst war ich nicht beunruhigt, da mein Hoster (active-servers) bereits in der Vergangenheit eine defekte Platte im Storage austauschen musste, was zu einer schlechten Performance während des RAID Rebuilds geführt hat. Dieses Mal wurde der Ausfall aber durch einen defekten RAID Controller verursacht, der zwar zügig ausgetauscht wurde, aber viel größere Probleme verursacht hatte.

Was ist passiert?

Alle meine dort gehosteten 4 virtuellen Maschinen ließen sich nach der Reparatur nicht mehr booten, die viruellen Festplatten waren defekt. Einer der Server war weniger schlimm betroffen, aber das Dateisystem war absolut kaputt, so dass ein ausgeführtes

fsck

hoffnungslos war. Zwar habe ich jede Nacht Backups auf Dateiebene ausgeführt, aber der dafür zuständige Server lag wider meines Erwartens und meiner ursprünglichen Intention auf dem selben Storage. Mit dem dateibasierten Backup hätte ich alle drei übrigen Server innerhalb eines Tages wiederherstellen können. active-servers bietet zwar (kostenpflichtige) automatische Backups der VMs an, die ich auch zukünftig nutzen werden, aber meine Erwartungshaltung gegenüber Backups entsprach nunmal nicht deren Hostingphilosophie. VM-Backups muss man bei active-servers definitiv ausführen, da sie selbst scheinbar kein Backup ihrer Storages oder eine Art Redundanz besitzen.

Und nun?

Zwar ist das hier mein schlimmster Datenverlust, den ich je hatte, aber ich sehe es als Neustart und werde alles wieder aufbauen. Wirklich wichtige, persönliche Daten liegen eh lokal bei mir zu Hause auf mehreren verschiedenen Systemen, aber dieser Blog und alle übrigen Dienste sind ein großes Hobby von mir. Ich hatte bereits vorher einen weiteren Server bei einem anderen Hoster als DNS- und Backup-Server eingerichtet, aber die Umsetzung war noch nicht abgeschlossen, schade. Nun setze ich auf 3 Hoster und werde die Backups gut verteilen und zukünftig, wenn meine DSL Anbindung das hergibt, auch hier zu Hause Backups speichern. Ich sehe das ganze eher als Chance, so ein Datenverlust wird mir nie wieder passieren.

Dieser Blog und vor allem die Konfigurationen der Server haben mir als Lehrobjekt, Nachschlagewerk und Versuchslabor gedient. In den nächsten Tagen und Wochen werde ich noch sehr beschäftigt sein, weshalb ich keine neuen Themen hier im Blog behandeln werden, auch wenn bei mir einiges in der Warteschlange hängt. Inzwischen bin ich wieder per Mail (kontakt@finnchristiansen.de) erreichbar, XMPP werde ich in der nächsten Woche wieder in Betrieb nehmen. Leider ist auch mein pimux.de Projekt betroffen, das ich gerade erst begonnen hatte. Wenn alle Backups wie gewünscht funktionieren, werde ich die Registrierungen bei pimux.de wieder freischalten, ich bitte diese enorme Panne zu entschuldigen.

Dafür, dass dies alles hier nur ein Hobby ist, habe ich in den letzten Jahren erstaunlich viele meiner Stunden darin investiert. Da aber alles bis zum Schluss ziemlich reibungslos funktioniert hatte, war der regelmäßige Pflegeaufwand recht gering. Letztendlich war eben alles nur ein Hobby. Jedem, dem noch nie eine kleine oder große Panne dieser Art passiert ist, rate ich zur Achtsamkeit.

Neue Chancen durch den Neustart

Einen großen Vorteil sehe ich als Optimist an diese Sache aber: Ich werde jede Menge Altlasten los und spare mir meine geplante Migration von CentOS 6 auf Debian 8. Meine Domain habe ich nun auch zu einem anderen Registrar umgezogen, da das Ändern des für DNSSEC notwendigen Dnskeys mit dem Umweg über active-servers recht umständlich gewesen ist. Außerdem ließen sich angeblich keine DNS Server nutzen, dessen IP Adresse nicht zu active-servers gehört. Das habe ich zwar nicht verstanden, aber ok. Nun werde ich mir eine Pause gönnen und meinen Feed Reader Tiny Tiny RSS wieder mit Blogs befüllen, darin hatten sich zusätzlich zu osbn.de und dem ubuntuusers.de Planeten weit über 100 Blogs angesammelt. Für Vorschläge und Tipps für Blogs, die freie Software etc. als Thema haben, bin ich dankbar.