Home-Server mit Ubuntu 6.06 LTS, Teil 7
Nach dem ersten Durchlauf werden jeweils nur noch Dateien gesichert, die neu hinzugekommen sind oder sich verändert haben. Nun fehlt nur noch der Feinschliff - da wir das Ganze automatisieren wollen, braucht es noch einen kleinen Eintrag in die Datei /etc/crontab. Linux User hat einen hervorragenden Artikel, der die Funktionsweise von cron (und at) verständlich macht.
Wir editieren /etc/crontab mit sudo nano /etc/crontab.
# /etc/crontab: system-wide crontab # Unlike any other crontab you don't have to run the `crontab' # command to install the new version when you edit this file. # This file also has a username field, that none of the other crontabs do. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command 17 * * * * root run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily 47 6 * * 7 root test -x /usr/sbin/anacron || run-parts --report /etc/cron.weekly 52 6 1 * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.monthly #
Wir fügen eine Zeile hinzu, die neue Konfiguration sieht so aus:
# /etc/crontab: system-wide crontab # Unlike any other crontab you don't have to run the `crontab' # command to install the new version when you edit this file. # This file also has a username field, that none of the other crontabs do. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command 17 * * * * root run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily 47 6 * * 7 root test -x /usr/sbin/anacron || run-parts --report /etc/cron.weekly 52 6 1 * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.monthly 0 3 * * * root rsnapshot daily #
[Anm. d. Ed. Statt /etc/crontab zu ändern, sollte man die Crontab des Root-Benutzers mit sudo crontab -e verwenden.]
Der Server macht nun automatisch (einmal pro Tag, immer nachts um 3 Uhr) ein Backup der oben definierten Verzeichnisse. Dieses Backup wird sich bis zu sieben Tage zurückverfolgen lassen. Es wird also z.B. möglich sein, den exakten Stand der Verzeichnisse von vor vier Tagen wieder einzuspielen.
Dennoch verbraucht RSnapshot keinen unnötigen Platz, da es mit Hardlinks arbeitet. Die Dateien werden zwar mehrmals in den gesicherten Verzeichnissen angezeigt, sind aber in Wirklichkeit nur einmal vorhanden. Trotzdem lassen sie sich aber gezielt wiederherstellen.
Während unsere erste Sicherung noch läuft, nutzen wir die Zeit und stellen noch kurz unseren Standard-Editor um. Dies hat zwar überhaupt nichts mit der ganzen Backup-Geschichte zu tun, aber da wir uns mittlerweile wohl an Nano gewöhnt haben, machen wir das doch auch gleich:
fish@fishbox:~$ which nano /usr/bin/nano fish@fishbox:~$ export EDITOR=/usr/bin/nano
Da das Backup immer noch läuft, hier noch ein weiterer Tipp: Um das Arbeiten in der Konsole zu vereinfachen, empfehle ich (und Lunkwill auch) die Installation von Midnight Commander. Ein Dateimanager ähnlich wie Total/Free Commander bzw. Krusader für die Konsole mit einer Zwei-Panel Ansicht. Wir installieren wie folgt:
fish@fishbox:/$ sudo apt-get install mc
(falls Sie hier mc zum ersten Mal installieren, die Abhängigkeitsprüfung einfach bejahen)
Gestartet wird das Teil mit dem einfachen Kommando mc bzw. sudo mc für einen Root-Midnight-Commander mit Administratorrechten. Bis das Backup fertig ist, kann man ja mal damit noch ein wenig rumspielen und sich mit dem Programm vertraut machen. Unten im Anhang auch noch ein Screenshot davon.
Ist das Backup fertig, sehen wir nach, ob auch alles geklappt hat:
fish@fishbox:/media/backups$ ls daily.0 fish@fishbox:/media/backups$ cd daily.0 fish@fishbox:/media/backups/daily.0$ ls localhost fish@fishbox:/media/backups/daily.0$ cd localhost fish@fishbox:/media/backups/daily.0/localhost$ ls etc home media usr fish@fishbox:/media/backups/daily.0/localhost$
Ja, die definierten Verzeichnisse sind auf der Backup-Festplatte alle 1:1 dupliziert worden. Unsere erste Sicherung ist also gelungen. Und jetzt, wo wir diese Prozedur hnter uns gebracht haben, können wir uns zurücklehnen - unsere Backups macht Ubuntu nun vollautomatisch und wir müssen uns um nichts mehr kümmern!
Anhang - Backup nur bei gemounteter Platte ausführen
Hier ein wichtiger Anhang aus »aktuellem Anlass« - als ich heute morgen aufwachte, war mein Server nämlich kaum mehr erreichbar, MySQL lieferte Fehler, MPD und Giantdisc funktionierten nicht mehr. Was war passiert?
Das Problem war folgendes: Mein Backup wird mit obiger Konfiguration so oder so ausgeführt, völlig egal, ob die Festplatte gemountet ist oder nicht! Wieso? Nun, wir sehen uns nochmals die Datei /etc/rsnapshot.conf an:
# If no_create_root is enabled, rsnapshot will not automatically create the # snapshot_root directory. This is particularly useful if you are backing # up to removable media, such as a FireWire drive. # no_create_root 1
Diese Option war eigentlich richtig gesetzt. Sie verhindert nämlich, dass RSnapshot ein Backup auslöst, wenn das definierte Backup-Verzeichnis im System gar nicht vorhanden ist. Mein Problem war nun folgendes:
# All snapshots will be stored under this root directory. # snapshot_root /media/backups
Da ich ja das Verzeichnis /media/backups im System angelegt habe, ist es natürlich immer vorhanden!
Fall A: Die Platte ist gemountet - das Backup wird auf die externe Festplatte nach /media/backups ausgeführt.
Fall B: Die Platte ist nicht gemountet - das Backup wird auf /media/backups auf meiner Root-Partition ausgeführt.
Also wurde das Backup nachts um 3 Uhr normal gestartet - nur halt auf meine Root-Partition anstatt auf die externe Festplatte, da diese ja gar nicht gemountet war. Da / aber nur 10 GB Speicherplatz hat, war es im Nu vollständig zugemüllt - das System wurde mit 99% Speicherplatzauslastung instabil und funktionierte nicht mehr richtig.
Um dies zu beheben, muss snapshot_root einfach auf ein Verzeichnis zeigen, das auf der Partition / nicht vorhanden ist. Dann startet RSnapshot das Backup nicht, wenn no_create_root (so wie oben) an ist.
Achtung: Für die nächsten Befehle ist es wichtig, dass kein RSnapshot-Backup läuft oder gerade ausgelöst wird!
Wir machen folgendes - erst einmal die Platte normal mounten:
fish@fishbox:~$ sudo mount /media/backups
Nun erstellen wir ein neues Verzeichnis:
fish@fishbox:~$ cd /media/backups fish@fishbox:/media/backups$ ls daily.0 daily.1 daily.2 daily.3 fish@fishbox:/media/backups$ mkdir localhost
(wie Sie es nennen, ist egal)
Wie man oben sehen kann, wurden bisher vier Sicherungen gemacht. Diese verschieben wir alle ins neu erstellte Verzeichnis:
sudo mv /media/backups/daily.* /media/backups/localhost
Nun ändern wir in der Datei /etc/rsnapshot.conf den Eintrag snapshot_root in:
# All snapshots will be stored under this root directory. # snapshot_root /media/backups/localhost
Wir testen diese Änderung - zuerst binden wir unsere externe Festplatte aus dem System aus:
fish@fishbox:/$ sudo umount /media/backups
In /media/backups ist nun nichts mehr gemountet, demzufolge gibt es auch kein /media/backups/localhost.
Lösen wir nun ein Backup manuell aus, sollte RSnapshot den Dienst eigentlich verweigern:
fish@fishbox:/media/backups$ sudo rsnapshot -V daily ---------------------------------------------------------------------------- rsnapshot encountered an error! The program was invoked with these options: /usr/local/bin/rsnapshot -V daily ---------------------------------------------------------------------------- ERROR: /media/backups/localhost does not exist. ERROR: rsnapshot refuses to create snapshot_root when no_create_root is enabled /usr/bin/logger -i -p user.err -t rsnapshot /usr/local/bin/rsnapshot -V \ daily: ERROR: rsnapshot refuses to create snapshot_root when \ no_create_root is enabled
Ja! RSnapshot hat also erkannt, dass die Festplatte nicht eingebunden ist, und hat darum auch keine Daten gesichert.
Wenn wir nun die Platte wieder mounten, können wir das Backup erfolgreich starten:
fish@fishbox:~$ sudo mount /media/backups fish@fishbox:/media/backups$ sudo rsnapshot -V daily fish@fishbox:/media/backups$ cd localhost fish@fishbox:/media/backups/localhost$ ls daily.0 daily.1 daily.2 daily.3 daily.4
Es hat geklappt!
Jetzt noch eine letzte kleine Änderung:
fish@fishbox:/media/backups$ ls -l total 4 drwxr-xr-x 9 fish fish 4096 2007-04-13 04:31 localhost
Wie man sieht, kann jeder Benutzer auf meinem Server auf das Verzeichnis localhost zugreifen.
Das ist zwar für meine kleines Home-Setup nicht weiter tragisch, trotzdem ist es sinnvoll, dies zu ändern:
fish@fishbox:/media/backups$ sudo chown root:root localhost fish@fishbox:/media/backups$ sudo chmod 0700 localhost fish@fishbox:/media/backups$ ls -l total 4 drwx------ 9 root root 4096 2007-04-13 04:31 localhost
So, nun passen auch die Rechte.
Unsere Sicherungen werden von jetzt an nur noch ausgelöst, wenn die externe USB-Platte auch eingebunden ist!
