Disaster Recovery for Linux 2.0
From SEPsesam
SEP Sesam Linux BSR Restore
Einleitung
Das folgende Dokument beschreibt die Vorgehensweise für einen Linux BSR Disaster Restore.
Im dargestellten Beispiel wird der Restore eines 32 Bit Suse Linux Enterprise Server gezeigt.
Der Restore eines Clientsystems wird über die Linux BSR Live-CD vorgenommen welche einen SEP Sesam Clienten beinhaltet. Dieser Client wird als normales Clientsystem im SEP Sesam Server aufgenommen. Nach erfolgreicher Aufnahme des Clienten am SEP Sesam Server kann mit dem BSR Disaster Restore begonnen werden.
Unterstützte Distributionen und Filesysteme
Distributionen
- SLES 10
- SLES 11
- RHEL 5
- Debian
Filesysteme
- reiserfs
- ext2
- ext3
- xfs
Systemvorraussetzungen
- SEP sesam Server ab Version 3.6.4.6
- SEP sesam Klient ab Version 3.6.4.6
- SEP Sesam BSR CD Image für die richtige Architektur (SLES 11, Download)
- Identisches Zielsystem für einen Restore
| Achtung |
|
Die Festplatte muss gleich- oder grösser zum alten System sein! |
SAN Devices
| Achtung |
|
Existieren am zu sichernden system SAN Devices die sichtbar sind, so wird auch das Partitionslayout der SAN Devices während des Backups gesichert. Sind diese SAN Devices während des Restores auch am System sichtbar, so werden auch hier die entsprechenden Recoveryoperationen durchgeführt. Ist dies nicht gewünscht, so ist darauf zu achten dass diese Disk Devices während des Restore Vorganges nicht am System verfügbar sind. |
Einrichten einer SEP BSR Sicherung
Nachdem der zu sichernde Server am Sesam Server als Klient aufgenommen wurde, müssen folgende Sicherungen durchgeführt werden:
- Save-Set des Clientsystems das eine "disk_info" Sicherung enthält.
Hierbei werden sämtliche Partitionsinformationen gesichert (Normale Partitionen, LVM Volumes und SoftRAID).
- Save-Set des Clientsystems das eine "all" Sicherunge enhält (Komplettsicherung des Systems).
Vorgehensweise bei Restore
Boot der SEP SESAM BSR Live CD
Bootmenü
Nach einlegen der CD erscheint die Grafische Bootmenüauswahl. Hier wird er Eintrag SEP Sesam Live client nox gewählt.
Netzwerkkonfiguration
Anschließend startet das Live-CD System und die YAST2 Konfiguration des Netzwerkes kann vorgenommen werden. Während des ersten Bootvorganges wir der SEP Sesam BSR Client in die Live-CD Ramdisk installiert.
Dies kann unter Umständen etwas Zeit in Anspruch nehmen. In diesem Beispiel wird der SEP Sesam Client mit dem Hostnamen "recover.sep.de", mittels DHCP in das Netzwerk aufgenommen.
| Info |
|
Möchte man den Klienten mit einer statischen IP aufnehmen ist die Netzwerkkonfiguration via YAST vorzunehmen. |
Ende des Bootvorganges
Nach Abschluss des Bootvorganges steht eine Linux Shell zur Verfügung:
Hier können gegebenenfalls noch weitere Aktionen wie die Prüfung der Netzwerkverbindung zum Sesam Server vorgenommen werden (mit ping und nslookup/host). Um zu prüfen ob der Sesam Klient korrekt läuft fogenden Befehl eingeben (vorher mit su als root einloggen):
| Info |
|
Root PW: recover |
/etc/init.d/sesam status
Aufnahme des Clienten am SEP sesam Server
Anschließend ist es Nötig den Clienten am SEP Sesam Server aufzunehmen. Dies erfolgt über die SEP Sesam GUI. Hier gibt es keinen Unterschied zur Aufnahme eines regulären Klienten.
Die Verbindung zum SEP Sesam Klienten muss erfolgreich sein, gibt es bei Aufnahme des Live-CD Klienten Komplikationen, so sind die im Sesam üblichen Parameter zu überprüfen (DNS (Forward- Reverselookup, ping, etc.)
Start des Restores über den Restore Wizard
Der Restore teilt sich in zwei Vorgänge auf:
- Restore der "disk_info" Sicherung, partitionieren der Festplatte
- Restore der "all" Sicherung und Installation des Bootloaders
Restore der disk_info Partitionsinformationen
| Achtung |
|
Der Restore erfolgt hier immer auf das Zielsystem "recover", NICHT auf den eigentlichen Klienten! |
Restore
Überprüfung des Restores
Nach einem erfolgreichen Restore ist zu überprüfen ob auf dem Clientsystem die nötigen Partitionen erfolgreich angelegt wurden. Wichtig ist hierbei, dass die entsprechenden Partitionen des Zielsystems auf dem Live-CD system nach /mnt/disk/ eingebunden werden. Das Restore Protokoll enthält am Ende die nötigen Informationen welche Dateisysteme eingebunden wurden.
In diesem Beispiel wird auf eine einzige Festplatte zurückgesichert:
Current mount status: ============================================================ /dev/sda2 on /mnt/disk type ext3 (rw) ============================================================
Restore der "all" Sicherung auf den Klienten
War die Rücksicherung der "disk_info" erfolgreich, so können nun die Eigentlichen Daten des Clienten zurückgesichert werden. Am ende der Rücksicherung werden die entsprechenden Bootinformationen in den Master-Boot-Record geschrieben.
Reboot des Systems
Anschließend kann das Live-CD System gebootet werden und das Originalsystem steht wieder zur Verfügung.
Troubleshooting
Probleme beim Bootvorgang des Recoverten Systems
Es wird kein Bootfähiges System gefunden
Wird trotz erfolgreichem Restore kein Betriebssystem beim Boot gefunden, lässt das auf ein Problem bei der Installation des GRUB Boot Managers schliessen.
Das Restore-Protokoll enthält die entsprechende Fehlermeldung nach der folgenden Stelle:
2009-12-14 14:48:27: sbc-3500: Info: Reinstall boot manager [/sesam/bin/sesam//sbc_grub_auto /mnt/disk/ AUTO]
/dev/sda1 does not have any corresponding BIOS drive.
Tritt der Folgende Fehler während des Restores auf:
/dev/sda1 does not have any corresponding BIOS drive.
so ist die auf dem Recoverten System verfügbare "/boot/grub/device.map" zu überprüfen. Finden sich hier Einträge auf Devices wie z.B:
(hd0) /dev/by-disk/id/<disk_id>
findet der entsprechende GRUB Aufruf das Device nicht. Workaround
- Von der Live CD Booten
- Das Root Verzeichnis nach /mnt/disk/ mounten
- GGF das Boot verzeichnis (wenn seperat) nach /mnt/disk/boot/ mounten
- anschliessend GRUB mit den folgenden Parametern aufrufen:
grub-install --root-device=/mnt/disk --recheck hd0
fsck.ext3: Filesystem has unsupported feature(s)
Bei einem Restore von Kernel Versionen älterer Generation (z.B. 2.4.x) kann es Vorkommen dass der Kernel die von der BSR CD angelegten Dateisysteme nicht nutzen kann, weil sie über mehr Features verfügen als der Kernel unterstützt.
Das häufigste Problem sind die EXT Features "resize_inode,dir_index,large_file,ext_attr"
Für dieses Problem gibt es nur einen Workaround: Erneut von der BSR Linux CD Booten und diese Features mittels des Tools "debugfs" entfernen. Dies geschieht über die folgenden Befehle:
Anzeigen der Filesystem features:
root@recover#: debugfs -w /dev/sda2 debugfs 1.41.1 (01-Sep-2008) debugfs: features Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file quit
/dev/sda2 ist gegen die richtige Partition zu ersetzen!
Entfernen der Filesystem Features:
root@recover#: debugfs -w /dev/sda2 debugfs: features -resize_inode -ext_attr -dir_index -large_file -needs_recovery -sparse_super Filesystem features: has_journal filetype quit
nach einem anschliessenden Reboot sollte das System wieder bootfähig sein.
incorrect inode size (256)
Nach einem Restore stopt der Boot mit Fehlermeldung "incorrect inode size (256)" Ältere Kernel Versionen (z.B. SLES8 Basierte Systeme) nutzen eine Inode Size von 128k. Der Workaround ist hier: Nach anlegen der Partitionen durch den disk_info restore, müssen diese auf der BSR Cd ausgebunden werden (mittels umount) und erneut mit der richtigen Inode Grösse formatiert werden:
mkfs.ext3 -I 128 </b>/dev/partition</b>
anschliessend die entsprechenden Partitionen wieder nach /mnt/disk einbinden und den Restore der "all" Sicherung wiederholen.
Ein Ändern der Inode Grösse ohne Formatierung ist bei Ext2/3 derzeit nicht möglich.
Das Restorte System findet keine Netzwerkkarten
Wurde die Instanz auf ein Hardware System restored das über andere Netzwerkkarten verfügt, so besteht bei SLES Basierten Distributionen das Problem dass die Netzwerkkarten beim anschliessenden Boot nicht erkannt werden.
Das Problem ist: SLES Basierte Distributionen ordnen die Netzwerkkonfiguration über die MAC Adressen zu. Ändert sich die MAC Adresse, so stimmt die zuordnung nicht mehr.
Das System geht dann wie folgt vor: es wird das neu erkannte Netzwerk Interface nicht als "eth0" eingebunden, sondern als "eth1".
Unter SLES Basierten Distributionen gibt es hier mehrere Wege dieses Problem zu lösen:
1) Neukonfiguration der Netzwerkkarte über YAST: einfache Lösung 2) Anpassen von /etc/udev/rules.d/70-persistent-net.rules setzt Weitereichende SLES Kenntnisse vorraus
Das File /etc/udev/rules.d/70-persistent-net.rules enthält die Liste der gefundenene Netzwerkkarten und wird während des Bootvorganges erstellt. Hier findet sich auch der alte Eintrag zu "eth0" und die entsprechend alte MAC Adresse des Systems. Diesen Eintrag entfernen oder die MAC Adresse entsprechend ändern.
Zusätzlich müssen in /etc/sysconfig/network/ noch die entsprechenden ifcfg-eth<id-<mac_adresse> Scripten geändert werden.
