Backup Konzept für Rootserver
Ich muss mir unbedingt mehr Gedanken über eine Backupstrategie machen. Ausgelöst wurden diese Gedanken durch einen Festplattentausch beim Rootserver vom Mobbing-Gegner, und durch einen Artikel in der aktuellen Ausgabe der C'T. Auf meinem Rootserver auf dem ja wie bereits mehrfach geschrieben so etliche kleine Webs und auch ein paar Gameserver laufen, hat das www Verzeichnis nun eine Größe von 30 GB erreicht. MacDet, der Kumpel von mir, hat auch bei Hetzner einen Rootserver der gleichen Bauart.
Mir geht es nicht um eine komplette Backupstrategie für den ganzen Server, weil wir beide eigentlich Hobby Projekte betreiben, sind wir der Meinung, das System muss nicht mit gesichert werden, da ist ein neu aufsetzen durchaus drin, wenn es hart auf hart kommt. Viel wichtiger sind die Webs und die Datenbanken.
Deshalb kam ich auf die Idee, mit Dirvish rumzuspielen. Eine englisch sprachige Anleitung, die näher auf die Client / Server Geschichte eingeht, ist Remote backup with Dirvish, rsync and ssh. Eine recht gute deutschsprachige Anleitung findet sich bei Backup HowTo [Backenhoernchen.de], hier wird die Sache mit ssh gut beleuchtet:
dirvish for Debian,
Nabble - Dirvish - Permissions and acces.
Leider ist der Vorteil von Dirvish, nämlich das platzsparenende Backup unter Verwendung von Hardlinks und Erstellung einer Directory Struktur, zugleich auch sein größter Nachteil. Denn die Filesysteme werden durch erhöhte Inode Benutzung und Hardlinkbenutzung in den Wahnsinn getrieben. ext2/3 wird ausdrücklich nicht empfohlen, denn selbst die Einrichtung eines ext2/3 Systems mit einem Inode für 4K sind nicht ausreichend dafür. Ausserdem hat ext2/3 ein Limit bei der Anzahl der Hardlinks. Man müsste also auf jfs, xfs oder Reiserfs4 ausweichen. Das bringt andere Probleme mit sich, jfs könnte ein Problem bei massivem I/O haben, wenn eine Config Option
im Kernel gesetzt ist (Mist, die Quelle verbusselt). Ausserdem ist das Setup eines dirvish Systems nicht trivial und ein wenig oversized für meine Zwecke.
Doch genug der Beschreibung des Systems, welches ich nicht genommen habe. Ich habe mich für rdiff-backup entschieden, denn genau wie dirvish baut es auf die Funktionen von rsync auf, verwendet aber die entsprechende Library, nicht das Kommando selbst. Es legt nicht wie dirvish für jeden Backuplauf ein Directory an, sondern arbeitet mit gewöhnlichen Diff Datasets. Das zurücksichern des letzten Standes oder einer älteren Version ist sehr einfach. Ein weiterer Vorteil ist das durchsichtigere konfigurieren, finde ich wenigstens. Als Hauptinformationsquelle habe ich die Man page genommen. Aber es gibt auch prima Anleitungen im Netz, die Beschreibung von Unattended rdiff-backup HOWTO zum Beispiel. Im erweiterten Teil geht es um die detailierte Beschreibung meiner Konfiguration.
drwx------  5 zback nogroup 4096 2008-10-16 19:02 zockerback
rdiff-backup /etc/ [backupuser]@mobbing-gegner.de::backup_test
rdiff-backup -l [backupuser]@mobbing-gegner.de::backup_test
Found 1 increments:
   increments.2008-10-16T19:06:07+02:00.dir  Thu Oct 16 19:06:07 2008
rdiff-backup ist Spezialist für die Backup Erzeugung einzelner Verzeichnis Strukturen.
Einschub: die Partitionierung für den Backupspace auf beiden Servern:
Unsere beiden RootServer sind nicht völig gleich aufgebaut, MacDet hat bei sich ein lvm aufgesetzt. Da er von Anfang an nicht alles an verfügbarer Kapazität der mit softraid1 gefahrenen 400GB Platte verbraten hat, konnte er mir ein Volume mit 128G als Backupspace zur Verfügung stellen. Mittlerweile habe ich aufberäumt und denke, dieser Platz ist mehr als ausreichend. Ich war damals nicht ganz so schlau, ich habe kein lvm aufgesetzt und alles verbraten. Sich auf quota verlassen und darüber seinen Backupspace bei mir begrenzen, wollte ich nicht. Ich habe es anders gemacht. Ich habe ein 130 G großes File mit
nice dd if=/dev/zero of=/var/www/backup/BACKUP_mobbing-gegner bs=1024 count=130M
angelegt. (Vorsicht! das beeinflusst die Performance des Server ganz erheblich) Dann ein Filesystem darin angelegt,
mkfs.ext2 /var/www/backup/BACKUP_mobbing-gegner
Dieses Filesystem mit loop gemountet
mount -o loop /var/www/backup/BACKUP_mobbing-gegner /mobbingback
Gedanken über die Backup Strategie
Auf beiden Root Servern ist ispconfig installiert. Das erleichtert das Backup Vorhaben natürlich ungemein, weil das Script dann nicht groß an die Servergegebenheiten angepasst werden muß.
Die Web Verzeichnisse liegen unter /var/www. Da dort natürlich viele Eigentümer und Gruppen existieren, nimmt man normalerweise root als user für das Backup System. Man könnte aber auch auf die Idee kommen und einen dedizierten User für's Backup zu kreieren und ihn jeweils zu den Gruppen connecten, damit er alle Lesen kann. Nur in die Gruppe des Webservers mit aufzunehmen ist auch eine Möglichkeit, nur muss man dann die diversen privaten Config Dateien für die unterschiedlichen CMS-, Blog- und was noch so Systemen auf andere Weise sichern. Da sich diese Dateien nicht so häufig ändern, wäre ein Script denkbar, das - als root ausgeführt- alle diese privaten Dateien in ein tar packt und nur dem Backup User mit Leseberechtigung zur Verfügung stellt.Für Die Datenbanken muss man eh eine Extrawurst braten, warum also nicht?
Eine weitere Methode wäre, der Reihe nach einfach das Backupscript als webuser starten und das Backup also praktisch pro User anlegen. Der Charme dieser Lösung ist nicht zu übersehen. Da die Backups alle entsprechend kleiner sind, ist das wiederfinden von Files einfacher und schneller. Außerdem wäre dann sogar eine Integration in ISPConfig denkbar, sofern man das will. Der Nachteil ist, das es kein Backup für alle, sondern eine Anzahl von Einzelbackups gibt. Es kommt natürlich auf die individuellen Verhältnisse an, ab 50 Webs sollte man sich das überlegen und eben doch ein Gesamt Backup mit root durchführen. Zweitens ist diese Lösung suboptimal, denn es gibt keinen User, der garantiert alle Dateien der Webpräsenz lesen darf. Abhilfe: gar nicht so einfach, wenn man seinen Untermietern nicht traut, denn vom Grundsatz her sollte ja der Hauptuser nicht unbedingt die Datenbank Passworte einer seiner Untermieter (lies Subdomain) sehen.Noch wichtiger anders herum: Der Untermieter sollte keinesfalls in der Lage sein, an die Konfigurationensdaten des Hauptbenutzers zu kommen.
# Ausschnit aus meinem Web
web9/
|--- [web9/cgi-bin/]
|--- [web9/phptmp/]
|--- [web9/ssl/]
|--- [web9/download/]
|--- [web9/ftp/]
|---[web9/ftp/incoming/]
|---[web9/ftp/software/]
|---[web9/web/ (Das Hauptbenutzer Web
|---[web9/web/s9y/]
|---[web9/user/]
|---[web9/user/web9_btu/] (Subdomain)
|---[web9/user/web9_bed/] (Subdomain)
|---[web9/user/web9_fox/] (Subdomain)
Das ist jetzt noch nicht die komplizierteste Struktur, aber ich glaube, das Problem wird deutlich.
Deshalb habe ich mich doch für die einfache Lösung entschieden. Ich werde rdiff-backup als root Prozess laufen lassen.
# Die MinimalLösung sieht momentan so aus:
EXCLUDEFILE="/root/ockerbackup-excld.txt"
OPTIONS=" --ssh-no-compression --exclude-globbing-filelist $EXCLUDEFILE "
rdiff-backup $OPTIONS /var/www/ [backupuser]@mobbing-gegner.de::backup_test
Wobei in EXCLUDEFILE z.Zt. nur das steht:
/var/www/backup/*
/var/www/*/log/*
Die Einträge in der exclude Liste müssen natürlich gepflegt werden. Gleich beim ersten Lauf des Backups bekam ich die Fehlermeldung:
UpdateError web27/user/web27_game/bf2/serverfiles/bf2_aix/python/bf2/logs/bf2game_20081016.log
Updated mirror temp file backup_test/web27/user/web27_game/bf2/serverfiles/bf2_aix/python/bf2/logs/rdiff-backup.tmp.188060
does not match source
Also in diesem Fall habe ich
/var/www/web27/user/web27_game/bf2/serverfiles/bf2_aix/python/bf2/logs/*
nachgetragen.
Was zum kompletten von mir gewünschten Backup fehlt, sind u.a. die Userdatenbanken. Dafür setze ich AutoMySQLBackup ein. (Gefunden via daniel.omschallom) Das bash Script automysqlbackup macht mit mysqldump ein daily,weekly,monthly backup. Es ist vielfältig einstellbar. Ich sichere damit alle Datenbanken in ein Backupverzeichnis, welches ich mit rsync auf dem Backupserver übertrage. Eigentlich wäre das Bash Script einen eigenen Artikel wert, ich verzichte vorerst darauf, ich setze es ja auch erst seit heute ein.
Die Verzeichnisse /boot, /etc, /home, /usr/local/bin und /root sichere ich auch, allerdings ebenfalls mit rdiff, das spart Platz und gibt mir Versionssicherheit. In der Praxis kommt es zwar selten vor, aber es ist schon denkbar, das man sich mal eine Config von einem Service zerschossen hat, es aber erst Tage später merkt.
Das komplette Backupscript ist nun in der Testphase. Wenn nach ein paar Wochen die Kinderkrankheiten ausgemerzt sind und ich es um eine Löschfunktion erweitert habe, werde ich das Script veröffentlichen.
Hallo, also ich hab mich auch für rdiff-backup entschieden, weil es einfach flexibler ist. Hardlinks sind wie gesagt keine echte alternative, mit dem inkrementellen Diff kann man das ganze sogar auf einen Windows-Server mit Cygwin-SSH und NTFS backupen (hab nen Notebook, mit dem ich die wichtigen Sachen hin und wieder rüberspiele - über den Router zuhause und portweiterleitung ). Sogar andere Dateisysteme wie FAT sollten (theoretisch) möglich sein, so werden z.B. Großbuchstaben maskiert wenn rdiff-backup feststellt, dass das Dateisystem dies nicht kann.
Eigentlich war ich ja drauf und dran, Dirvish nach dem Artikel mal nen Versuch zu geben, aber deine Ausführungen haben das gut verhindert, danke!
Flo Wie.
Danke Ja, es ist weitgehend plattformunabhängig. Ich werde es wohl dann auch mal für meinen Laptop einsetzen und den Fileserver im Keller als Sicherungsmedium nehmen. Nur per wlan habe ich vor der ersten Sicherung Angst... Da muss ich ihn wohl mal nachts in den Keller stellen und direkt anstöpseln...
Na endlich mal jemand, der das von mir schon seit langem beworbene rdiff-backup nutzt Ebenso wie du nutze ich es als root, jedoch wird das Backup vom Backup-Server aus gestartet, nicht vom Webserver aus. Funktioniert seit Jahren zuverlässig und schnell! Auch das Rücksichern läuft
Zusätzlich sichere ich meinen Laptop (inkl. Diplomarbeit!) per rdiff-backup, mal auf nen Backup-Server, mal auf ne externe Festplatte - inkrementelles Backup inklusive.
Abbrechende Backups sind übrigens kein Problem, anschließend nur kurz ein rdiff-backup --check-destination-dir /dir und alles ist wieder im grünen Bereich.
Jau, danke für den Tipp, brauche ich vielleicht morgen früh, wenn der erste Lauf per Cron gelaufen ist Ist auch wirklich einfach zu bedienen.
Eine grafische Oberfläche wäre vielleicht noch einmal interessant, für Menschen die nicht so mit der Shell umgehen können. So in Richtung Apfel TimeMachine (nicht dass ich abkupfern wollte).
Ja, ne GUI wäre schön, aber letztlich macht ja nur die regelmäßige Datensicherung Sinn. Und da ist ein Script per Cron einer Gui überlegen, auf dem Server sowieso. Allerdings wäre eine Gui zum zurücksichern evtl. sinnvoll. Weil, wenn's eilig ist und man den Vertipper in der Console mal wieder nicht sieht, ist halt 'ne Gui bequemer. Nur die list erst wieder langwierig vom Backupplatz die Files ein, bis man dann was zum Auswählen bekommt, ist man in der Console dreimal fertig
Natürlich, wenn sich genug damit auskennt, kann man natürlich um Längen schneller sein. Aber ich meine ehr so eine Verzeichnis auswählen und glücklich-sein Lösung für Ottonormalbenutzer (gibts sowas bei Linux?), die sicherlich auch von der versionierten Sicherung profitieren könnten.
Damit auf rdiff-backup aufzusetzen wäre eine schöne Sache, man muss das Rad ja nicht neu erfinden.
Du meinst sowas wie http://code.google.com/p/flyback/ Gerade mal die svn Cersion ausprobiert...kome damit nicht zurecht
[update:19.10.08] Meine bisherige Zwischenlösung, funktioniert bereits, Fehlermeldungen sind momentan nur rudimentär, aber mal so als Denkanstoß:
[geshi lang=bash]
!/bin/bash
Ockerbackup
V0.4 bed
Dieses Script ist speziell fuer den eigenen Bedarf, es ist in keiner Weise
dafuer geeignet, es ohne Kontrolle sich selbst zu uerberlassen
Hinweis: Bei rsync ist nach dem Hostnamen 1 Doppelunkt der Trenner zum
Target Directory, also wie auch bei scp
Bei rdiff-backup sind 2 Doppelpunkte notwendig
#
Optionen für rsync und rdiff-backup
BACKUPTARGET="[backupuser]@zielserver"
Optionen für rdiff-backup
EXCLUDEFILE="/root/ockerbackup-excld.txt" OPTIONS=" --ssh-no-compression --exclude-globbing-filelist $EXCLUDEFILE "
Optionen fuer automysqlbackup
SQLBACK=/var/www/backup/
Ab hier sollte kein Einstellbedarf mehr sein
nice /root/automysqlbackup.sh
rsyncen der Datenbanken
Da die Datenbanken bereits durch automysqlbackup.sh versioniert werden,
ist rsync sinnvoller
BACKUP_mobbing-gegner ist excluded
nice rsync -at --exclude=BACKUP_mobbing-gegner --bwlimit=2500 $SQLBACK $BACKUPTARGET:backup_mysql retval=$((retval - $? )) if [ $retval -gt 0 ]; then echo "SQLBACK Backup failed!" fi
rdiffbackup des /etc Verzeichnisses
nice rdiff-backup /etc $BACKUPTARGET::backup_etc retval=$((retval - $? )) if [ $retval -gt 0 ]; then echo "etc Backup failed!" fi
rdiffbackup des /home Verzeichnisses
nice rdiff-backup /home $BACKUPTARGET::backup_home retval=$((retval - $? )) if [ $retval -gt 0 ]; then echo "home Backup failed!" fi
rdiffbackup des /root Verzeichnisses
hautpsächlich wegen der Scripte und wegen der ispconfig sachen
nice rdiff-backup /root $BACKUPTARGET::backup_root retval=$((retval - $? )) if [ $retval -gt 0 ]; then echo "root Backup failed!" fi
rdiffbackup des /boot Verzeichnisses
nice rdiff-backup /boot $BACKUPTARGET::backup_boot retval=$((retval - $? )) if [ $retval -gt 0 ]; then echo "boot Backup failed!" fi
rdiffbackup des /usr/local/bin Verzeichnisses
nice rdiff-backup /usr/local/bin $BACKUPTARGET::backup_local-bin retval=$((retval - $? )) if [ $retval -gt 0 ]; then echo "local-bin Backup failed!" fi
rdiffbackup des /var/www Verzeichnisses
Beruecksichtigung des exculdefiles und Ausfuehrung als nice
weil dieser Teil sehr lange läuft, wenn es der erste Aufruf ist
nice rdiff-backup $OPTIONS /var/www/ $BACKUPTARGET::backup_www retval=$((retval - $? )) if [ $retval -gt 0 ]; then echo "www Backup failed!" fi [/geshi] (Gleichzeitg ein Test für das Geshi Pling, welches mir noch immer nicht gefällt. was sollen die escapeten Gänsefüßchen?
Funktioniert bei mir auch nicht vernünftig. Zumindest nicht mit meinem schon fertigen Backup . Na, was solls. Hab im Moment eh nicht genug Zeit, mich ernsthaft damit zu beschäftigen.
Fazit: mit Commandline wär das nicht passiert
Ich verwende Duplicity. Sehr zu empfehlen, da es die Backups auch mit GPG verschlüsseln kann, dann kann man die sogar auf einem Google-FS oder unsicheren Webspace lagern.
Ja duplicity war auch vorher bei mir im Einsatz. Da bei Hetzner der Backupspace aber viel zu gering war und die täglichen Backups doch ganz schön Platz brauchten, suchte ich nach einer anderen Lösung. Die stärke von Duplicity, nämlich die Verschlüsselung ist auch der Schwachpunkt. Wenn du den Key nicht mehr hast, dann bist du völlig machtlos.