Backup-Strategien

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:

  1. Evtl. Festplatte in server2 austauschen
  2. server2 mit einem sog. „live linux“ booten (z.B. „sysrescuecd“)
  3. Dort „cfdisk“ aufrufen und die Partitionen 1:1 so erstellen wie sie zuvor auf server2 waren UND formatieren (mkfs.ext3 /dev/hdaX)
  4. Jetzt wird das „system“ in einem abgesonderten Verzeichnis erstellt, und die neuen Partitionen darin gemountet:

[stextbox id=“warning“ caption=“Achtung“]Das folgende Beispiel geht von einem setup mit separaten Partitionen für / /boot, /home, /tmp, /usr, /var aus!)[/stextbox]

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

[stextbox id=“note“ caption=“Hinweis bei XFS Filesystemen“]
XFS erlaubt es standardmässig nicht mehrere Volumes mit derselben UUID zu mounten.
Da aber beim LVM Snapshot, die UUID ebenfalls repliziert wird, schlägt ein mount erstmal mit der Meldung:

# mount /dev/rootvg/home_snap
 mount: wrong fs type, bad option, bad superblock on /dev/rootvg/home_snap,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

fehl.

Im /var/log/messages findet man dann auch die Ursache dafür:

[ root@hostname ~ ]#  tail -f /var/log/messages
Oct 16 03:29:22 hostname kernel: XFS (/dev/rootvg/home_snap): Filesystem has duplicate UUID c4e2eef9-c744-4c64-8ebc-044373f84ddc - can't mount
Oct 16 03:29:27 hostname kernel: XFS (/dev/rootvg/home_snap): Filesystem has duplicate UUID c4e2eef9-c744-4c64-8ebc-044373f84ddc - can't mount

Damit das dann funktioniert, muss der snapshot einfach mit der Option -o nouuid gemounted werden:

 mount -o nouuid /dev/rootvg/home_snap /mnt/home-backup/

[/stextbox]

LVM-Snapshots im praktischen Einsatz

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

Quellen

)

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:





[stextbox id=“tip“ caption=“LVM-Snapshots im praktischen Einsatz“]

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

[/stextbox]





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:










Und gezippt:










Zurückgespielt wird das backup mittels:










bzw.:










Related Links









Quellen






0
 
 
	


	
	







	
	
		

		
Schreibe einen Kommentar 
Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert