Backups werden immer wichtiger. Deshalb möchte ich hier backup Strategeien für Windows, sowie für Linux Systeme vorstellen.
Inhalt
Backup von Windows-Systemen
robocopy
Robocopy ist ähnlich wie rsync für Linux ein exzellentes tool um grosse Datenmengen zu kopieren!
Ein Backup kann man mit Robocopy beispielsweise so machen:
robocopy H: B:\BACKUPS\homedrive /MIR /TEE /LOG:B:logsbackup.log |
Der Parameter /MIR gibt dabei an, dass ein „Ebenbild“ (mirror) auf dem Zielverzeichnis entstehen soll, /TEE (optional) in Verbindung mit /LOG (optional) zeigt das Konsolenfenster an, während gleichzeitig alles in ein logfile geschrieben wird. -Dieses logfile sollte man zusätzlich regelmässig kontrollieren, ob das Backup noch sauber durchläuft!
Wenn man das Windows-Profil backuppen will, muss man zusätzlich noch einige file-typen weg lassen:
robocopy C:\profiles\ B:\BACKUPS\profiles\ /MIR /R:3 /W:10 /XF .dat .dat.log .exe .dll .tmp .ocx .xvd .class .lock .cch.* /XD "C:\profiles\%username%\Lokale Einstellungen\Temp\" /TEE /LOG+:B:logsbackup.log |
Der Parameter /R:3 gibt an, dass maximal 3 mal versucht werden soll die Datei zu kopieren, /W:10, dass pro Versuch 10s gewartet werden soll (sonst kann es bei nicht lesbaren Files zu einer fast-endlos schleife kommen!), /XF schliesst gewisse nicht-kopierbare Files aus und /XD tut dasselbe mit den Verzeichnissen.
Die parameter /TEE und /LOG kennen wir hier schon; einziger unterschied ist das ‚+‘ nach /LOG; dieses bewirkt, dass nicht immer ein neues logfile erstellt wird, sondern das log angehängt wird.
Backup von Linux Systemen
rsync
Wenn man zwei Server und genügend Platz hat ist die beste Lösung ein rsync-images des ganzen root-Verzeichnissbaums (/) auf dem zweiten Server zu machen; fällt so eine Platte aus, kann man diese relativ unkompliziert wieder zurückspielen; ist also sozusagen eine Art „remote-raid1“ 😉
Im folgenden Beispiel ist:
server1: Der Server auf dem das Backup liegt
server2: Der Server der gesichert wird
So gehts:
Auf dem Server, auf dem die Backups abgelegt sind (server1) folgendes Script anlegen:
/opt/scripts/backup.sh
WHICH="/usr/bin/which" CHMOD=$($WHICH chmod) RSYNC="$($WHICH rsync) --rsh=$($WHICH ssh)" TAR=$($WHICH tar) ### SERVER 2 ### # System sync $RSYNC -av --numeric-ids --delete --delete-excluded --exclude-from=/etc/rsync-excludes root@server2:/ /backup/sysimage/server2/ >> /var/log/server2_rsync.log 2>> /var/log/server2_rsync.err |
Das ist im Prinzip schon alles! -Jetzt müssen wir auf server1 nur noch die Verzeichnisse und das exclude-file anlegen:
mkdir -p /backup/sysimage/server2/ |
/etc/rsync-excludes
/proc/* /sys/* |
(/proc und /sys sind spezielle Verzeichnisse und müssen/sollten nicht gesichert werden!)
Nun noch einen Cronjob machen, der das Backup täglich ausführt:
crontab -e
# Backup 30 3 * /opt/scripts/backup.sh |
Sicherung zurückspielen
Nun, da wir ein volles Backup haben können wir im falle eines Plattencrashses ganz einfach das Image zurück spielen!
Folgende Schritte sind dafür aber nötig:
- Evtl. Festplatte in server2 austauschen
- server2 mit einem sog. „live linux“ booten (z.B. „sysrescuecd“)
- Dort „cfdisk“ aufrufen und die Partitionen 1:1 so erstellen wie sie zuvor auf server2 waren UND formatieren (mkfs.ext3 /dev/hdaX)
- Jetzt wird das „system“ in einem abgesonderten Verzeichnis erstellt, und die neuen Partitionen darin gemountet:

mkdir /mnt/system mount /dev/hda1 /mnt/system mkdir -p /mnt/system/{boot,tmp,var,usr,home,proc} mount /dev/hda1 /mnt/system mount /dev/hda2 /mnt/system/boot mount /dev/hda3 /mnt/system/tmp mount /dev/hda5 /mnt/system/home mount /dev/hda6 /mnt/system/usr mount /dev/hda7 /mnt/system/var mount -t proc proc /mnt/system/proc |
Nun stellen wir sicher dass auf server2 per ssh zugegriffen werden kann; im Falle von „sysrescuecd“ muss man den sshd starten und mit passwd ein root-passwort vergeben.
Auf server1 eingelogt nun das backup wieder mit rsync zurückspielen:
rsync -av --numeric-ids --exclude-from=/etc/rsync-excludes /backup/sysimage/server2/ root@server2:/mnt/system/ |
Nun können wir uns in dieses system „chrooten“.
Auf server2 muss man dazu noch folgendes eingeben:
chroot /mnt/system |
Hier muss dann nur noch der Bootloader wieder installiert werden, z.B. im Falle von grub:
grub-install /dev/hda |
Nun kann man den chroot verlassen, unmounten und neustarten: Das System müsste wieder den ursprungszustand haben! 😉
exit umount /mnt/system* reboot |
tar auf lokalem System
Will man auf dem lokalen System ein Backup in ein tar.gz Archiv machen, geht das folgendermassen:
cd / tar -cvpzf /srv/backup/$(hostname).tgz --exclude=/srv/backup/$(hostname).tgz --exclude=/proc --exclude=/dev --exclude=/sys --exclude=/run / |
Hinweis: Das cd /
zu beginn ist wichtig, da sonst die Verzeichnis refferenzen der excludes nicht mehr stimmen!
Mit exclude werden das backup selbst, sowie einige Verzeichnisse, welche nicht gesichert werden sollen (z.B: /proc) ausgenommen.
Das -p flag („preseve“) behält die Datei-Berechtigungen.
Festplatten-Image erstellen
Manchmal ist es am besten man erstellt sich gleich ein ganze Image der Festplatte; dieses kann dann denkbar einfach wieder zurückgespielt werden:
Image erstellen
dd if=/dev/hda | gzip -c | cat > image.gz |
Image zurückspielen
gzip -d -c image.gz | dd of=/dev/hda |
Oder das ganze direkt remote auf einen Backupserver
dd if=/dev/hda | gzip -c | ssh user@server "cat > image.gz" |
ssh user@server "gzip -d -c image.gz" | dd of=/dev/hda |
Status anzeigen
Während dem Kopiervorgang kann man sich auch einen Status anzeigen lassen, indem man auf dem Zielsystem folgendes eingibt:
kill -USR1 $(pgrep '^dd$') |
Die Ausgabe erfolgt dabei auf der Konsole vom Quellsystem.
LVM-Snapshots
LVM-Snapshots eignen sich hervorragend um online-Backups (d.H. im laufenden Betrieb) von Daten zu machen die sich häufig ändern und so beim blossen kopieren korrupt werden könnten, wie das z.B. bei Datenbank-, oder Mailservern der Fall ist.
Ein „LVM-Snapshot“ erstellt eine 1:1 kopie eines laufenen LogicalVolumes genau in zu der Zeit wo man es ausführt.
Dabei werden nur die Daten die sich auf dem originalen LV ändern tatsächlich auf dem snapshot gespeichert, die anderen files darauf referenzieren auf das original LV, benötigen also keienn Platz.
Daher muss das snapshot LV nicht gleich gross sein, wie das originale, nur so gross um die Änderungen zu speichern während der Lebenszeit des snapshots. – Für backup zwecke reichen deshalb sogar wenige GB. Will man das volume jedoch dauerhaft laufen lassen (z.B. für tests), so sollte es gleich gross sein, wie das Originale.
Die Grösse lässt sich nebst einer festen grösse mit dem -L (–size) Parameter auch als Prozentuale Grösse des bisherigen Volumes Angeben. Damit benutzt man den -l (–extents) Parameter mit dem Zusatz: %ORIGIN (siehe Beispiel unten).
Das Backup geht dann sehr einfach:
# Snapshot erstellen lvcreate -l 100%ORIGIN -s -n home_snap /dev/rootvg/home # Snapshot Mounten mkdir /mnt/home-backup mount /dev/rootvg/home_snap /mnt/home-backup/ # Backup erstellen # z.B. rsync -ahv /mnt/dbbackup/ /srv/backup/db/ # Snapshot unmeounten umount /mnt/home-backup rmdir /mnt/home-backup # Snapshot wieder entfernen lvremove -f /dev/rootvg/home_snap |

Ein praktisches Beispiel wäre folgendes Szenario:
Man hat einen Webserver mit dynamischen Seiten und eine MySQL-Datenbank.
Sichert man nun zuerst die Dateien im Web-Verzeichnis und dann die Datenbank (oder umgekehrt), könnte der Stand des Dateisystems nicht mehr der Datenbank entsprechen. Dies passiert z.B. wenn jemand ein Bild hoch lädt, die Datei zwar im Web-Verzeichnis abgelegt wird und die Informationen dazu (Titel, Beschreibung, Pfad, usw.) in der Datenbank gespeichert sind.
Eine Stratgeie um dieses Problem zu lösen wäre z.B. vor dem backup den Webserver (z.b. apache) zu stoppen, die Backups zu machen und den Webserver wieder zu starten. – Da jedoch üblicherweise das kopieren von vielen Dateien vier mehr Zeit in Anspruch nimmt, als das dumpen der Datenbank, hätte man eine entsprechend hohe downtime.
Mittels eines LVM snapshots kann man unmittelbar nach dem Datenbank dump den Webserver wieder starten und die Dateien in aller ruhe sichern:
Webserver stoppen -> LVM snapshot erstellen -> Datenbank sichern -> Webserver starten -> Dateien vom snapshot sichern
Um Platzprobleme zu vermeiden sollte man die Grösse des Snapshot-Volumes gleich gross machen wie das Original.
Backup von Datenbanken
mysql
Um mysql Datenabnken zu sichern, kann man mysqldump benutzen:
mysqldump -u [user] -p [datenbank] > db_backup.sql |
Und gezippt:
mysqldump -u [user] -p[passwort] [datenbank] | gzip > [db_backup.sql.gz] |
Zurückgespielt wird das backup mittels:
mysql -u [user] -p [datenbank] < [db_backup.sql] |
bzw.:
gunzip < [db_backup.sql.gz] | mysql -u [user] -p [datenbank] |
Related Links
- linux-magazin.de: Eine tolle Backup Lösung von linux-magazin um das ganze System zu sichern
- Image-Erstellung mit dd: Sehr guet Beschreibung diverses Backup-Möglichkeiten mit dd
- Using LVM for MySQL Backup and Replication Setup: Eine sehr gute Beschreibung vom „MySQL Performance Blog“
- How to Back Up and Restore a MySQL Database: Schnelle Übersicht über die mysql Backup Möglichkeiten
- thomas-krenn.com: LVM Snapshots
- tldp.org: Taking a Backup Using Snapshots