Zusammenfassung:

Inhalt

• Einführung
• LVM
• RAID
  • Linux Software RAID
  • Software RAID vs. Hardware RAID
  
  
• Backups Allgemein
• Backup von Dateien
  • Incremental Backup
  
  
• Backup des Bootloaders
  • Hintergrund
  • Backup
  
  
• Backup von Partitionen
  • Sicherung mit dd
  
  
• Backup von kompletten Systemen
  • Beispiel Backup Szenario
  • Beispiel Restore Szenario
  
  
• Meine persönliche Erfahrung

Einführung

Bevor es ans Eingemachte geht, will ich gleich mal auf den wichtigste Leitsatz für Backups verweisen: Keep it simple! Das beste Backup-Tool bringt nämlich nichts, wenn es im Ernstfall nicht zur Verfügung steht, oder nicht funktioniert weil Konfigurationsdateien, Datenbanken etc. nicht mehr vorhanden sind, die es benötigt. Dann waren die ganzen Backups für die Katz.

Aus diesem Grund versuche ich immer alles mit den einfachsten Unix-Tools zu erledigen. Die wichtigsten Tools neben den Standardbefehlen ''cd, cp, etc.'' sind die Tools ''dd, tar und sfdisk''. Diese sind auf jeder Distribution wie z.B. Knoppix vorhanden und deswegen immer verfügbar. Außerdem sind sie so einfach gestrickt, dass sie keine besonderen Abhängigkeiten haben und deshalb auch zuverlässig funktionieren.

Schlaue Leitsätze gibt es natürlich noch mehr ;-)

• Keep it simple!
• Try to restore before you need to!
• Understand what you are doing!

Linux und andere Unix-Systeme haben eine sehr schöne Eigenschaft, die uns behilflich ist bei Backups. Alles ist eine Datei! Neben vielen anderen Vorteilen, hat das speziell für Backups einen entscheidenden Vorteil. Man braucht keine binären Images zu erstellen wie man es z.B. von Windows gewohnt ist, sondern kann einfach alle Dateien des Systems archivieren und wiederherstellen.

Images von Partitionen und Festplatten sind zwar auch bei Unix möglich, haben aber einen entscheidenden Nachteil gegenüber Backups auf Dateisystem-Ebene. Sie können ohne Probleme nur auf identische Festplatten restauriert werden. Bei unterschiedlicher Partitionierung wird es schwierig. Für ein einfaches Backup eines Desktop-Systems mag das ausreichen, aber nicht für Server. Die Festplattenkapazitäten steigen andauernd, deswegen ist es eher unwahrscheinlich, dass man ein Image später mal auf die identische Platte restauriert. Und was ist, wenn die neue Platte gar keine IDE-Platte mehr ist, sondern SATA oder SCSI?

Ein sichern der Daten auf Dateisystem-Ebene bietet den Vorteil, dass man ein System auch restaurieren kann auf

• unterschiedlicher Plattengeometrie
• unterschiedlicher Partitionierung
• neuen Festplattentypen
• und auf ganz andere Dateisysteme.

Kurz gesagt man löst dabei die Daten von der Physik. Und damit sind wir auch schon beim Grund-Prinzip von LVM (Logical Volume Manager).

LVM

LVM ist bereits gut dokumentiert im LVM-Howto, deswegen werde ich mich hier kurz halten. Eigentlich erwähne ich es nur, weil sich die Leute immer wieder fragen wie sie ein LVM-System sichern sollen, weil ihre Image-Software damit nicht funktioniert...

Auf PCs gibt es traditionell eine Einschränkung auf vier Partitionen. Diese Einschränkung wurde später erweitert indem man eine der vier Partitionen als so genannte Erweiterte Partition definiert in der sich wieder weitere Partitionen befinden können. Das Hinzufügen von Partitionen, das Ändern der Größe ohne Datenverlust oder das Zusammenfügen von zwei Partitionen ist nur mit spezieller Software wie z.B. Partition Magic möglich und benötigt normal einen Reboot und ist gerade deswegen sehr unpraktikabel.

Ein Server muss in der Lage sein im Betrieb geändert und erweitert zu werden. LVM abstrahiert Geräte und Partitionen zu rein logischen Begriffen wie Physical Device (PD), Volume Group (VG) und Logical Volume (LV). Physical Device ist wie es der Name schon sagt das ''physikalische Gerät'' und kann eine ganze Festplatte oder auch nur eine Partition auf einer Festplatte darstellen. Eine Volume Group ist schon ein rein logischer Begriff und ist so was wie eine Virtuelle Festplatte. Mehrere PDs können nun zusammen gefasst werden zu einer VG. Logical Volumes sind dann logische Partitionen. Eine VG kann sozusagen partitioniert werden in mehrere LVs. So ein LV kann jetzt wie eine herkömmliche Partition verwendet werden und man kann darin ein Dateisystem formatieren.

Eine VG über mehrere Festplatten funktioniert jetzt im Grunde wie ein RAID-0 System und verteilt die Daten physikalisch auf alle Platten um die Zugriffsgeschwindigkeit zu erhöhen.

Der große Vorteil ist jedoch, dass im Betrieb neue Festplatten und Partitionen hinzugefügt werden können und somit der verfügbare Speicherplatz erhöht werden kann. Nachdem die VG nun größer ist können auch die LVs wie gewünscht vergrößert werden. Man kann auch ein LV verkleinern und den frei gewordenen Platz einem anderen LV hinzufügen. Damit das ganze auch noch ohne unmount und remount das Dateisystems funktioniert sollte man ein Dateisystem wie ReiserFS verwenden, das ebenfalls im Betrieb, also während es gemountet ist vergrößert werden kann.

Man muss sich bei einem Linux-System das normal aus mehreren Partitionen besteht, bei der Installation mit LVM keine großen Gedanken mehr machen wie groß die Partitionen sein sollen, da es später jeder Zeit ohne Probleme geändert werden kann.
Noch ein Vorteil, der jetzt gerade für Backups interessant ist, ist die Snapshot Funktionalität. Man kann von jedem beliebigen LV einen Snapshot erstellen um ein konsistentes Backup im Betrieb zu ermöglichen. Dabei wird der Snapshot, ein eingefrorenes Abbild eines LVs gemountet, während das LV ganz normal weiter verwendet werden kann. Was im Hintergrund dabei passiert, kann im LVM-Howto nachgelesen werden.

Es sollte nun schon klar sein, dass ein Image eines LVM-Systems eigentlich gar keinen Sinn macht. Man sichert einfach die Daten auf Dateisystem Ebene. Bei einem Bare Metal Restore müssen die LVM PDs, VGs und LVs einfach neu angelegt und gemountet werden. Danach restauriert man die Dateien. Fertig.

Wie das am einfachsten gemacht wird sehen wir später im Kapitel Bare Metal Restore.

RAID

RAID hat eigentlich nichts mit Backups zu tun. Der Sinn (abgesehen von RAID0) ist es eine Redundanz zu schaffen, damit bei Hardware-Defekt die Daten nicht verloren gehen und die Down-Time zu minimieren. Bei Ausfall einer Platte ist die Funktionstüchtigkeit weiterhin gegeben und man kann die defekte Platte dann tauschen wenn dafür Zeit ist (abends, Wochenende).
Ist eine Platte ausgefallen ist keine Redundanz mehr gegeben, deswegen sollte man nicht zu lange mit dem Austausch warten. Man kann von vorn herein auch eine Sparedisk einbauen, die den Job automatisch übernimmt.
Ich will nicht weiter darauf eingehen, da RAID Systeme ausreichend dokumentiert sind, wichtig ist nur zu verstehen, das RAID zwar bei Hardware-Ausfall hilft, aber nicht bei versehentlichen/mutwilligen löschen. Für das Dateisystem ist ein RAID-Verbund einfach eine normal Festplatte. Wenn eine Datei gelöscht wird (durch Benutzer, Viren, Dateisystemfehler), ist sie weg. Da hilft auch kein RAID. Deswegen ist es wichtig immer auch ein Backup zu haben.
Genau wie für Backups gilt auch für RAID: Es bringt nur was wenn es im Ernstfall auch funktioniert und man weiß was zu tun ist. Deswegen unbedingt testen! Den Ausfall provozieren, die Überwachung verifizieren und das Ersetzen einer Festplatten durchspielen.

Linux Software RAID

Ist gut dokumentiert im Software RAID Howto, allerdings möchte ich hier noch einen Hinweis auf die Überwachung geben, da hier die Doku etwas knapper ist.
Der Status des RAID Verbundes kann einfach aus /proc/mdstat ausgelesen werden.

raidserver:~ # cat /proc/mdstat
Personalities : [raid5]
md0 : active raid5 sdd1[3] sdc1[2] sdb1[1] sda1[0]
      390684416 blocks level 5, 128k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Bei Ausfall einer Platte wird das entsprechende 'U' durch '_' ersetzt um den Ausfall zu kennzeichnen. Bei diesem RAID5-System mit drei aktiven Platten gibt es also die folgenden drei Möglichkeiten: [_UU], [U_U], oder [UU_].
Das lässt sich natürlich leicht mit einer Regular Expression überprüfen. Nachfolgend ist ein Beispiel eines Cronjobs der den Zustand stündlich überprüft und bei Fehler das Script notify_raid_failure.sh ausführt.

0 * * * * root  test -r /proc/mdstat && grep -q '\[_\|\[U_\|\[UU_' /proc/mdstat && /root/notify_raid_failure.sh

Erklärung:

• test -r /proc/mdstat: Überprüft ob die Datei überhaupt vorhanden und lesbar ist.
• grep -q '\[_\|\[U_\|\[UU_' /proc/mdstat: Überprüft mittels RegEx ob eine Platte ausgefallen ist.
• /root/notify_raid_failure.sh: Sendet eine E-Mail an den Administrator

Nachfolgend ist ein Beispiel Script wie so eine Nachricht mittels Windows Popup-Message und E-Mail gesendet werden kann.

#!/bin/sh
# CONFIG START
# Users to notify via SMB Popup
SMBUsers="user1 user2"
# Acounts to send a notification mail to
Users="admin@acme.com chief@acme.com"
FROM="root@localhost"
# CONFIG END
# don't modify below this line

cd /root
# create message
echo RAID disk failure > msg.txt
echo >> msg.txt
cat /proc/mdstat >> msg.txt

# send message via SMB
for User in $SMBUsers
do
  cat msg.txt | smbclient -M $User
done

# send message via mail
for TO in $Users
do
  /usr/bin/mail -s "RAID disk failure (`/bin/date +\%Y.\%m.\%d-\%H:\%M`)" $TO < /proc/mdstat
done

Software RAID vs. Hardware RAID

Es gibt immer noch Vorurteile gegenüber Software RAID. Zu dem Thema muss ich nochwas los werden.

• Ein paar Windows 'Experten' wollten mich mal davon überzeugen, dass es viel besser sei Hardware RAID zu verwenden, da dies stabiler sei. Natürlich gibt es Treiber vom Hersteller meistens nur für Windows, blabla... Die alte Diskusion. Windows ist äh viel besser...
  Was die Jungs, die außer der Oberfläche wieder nichts kapieren, nicht wissen ist folgendes. Die schönen IDE-RAID Karten die es zu kaufen gibt, machen kein Hardware RAID. Im RAID-BIOS kann man zwar rum konfigurieren und RAID Verbunde anlegen, aber die RAID Funktionalität wird vom Windows-Treiber erledigt. Also auch Software RAID und das unter Windows... Viel Spaß ;-)
• Software RAID im Linux Kernel ist absolut stabil und wird auch in unternehmenskritischen Bereichen erfolgreich eingesetzt.
• Software RAID bietet eine Reihe von Möglichkeiten wie einfache Überwachung, Simulation von Gerätefehlern zum Testen, Hotswapfähigkeit (wenn die Hardware es kann, eigentlich nur bei SCSI möglich), Rebuild im Hintergrund während das System voll einsatzfähig ist.
• Auch das Booten funktioniert einwandfrei von RAID, was in der Anfangszeit noch etwas schwierig war. Aber eigentlich habe ich mein System nie auf RAID, nur die Daten. Wer's braucht...
• Software RAID ist Open Source und hat damit vermutlich auch weniger Bugs wie ein proprietärer Windows Treiber.
• Software RAID mit IDE oder SATA ist auf jeden Fall der Preis Sieger.

Wer trotzdem lieber Hardware hat, kann das natürlich auch unter Linux machen. Man sollte nur vorher schauen welche Controller auch unterstützt werden, bevor man einen kauft. Und wenn man schon RAID macht, dann bitte nicht mit einem EXPERIMENTAL Treiber. Das widerspricht sich doch ;-) Bei SCSI macht Hardware dann auch Sinn. So Hotswap fähiges SCSI ist schon was schönes...

Backups Allgemein

Unabhängig davon wie man Backups nun technisch durchführt gibt es für mich 2 Arten von Backups.

1. Daten-Backups
2. System-Backups

Daten-Backups gehen vom gelegentlichen Packen von Dateien und Brennen auf eine CD bis hin zum vollautomatischen und inkrementellen Backup von wichtigen Geschäftsdaten. Typische Daten sind E-Mails, Daten von Netzlaufwerken welche via SAMBA oder NFS zur Verfügung gestellt werden und Source Code Repositories wie SVN und CVS.

System-Backups macht man um im Ernstfall ein System schnell wieder aufsetzen zu können, ohne neu installieren zu müssen. Dazu gehören alle Systemdateien, Programme und Programmkonfigurationen. Ein System-Backup macht man normal nur nach der Installation oder nach einer Änderung am System. Die Daten gehören normal aber nicht dazu, da diese über ein getrenntes Datenbackup aktuell gehalten werden.

Beispiel Mailserver: Ich verwende einen Mailserver auf Linux Basis. Der Postfix MTA ist für die Mailzustellung verantwortlich, fetchmail holt die Dateien von externen Mailserver, lokal werden die Mails dem Cyrus IMAP Server zugestellt. Die User-Account-Verwaltung wird mittels MySQL Datenbank erledigt. Der Cyrus IMAP Server speichert jede Mail als Datei in einem Spool Verzeichnis, indiziert die Mails aber ebenfalls über eine spezielle Berkeley Datenbank.
Ins System-Backup kommt nun natürlich das gesamte Betriebssystem, die installierten Programme und deren Konfigurations-Dateien (die befinden sich bei Linux sowieso einfach im Verzeichnis /etc).
Ins Daten-Backup kommen die MySQL- und Berkeley-Datenbanken und das Mail-Spool Verzeichnis mit den enthaltenen E-Mails.

Comming Soon: Tipps zum Backup von Cyrus Mail Server werde ich nochmal extra schreiben, da es hier noch ein paar spezielle Fallstricke gibt.

Backup von Dateien

Dateien zu archivieren ist einfach. Typischerweise verwendet man tar oder ein äquivalentes Programm um mehrere Dateien und Verzeichnisse zu archivieren. Früher wurden Backups meist mittels Streamer gespeichert, da Festplatten einfach zu klein und zu teuer waren. Auch tar wurde ursprünglich dafür entwickelt. Üblicherweise arbeitet man dabei mit dem Gerät /dev/tape. Hat man also einen Streamer, z.B. einen SCSI Streamer sollte man den einen symbolischen Link auf /dev/nst0 anlegen.

ln -s /dev/nst0 /dev/tape

Dann kann man mittels mt und tar sehr einfach auf Streamer archivieren.

# band zurück spulen
mt rewind
# Daten archivieren (z.B /home)
tar -cvjf /dev/tape /home

Auf Streamern gibt es kein Dateisystem, man muss also wissen auf welchem Band, an welcher Position sich was befindet.

Wenn man unbedingt mit Streamer arbeiten will, sollte man sich Software AMANDA (http://www.amanda.org) anschauen. Diese übernimmt die komplette Verwaltung der Daten und Bänder. AMANDA verwaltet eine Datenbank mit deren Hilfe man seine Dateien auf den Bändern wieder findet. Man kann damit beliebige Dateien per Namen und Datum suchen und wiederherstellen.
Wie schon in der Einführung erwähnt halte ich von so komplexen Lösungen nicht viel, weil sie zu anfällig sind. Man braucht erstens ein Not-System auf dem die Amanda Software läuft, in dem ein Streamer eingebaut ist um die Bänder zu lesen, und die Datenbank welche die Bänder verwaltet. Ist die Datenbank verloren sind auch die Daten auf der Datenbank mehr oder weniger nutzlos.

Incremental Backup

Heutzutage sind Festplatten so groß und günstig geworden, dass es keinen Sinn mehr macht Streamer zu verwenden. Man archiviert einfach auf Festplatten. Dies bietet außerdem bessere Flexibilität und mehr Geschwindigkeit. Die Zeiten in denen man noch das richtige Streamer Band suchen musste, oder umständlich Daten von mehreren Bändern zusammensuchen musste sind damit endlich vorbei.

Ich verwende für tägliche Backups auf Festplatte eine Kombination von rsync und cp.

Comming soon: Inkrementelles Backup mit rsync und cp. Absolut genial.

Backup des Bootloaders

Hintergrund

Wer weiß was ein MBR ist und wie sein Bootloader funktioniert kann gleich zum nächsten Punkt übergehen.
Üblicherweise befindet sich der Bootloader im MBR (Master Boot Record) der ersten Festplatte. Der Code im MBR wird vom BIOS (Basic Input Output System) gestartet, nachdem das BIOS alle Systemchecks abgeschlossen hat, und ist sozusagen der erste Maschinencode der von Festplatte geladen wird. Die Aufgabe des Bootloaders ist es nun das Betriebssystem zu laden.
Der MBR befindet sich im ersten Sektor der Festplatte und ist 512 Byte groß. Nur die ersten 446 Byte davon enthalten den Boot Code, im Rest steht Partitionstabelle der Festplatte.
Die Möglichkeiten des Bootloaders sind durch die Begrenzung auf 446 Byte sehr limitiert, und von einem Dateisystem weiß er deshalb noch nichts. Bei LiLo (Linux Loader) war es deshalb üblich, das die Adresse der Linux Kernels direkt als Sektor-Adresse im MBR gespeichert wurde. So kann LiLo ohne Wissen über Dateisysteme den Kernel laden. Das hat allerdings den Nachteil das bei jeder Änderung des Kernels, bei der sich die genaue Adresse meistens ändert, nochmals das Kommando lilo (LiLo Installation) ausgeführt werden muss, damit der MBR wieder weiß von wo er den Kernel laden kann.
GRUB (Grand Unified Bootlader) ist da etwas cleverer. Diese Loader kann auf Dateisysteminformationen (ext2, reiserfs, ...) zugreifen um den Kernel und seine Konfigurationsdatei zu finden. Deswegen ist keine Neuinstallation nach Änderung eines Kernels oder der Boot-Konfiguration notwendig. GRUB hat drei Boot-Phasen.

• Stage1: Code im MBR
• Stage1.5: Code nach dem MBR
• Stage2: Der eigentliche Bootmanager

Da es auch bei GRUB nicht möglich ist den gesamten Code im MBR unterzubringen gibt es ein mehrstufiges Konzept. Stage1 lädt nur Stage1.5 nach. Stage1.5 enthält den nötigen Code für das Dateisystem in dem sich Stage2 befindet, so kann Stage1.5 nun Stage2 nachladen und ausführen. Stage2 beinhaltet nun den eigentlichen Bootmanager und kann auf alle Dateisysteme zugreifen.
Bei der Installation überprüft GRUB das Dateisystem in dem sich Stage2 befindet und erzeugt ein Stage1.5 Programm welches nur dieses Dateisystem versteht und speichert es in den 30KByte hinter dem MBR. Stage1 referenziert Stage1.5 auch nur per Sektor. Die Position von Stage1.5 ändert sich normal jedoch nicht.

Bitte korrigiert mich hier an der Stelle falls ich was falsches sage, aber so habe ich das Prinzip von GRUB verstanden.

Backup

Am einfachsten kann der MBR natürlich mit dd gesichert und wiederhergestellt werden. Den Boot-Sektor der ersten IDE Platte kann man z.B. in einer Datei hda.mbr sichern:

dd if=/dev/hda of=/mnt/hda.mbr bs=512 count=1

Restaurieren geht genauso:

dd if=/mnt/hda.mbr of=/dev/hda bs=512 count=1

Will man nur den Bootloader sichern ohne die Partitionstabelle kann man einfach nur die ersten 446 Byte sichern. dd if=/dev/hda of=/mnt/hda.mbr bs=446 count=1

Wer die Hintergrundinformationen gelesen hat weiß aber, dass das ganze nur funktioniert, wenn sich der Rest des Dateisystems nicht geändert hat. Also macht das nur Sinn um auf der selben Platte einen Bootmanager zu restaurieren, der vielleicht versehentlich gelöscht wurde.
Bei einem Bare Metal Restore auf eine neue Platte oder beim Klonen von Rechnern bringt das also nichts. Lilo würde den Kernel nämlich nicht mehr finden. Selbst bei GRUB würde das nicht funktionieren, da Stage1 dann Stage1.5 nicht mehr finden würde.
Bevor man sich jetzt Gedanken macht wie man mit dd auch noch Stage1.5 sichert, sollte man lieber einfach den Bootloader neu installieren. Das geht sowohl mit LiLo als auch mit GRUB ganz einfach wie wir im nächsten Kapitel noch sehen werden.

Backup von Partitionen

Manchmal ist es nützlich eine Partition binär zu sichern. So kann man z.B. auch Windows Systeme oder einfach nur seinen USB-Sticks sichern. Damit man später die Images auch wieder einspielen kann ist es sinnvoll auch die Partitionierung zu sichern. Andernfalls stimmt später die Partitionsgröße eventuell nicht mehr.
Wie wir die Partitionstabelle sichern können, haben wir schon im vorigen Kapitel gesehen, aber was ist mit erweiterten Partitionen? Dafür kann man das Tool sfdisk verwenden.

# Die Partitionierung sichern
sfdisk -d /dev/hda > /mnt/backup/hda.sfdisk
# Die Partitionierung wiederherstellen
sfdisk /dev/hda < /mnt/backup/hda.sfdisk

dd, dump, partimage, tar, ... TODO

Sicherung mit dd

Mittels dd kann man sehr einfach jede Partition binär sichern. Dabei darf die Partition selbstverständlich nicht gemountet sein.

dd if=/dev/hda1 of=/mnt/backup/backup.img

Mittels gzip und split lassen sich die Daten noch komprimieren und in handliche Pakete aufteilen.

dd if=/dev/hda1 | gzip -c | split -b 2000m - /mnt/backup/backup.img.gz.

Dieses Vorgehen bietet den Vorteil, dass es unabhängig vom Dateisystem eine exakte binäre Kopie erstellt, da wir direkt auf das Gerät zugreifen. Der Haken an der Sache ist aber, dass wir dadurch auch sämtliche ungenutzte Bereiche der Partition mit kopieren. Für große Partitionen ist dieses Vorgehen deswegen eher unpraktikabel. Mit einem kleine Trick kann man die Sache wenigsten etwas optimieren. Man kann vorher eine Dummy-Datei anlegen welche den gesamten ungenützten Speicher aufbraucht und nur Nullen enthält. So lässt sich das Image besser komprimieren und man spart Speicherplatz. Auch hierfür ist dd wieder das richtige Werkzeug.

# dummy Datei mit Nullen anlegen
mount /dev/hda1 /mnt/hda1
dd if=/dev/zero of=/mnt/hda1/dummy
umount /dev/hda1
# Das image erzegen
dd if=/dev/hda1 | gzip -c | split -b 2000m - /mnt/backup/backup.img.gz.
# dummy Datei wieder entfernen
mount /dev/hda1 /mnt/hda1
rm /mnt/hda1/dummy
umount /dev/hda1

Backup von kompletten Systemen

Danke dem Unix Prinzip 'Alles ist eine Datei' würde es prinzipiell einfach ausreichen das gesamte System mittels tar zu sichern. In etwa so:

tar -cvjf system-backup-`date -I`.tar.bz2 /

Allerdings will man ja nicht unnötige Dateien sichern, da dies Zeit und Speicherplatz verschwenden würde. Deswegen sollte man alle unnötigen Dateien vom Backup ausklammern. Folgende Tabelle enthält typische Verzeichnisse die normal nicht gesichert werden müssen.

Man kann tar mittels einigen --exclude=MUSTER Parametern mitteilen welche Dateien ausgelassen werden sollen, was allerdings etwas unpraktisch ist. Einfacher ist es diese Liste in eine Datei zu schreiben und tar mittels --exclude-from=FILE aufzufrufen.

Anstatt als Muster nur /proc anzugeben, sollte man /proc/* angeben, damit wird der Ordner mit gesichert, aber nicht der Inhalt. So erspart man sich später beim Restore die Ordner neu anzulegen.

/path/to/exclude.txt:

/proc/*
/mnt/*
/sys/*
/tmp/*
/var/tmp/*
/var/log/*
*.~
*.bak
*.o
.thumbnails

Beispiel Backup Szenario

Es soll ein einfaches Gentoo System gesichert werden welches folgende Partitionierung aufweist.

device	Filesystem	Mountpoint
/dev/hda1	ext2	/boot
/dev/hda2	swap	swap
/dev/hda3	ext3	/

Die Swap Partition muss selbstverständlich nicht mit gesichert werden. Das Backup kann auf einer zweite Festplatte oder via NFS auf einen anderen Server im Netzwerk gesichert werden. In diesem Beispiel verwende ich eine Wechselfestplatte, welche als Master am zweiten IDE Controller arbeitet.

Um ein konsistentes Backup zu ermöglichen sollte man von einer Boot CD ( Knoppix, Gentoo Boot CD, etc. ) booten oder zumindest in den Single-User Mode wechseln (init 1) und die Dateisysteme ReadOnly mounten.

Da ich gerne Gentoo verwende boote ich einfach von der Gentoo Boot CD. Die weiteren Schritte sind hier exemplarisch dargestellt und kommentiert. Diese müssen natürlich an die jeweilige Situation angepasst werden.

# mount root file system read only
mount -o ro /dev/hda3 /mnt/gentoo
# mount /boot file system read only
mount -o ro /dev/hda1 /mnt/gentoo/boot
# create backup mountpoint
mkdir /mnt/backup
# mount backup file system
mount /dev/hdc1 /mnt/backup
# cd into your root file system
cd /mnt/gentoo
# do the backup
tar -cvjf /mnt/backup/backup-datum.tar.bz2 --exclude-from=./root/exclude.txt .

Beispiel Restore Szenario

Wie beim Backup boote ich wieder die Gentoo Boot CD. Restauriert man auf eine neue Platte müssen zuerst noch die nötigen Partitionen und Dateisysteme angelegt werden.

# fdisk starten und Partitionen anlegen
fdisk
# Dateisysteme formatieren
mkfs.ext2 /dev/hda1
mkswap /dev/hda2
mkfs.ext3 /dev/hda3

Ansonsten kann man direkt mit der Restauration beginnen.

# mount root file system
mount /dev/hda3 /mnt/gentoo
# create /boot mountpoint
mkdir /mnt/gentoo/boot
# mount /boot file system
mount /dev/hda1 /mnt/gentoo/boot
# create backup mountpoint
mkdir /mnt/backup
# mount backup file system
mount /dev/hdc1 /mnt/backup
# cd into your root file system
cd /mnt/gentoo
# restore the system data
tar -xvjf /mnt/backup/backup-datum.tar.bz2 
# mount /proc file system
mount -t proc none /mnt/gentoo/proc 
# bind current /dev file system into our restored system
mount -o bind /dev /mnt/gentoo/dev
# enter the system with chroot
chroot /mnt/gentoo /bin/bash
# reinstall boot loader
grub-install
# Gentoo users are syncing the portage tree now.
emerge --sync

Meine persönliche Erfahrung

Ich habe schon mit den verschiedensten Backuplösungen sowohl unter Windows als auch unter Linux gearbeitet. Dabei waren verschiedene Produkte um Images zu erzeugen bis hin zu komplexer Software welche mit Streamern arbeitet. Die Erfahrung hat gezeigt, dass am zuverlässigsten die einfachsten Lösungen sind, die man selber versteht und deren Mittel immer und überall zur Verfügung stehen.
Das ist natürlich nur meine Meinung und es gibt bestimmt auch Argumente für andere Lösungen. Ich hoffe aber, dass dieser Artikel trotzdem hilfreich war.
Über Feedback würde ich mich freuen.

---

2007-03-18