Veeam Agent for Linux – Recovery mit Hürden

Um den Backupprozess zu vereinheitlichen wurde vor einiger Zeit bei den letzten verbliebenen physischen Rechnern/Servern auf Veem Endpoint Backup bzw. Veeam Agent for Linux bzw. for Windows umgestellt. Die Datenspeicherung erfolgt über ein zentrales Veeam Backup Repository. Das ganze Backup- und Recovery Szenario wurde in einer VM Umgebung durgespielt und dokumentiert und, man ahnt es schon, VM Umgebung…., gabs beim ersten Recoveryversuch an der echten phsyischen Maschine erhöhten Pulsschlag.

Im konkreten Fall wird eine Debian Maschine, installiert auf einer Dell Workstation T3600, mittels Veeam Agent for Linux täglich gesichert. Zum Zeitpunkt der Wiederherstellung lief das System noch. Es sollte nur ein paar Tage zurückgesetzt werden. Als erstes also das Linux Recovery Image bei Veeam heruntergeladen, per Rufus auf nen Stick gepresst, Workstation gebootet und schwupp die wupp, Kernel Panic!…. nach wenigen Sekunden.

Ein Blick in die Doku bei Veeam verrät, daß in dem Recovery Image u.U. Treiber für die eigene Hardware fehlen könnten und es eine Möglickeit für die Erstellung eines eigenen individuellen Recovery Mediums gibt. Glücklicherweise lief der betreffende Rechner noch. Man kopiert das Imagefile von Veeam (nenne ich jetzt mal ‚veeam-base-image.iso‘) auf den betreffenden Rechner und erzeugt mittels:

veeamconfig config patchiso --input /tmp/veeam-base-image.iso --/tmp/output custom-drivers-image.iso

ein neues Imagefile. Dieses dann wieder per Rufus auf den Stick pressen, Rechner neu starten und tadaaa…. o.O hängt der Bootvorgang schon wieder, diesmal in einer Schleife mit der unschönen Meldung

Not enough memory to load specified image

Hier half es auf dem Stick die Datei isolinux.cfg im Ordner isolinux mittels eines Texteditors (bspw. Notepad++ unter Windows) zu editieren.

Die letzte Zeile

append initrd=initrd.img

wird ergänzt um einen Eintrag für zugewiesenen Speicher. In meinem Fall sah das dann so aus

append initrd=initrd.img mem=2048M

Datei speichern, Stick anstecken, Dell T3600 Workstation damit booten uuuuunnnnddd….. tadaaa, Die Veeam Agent Oberfläche erscheint. Das sich diese nun nicht mehr bedienen ließ, konnte mit dem Anstecken einer PS2 Tastatur behoben werden. USB Tastatur wollte hier keine mehr reagieren.

Kurzer Check in den Netzwerkeinstellungen, Netzwerkkarte erkannt, IP per DHCP erhalten und somit konnte es losgehen im ersten Schritt die Anbindung an das Veeam Backup Repository zu konfigurieren. Die eigentliche Wiederherstellung lief dann so, wie man es von Veeam gewohnt ist. Schnell und zuverlässig. Nach einer Viertelstunde war das System auf den gewünschten Zeitpunkt zurückgesetzt.

Merke, die alte Weisheit mit Bart, daß ein Backup nur dann wirklich ein Backup ist wenn man die Wiederherstellung getestet hat, hat sich hier wieder einmal bewahrheitet. Glücklicherweise konnte das Recoverymedium noch an die spezifische Hardware angepasst werden. Das sollte man also künftig direkt bei der Einrichtung der Datensicherung mit erledigen. Und auf jeden Fall einen Testdurchlauf unter Echtbedingungen durchführen! Und dokumentiern! Eh  klar… 😉

Acronis Home PXE Boot – Testversion / Trial License

Um ein Acronis anstatt von einer CD oder USB Stick einfachererweise aus dem Netzwerk zu starten, bedarf es keines großen technischen Aufwands.
Man benötigt einen konfigurierbaren DHCP Server der bei der automatischen IP-Vergabe dem Client als zusätzlichem Parameter zur IP noch einen „Netzwerk Startserver“ mitgibt den dieser beim „Booten per Netzwerk“ anspricht.
Als zweites muß man den „Netzwerk Startserver“ in Form eines TFTP-Servers bereitstellen.
Für beide Anforderungen finden sich im Internet unzählige Anleitungen für alle erdenklichen Plattformen (z.bsp. tftpd32 unter Windows, tftp unter Linux)

Um jetzt ein Acronis aus dem Netzwerk zu booten bedarf es nur zwei Dateien von der Acronis CD, die auf dem TFTP Server bereitgestellt werden müssen. Eine kernel.dat und eine ramdisk.dat.
So weit, so einfach.

Nun zum eigentlichen Problem. Wenn man die besagten Dateien von der Boot-CD oder aus einem selbst erstellten ISO File verwendet, kommt es beim Versuch einer Datensicherung zu folgender Meldung

Dies allerdings nur, wenn man eben per Netzwerk bootet. Bootet man von der besagten CD von der die Dateien stammen, funktioniert die Sicherung einwandfrei. Eine Wiederherstellung einer Sicherung ist immer möglich.
Lösung:
Die Dateien müssen von einem selbst erstellten Wiederherstellungsdatenträger (Rescue Media, kurz RM) stammen. Der Datenträger muss aus einer vollständig lizensierten und aktivierten Acronis Installation heraus erstellt werden. Darüber hinaus darf man nicht fälschlicherweise die o.g. Dateien kernel.dat und ramdisk.dat verwenden (die tatsächlich vorhanden sind) sondern die Dateien dat2.dat und dat3.dat.
Am einfachsten wählt man beim Erstellen des RM als Ziel einen USB-Stick (NICHT CD, NICHT ISO). Der angesteckte Stick wird dabei nicht gelöscht sondern nur um diverse Ordner und Dateien erweitert.
Im Rootverzeichnis des Stick befinden sich anschließend u.a. die genannten Dateien dat2.dat und dat2.dat wobei es sich bei der dat3.dat um die besagte kernel.dat und bei der dat2.dat um die besagte ramdisk.dat handelt.
Man kann sich im Endeffekt das umbenennen schenken, die Dateinamen spielen beim Startvorgang keine Rolle.
So sieht bspw. der Eintrag in der default Datei auf meinem Linux TFTP Server aus, um Acronis zu starten:

LABEL acronis2013
MENU LABEL Acronis True Image 2013
KERNEL /acronis2013/dat3.dat
APPEND initrd=/acronis2013/dat2.dat vga=791 root=/dev/ram0 quiet

Alles weitere zur Einrichtung einer PXE Umgebung läßt sich googeln. Ich möchte hier nur auf das bei mir aufgetretene Problem mit der Testversion hinweisen und die Lösung aufzeigen.