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… 😉

Ubuntu boot – Partition voll – Holzhammermethode

Wenn ich mit VMs hantiere und ‚mal schnell‘ eine Ubuntu VM installiere, klicke ich den Installer mit den meisten Default Einstellungen durch. Auch die Partitionierung der (virtuellen) HDD überlasse ich mangels besseren Wissens den Defaults des Setup.

Nun passierte es kürzlich, daß div. Softwareinstallationen scheiterten, weil die /boot Partition angeblich voll sei. Es stellte sich heraus, daß diese mit ca 240 MB nicht sonderlich groß war.

brd06

Ausgiebiges googeln nach Möglichkeiten der Vergrößerung ließ mich unzählige Workarounds mit fdisk und lvmgr ausprobieren. Letztlich führte nichts zum gewünschten Erfolg. Als alter Mausschubser wünschte ich mir ausserdem gern eine grafische Lösung meines Problems. Die fand ich schlussendlich in Form einer Boot CD zur Reparatur des grub2 Bootmanagers: Boot-Repair-Disk (B-R-D)

Mit der folgenden, etwas groben, Vorgehensweise konnte ich die /boot Partition vergrößern/verschieben.

  • Vergrößern der virtuellen Festplatte
  • Booten der VM mittels B-R-D
  • die nächsten Schritte mittels GParted: kopieren der /boot Partition auf den ungenutzten Speicherbereich
  • /boot-Flag auf neuer Partition setzen
  • alte /boot Partition löschen
  • GParted beenden
  • Aufruf des Tools „Boot-Reparatur“ von B-R-D
  • Anweisungen zur Reparatur von grub2 befolgen
  • Reboot, fertig.

Eine detailierte bebilderte Anleitung habe ich HIER zusammengestellt.

Es sei erwähnt, daß sich nach dem Booten mittels B-R-D ein Snapshot der VM anbietet um im Fehlerfall an den Ausgangspunkt der Aktion zurückspringen zu können.

Nachdem ich mittels o.g. Prozedur die Speicherprobleme beheben konnte, stellte sich mir die Frage, was eigentlich beim Setup per Default eingestellt ist und was es für Alternativen für die Zukunft gäbe.

Während der Ubuntu Installation lautet die Vorbelegung des Assistenten zur Partitionierung: „Geführt – gesamte Platte verwenden und LVM einrichten“.

 

brd03

Das führte zu folgender Partitionierung mit vollgelaufener /boot Partition

gefüllte /boot Partition

 

Die /boot Partition befindet sich am Anfang der HDD und kann nicht vergrößert werden

Weicht man stattdessen beim Setup auf den ersten Eintrag in der Liste aus – „Geführt – vollständige Festplatte verwenden“ …

brd04

…ergibt sich folgende Partitionierung, welche man im Bedarfsfall etwas einfacher erweitern könnte.

brd05

 

 

diverse Parameter bei der Arbeit mit Linux

Kommandos, Shortcuts, Konfiguration die ich mir immer wieder ergoogle weil ich sie mir nicht merken kann/will…

Ubuntu Version auslesen

lsb_release -a

Kernel Version

cat /proc/version_signature

CentOS Version auslesen

cat /etc/redhat-release

CentOS Dienste

chkconfig --list
service --status-all
service --stauts-all | grep... filtern

Editor vi – Zeilennummern

#Einschalten

:set number

#Ausschalten

:set nonumber

#Zeilennummer per default immer einschalten: in die Datei /etc/vim/vimrc die Zeile

set nu

einfügen.

Proxyserver als globale Variable eintragen: /etc/environment bzw. ~/.bashrc

export http_proxy='http://user:password@prox-server:port'
export https_proxy='http://user:password@prox-server:port'
export ftp_proxy='http://user:password@prox-server:port'
alternativ
export {http,https,ftp}_proxy='http://user:password@prox-server:port'

User/Password nur wenn für Proxy erforderlich

für apt in /etc/apt/apt.conf

Acquire::http::proxy "http://Proxy-IP-Adresse:Port/";

für wget in /etc/wgetrc

http_proxy = http://Proxy-IP-Adresse:Port/

https_proxy = http://Proxy-IP-Adresse:Port/

für yum in /etc/yum.conf
 proxy=http://Proxy-IP-Adresse:Port

für rpm: sudo visudo
Defaults env_keep += „http_proxy“
Defaults env_keep += „https_proxy“

 

Hilfreich: https://help.ubuntu.com/community/EnvironmentVariables

Linux Taskmanager – Alternative zu ‚top‘

Eine übersichtliche schicke Alternative zu ‚top‘ auf der Console ist ‚htop‘

Da ich mit Ubuntu arbeite, erfolgt die Installation mittels apt-get.

sudo apt-get install htop

Aufruf, schlicht: htop