Wer physische oder virtuelle Linux-Maschinen zu Hyper-V, vSphere oder auf geänderte Hardware migrieren möchte, sollte einen Blick auf das quelloffene Desaster-Recovery-Werkzeug Relax and Recover (ReaR) werfen. Geschaffen wurde es für bequeme Bare-Metal-Restores, also für das Wiederherstellen von Systemen per Knopfdruck auf nackter Hardware. Dazu erzeugt es aus dem laufenden System ein Backup und ein angepasstes, bootfähiges Rescue-Medium.
Technisch betrachtet steckt hinter dem modularen Desaster-Recovery-Framework ReaR ein mächtiges, interaktives bash-Skript. Das Backup erzeugt ReaR wahlweise mit Linux-Bordmitteln wie tar oder rsync oder durch Einbinden eines vorhandenen Backup-Systems. ReaR unterstützt CommVault Galaxy, EMC NetWorker, HP DataProtector, IBM Tivoli Storage Manager, SEP Sesam, Symantec NetBackup, Bacula und duplicity.
Da bei neueren ReaR-Versionen das Recovering auch auf nicht identischer Hardware gelingt, eignet es sich auch für P2V-, V2P- und V2V-Migrationen von Linux-Maschinen. ReaR versucht dann automatisch passende Ersatzhardware wie virtuelle Netzwerkadapter zuzuweisen oder fragt verfügbare Alternativen interaktiv ab. Denn ohne eine funktionierende NIC könnte das Tool beispielsweise nicht auf ein per NFS zugängliches Backup zugreifen. Will man Migrationen im großen Stil automatisieren und sind etwa in einer VMware-Umgebung die virtuellen Äquivalente zu den ursprünglichen Hardwarekomponenten vorher bekannt, kann der Admin die Zuordnungen auch vorab festlegen. Die entsprechenden Mapping-Dateien sucht ReaR unter /etc/rear/mappings.
Das Recovery-Medium mit dem Rescue-System kann ein ISO-Image, ein USB- oder eSATA-Gerät, ein bootfähiges OBDR-Tape oder eine NBP-Datei für PXE-Boot sein. Das Medium enthält nach der Sicherung einen individualisierten Kernel nebst benötigten Modulen sowie die gesamte ReaR-Konfiguration mit einer Beschreibung des gesicherten Systems und alle Informationen, die es zum Wiederherstellen braucht.
Für die P2V-Migration legt man zunächst eine neue Standard-VM unter vSphere oder Hyper-V an. Zahl und Größe der virtuellen Festplatten müssen der Ausgangslage weitgehend entsprechen. Gleiches gilt für die Zahl der NICs. Ursprünglich verwendete USB-Geräte lassen sich in der Regel nachträglich per Client- beziehungsweise Host-USB-Passthrough zum Laufen bringen. In der VM nicht unterstützte Geräte oder Treiber sollte man vorher deinstallieren. Will man das Rescue-System vom ISO-Image booten, benötigt der Administrator zudem ein mit diesem verknüpftes virtuelles CD-Laufwerk. Bei PXE genügen die virtuelle NIC und die passende Boot-Reihenfolge.
Große Auswahl bei der Zwischenablage
Vor dem ersten Start hinterlegt der Systemverwalter in der Konfigurationsdatei /etc/rear/local.conf, was ReaR sichern soll und wohin es das Rescue-Image und das Backup schreibt. Trotz umfangreicher und ausführlich kommentierter Beispielkonfiguration /usr/share/rear/conf/default.conf braucht es meist nur wenige Optionen. Unter ihnen bestimmt die Variable OUTPUT die zu verwendende Boot-Methode und BACKUP die gewünschte Backup-Strategie. Mit
OUTPUT=ISO BACKUP=NETFS BACKUP_URL="nfs://<NFS-Server>/<Pfad>
würde ReaR das Rescue-System in einer ISO-Image-Datei ablegen – per Default unter /var/lib/rear/output/ –, das Backup mit dem Standardwerkzeug tar durchführen und es auf die angegebene NFS-Freigabe legen. Mit OUTPUT=PXE würde das Tool die NBP-Datei zum direkten Booten des ISOs per PXE und alle weiteren für PXE-Boot benötigten Dateien unter /var/lib/rear/output/ speichern.
Schließlich bestimmt die Zeile BACKUP_URL=“nfs://<NFS-Server>/<Pfad> das Backup-Ziel, hier eine NFS-Freigabe. OUTPUT_URL=“nfs://<NFS-Server>/<Pfad> weist ReaR an, sämtliche Output-Daten wie Rescue-Image, Konfigurationsdaten und die PXE-Konfiguration zusätzlich auf das angegebene Ziel zu schreiben. Abschließend lassen sich mit AUTOEXCLUDE_PATH=<Pfad> Verzeichnisse vom Backup ausschließen, etwa Netzverzeichnisse.
Steht die Konfiguration, startet der Administrator den Prozess mit rear –v mkbackup, wobei –v für Gesprächigkeit sorgt. Alternativ stehen mit –s ein Simulationsmodus sowie mit –S ein Step-by-Step-Modus zur Verfügung. Optional kann er ReaR mit rear mkrescue zu Kontrollzwecken zunächst nur das Rescue-Image erzeugen lassen. Geht etwas schief, hilft ein Blick in /var/log/rear/rear-<hostname>.log, andernfalls kann der Umzug beginnen.
Nach dem Einschalten der VM und dem Laden des Rescue-Bootloaders kann der Administrator im automatisch erzeugten Boot-Menü zunächst versuchen, mit Automatic Recover <name> das Rescue-System hochzufahren. Andernfalls muss er gegebenenfalls zu ersetzende Komponenten manuell bestätigen. Ist das erledigt, kann er mit rear recover das eigentliche Recovery starten. ReaR baut das neue System dann automatisch wieder zusammen.
ReaR funktioniert auch bei aufwendigen Konfigurationen fast automatisch. Sogar RAID-Sets oder Logical Volumes, zahlreiche eingebundene Netzdateisysteme und mehrere NICs bringen es normalerweise nicht aus dem Tritt. (sun)
