Inhaltsverzeichnis
Mein Ubuntu-Server läuft auf meiner MSI Windbox II seit geraumer Zeit in Version 11.10 und liefert mir 24/7 und ohne Ausfälle unverzichtbare Dienste (Mail, Web, Fileserver, etc.). Leider hatte ich es bei der ersten Installation vor mehr als 2 Jahren übersehen, mir ein Image zu ziehen. So sichere ich zwar immer fleißig alle wichtigen Daten (Konfigurationen, Datenbanken, Web, …) per Cronjob auf externe Festplatten, jedoch würde ich vor einem großen Problem stehen, wenn die Hardware einen Defekt bekommen würde und ich den Server tauschen müsste. Eine Neuinstallation und Neukonfiguration wäre unausweichlich.
Außerdem: Nachdem die verwendete Ubuntu-Server Version doch schon etwas betagt ist (2 Jahre alt), wollte ich mich an ein Upgrade wagen. Nachdem bei automatischen Upgrades oftmals Probleme auftreten und die neue Version durch Leichen im Altsystem nicht so richtig läuft, muss ich natürlich auf Nummer Sicher gehen und eine Rückfallstrategie anwenden bzw. zuerst einmal Upgrade-Tests auf einer Maschine fahren, bei der es egal ist, wenn was schief geht.
Diese zwei Punkte verlangen nach einem Image, dass ich jetzt endlich erstellt habe und die Basis für weitere Schritte in meiner Upgradestrategie bietet:
- Image von der gesamten Platte erstellen.
- Virtuelle Maschine mit VMware Player auf Desktop anlegen.
- Virtuelle Maschine mit Live-USB starten.
- Netzwerkfreigabe mit dem Image innerhalb der virtuellen Maschine einhängen.
- Image auf die virtuelle Festplatte einspielen.
- Server in virtueller Umgebung starten und Tests durchführen.
- Realen Server hochrüsten und zuvor die Anfragen auf den virtuellen Umleiten.
1. Image von der gesamten Platte erstellen
Alternative 1: Image mit dd erstellen
Images erstellt man unter Linux bekanntlich mit dem Konsolenprogramm Diskdump (dd). dd macht nichts anderes, als den Datenträger bit-genau auszulesen und entweder direkt auf einen anderen Datenträger (clonen) oder in eine Image-Datei zu schreiben. Dies hat zur Folge, dass auch nicht beschriebene Bereiche der Festplatte mit ausgelesen werden und entsprechend Speicherplatz belegen. Will man eine dd-Imagedatei speichern bietet es sich deswegen auch an, dass man diese komprimiert. Beschrieben wir das ganze wunderbar im dd Artikel auf Ubuntuusers.de.
Der Haken an der Sache: Für ein dd-Image von der gesamten Platte und damit auch von der Systempartition darf diese nicht eingehängt sein. Ein dd-Image während des Betriebes kann u.U. fehlerhaft sein, da sich manche Dateien bei einem laufenden System natürlich ständig ändern. Aus diesem Grund musste der Server für einige Zeit vom Netz, um das Image anzulegen.
Dafür habe ich mir ein Kubuntu Livesystem auf einem USB-Stick erstellt. Dies geht ganz einfach, indem man zum einen ein beliebiges Live-Linux als ISO runterlädt und dann mit (K)ubuntu eigenen „Startmedienersteller„(usb creator) auf den USB-Stick kopiert.
Ist der Live-USB-Stick eingerichtet, kann man auch schon davon starten und booten. Ist das Live-System schließlich geladen, öffnet man eine Konsole und bindet am besten eine externe Festplatte ein:
sudo mkdir /media/extern
sudo mount /dev/sdb1 /media/extern
Natürlich sollte auf dem externen Datenträger genug freier Speicherplatz sein, um das Image aufnehmen zu können. Bei meiner 160GiB Platte sind das in etwa 150GB. Ist die externe Platte also eingehängt, können wir beginnen, das Image mit nachfolgendem Befehl zu erstellen:
sudo dd if=/dev/sda of=/media/extern/imagedatei.img
Das Erstellen dauert dann etwas (immerhin müssen 160GB bitweise ausgelesen und geschrieben werden).
In der Zwischenzeit kann man mit Schritt 2 beginnen und die VM auf einem zweiten Rechner anlegen (in meinem Fall mein Desktop mit Kubuntu 13.04).
Alternative 2: Image mit Clonezilla erstellen
Nachdem ich die Erfahrung machen musste, dass mein dd-Image zwar in die VM zurückgespielt werden konnte (wie im nächsten Schritt beschrieben), jedoch nicht startbar war, startete ich tagelange (!!) Versuche irgendwie ein Image zu generieren, dass ohne Fummelei (Grub oder MBR anpassen) in der VM lauffähig ist.
Relativ schnell stieß ich dabei auf Clonezilla, einer freien Implementierung einer Image-Software, ähnlich der kostenpflichtigen Pendants wie Notorn Ghost oder Acronis Trueimage. Leider scheiterte ich an der Erzeugung eines Live-USB-Sticks (die Windbox hat kein DVD/CD-Laufwerk). Alle Versuche mit dem bordeigenen (K)Ubuntu-Tool „Usb-Creator“ (das mit (K)Ubuntu hervorragend funktioniert) oder dem von Clonezilla empfohlenen Tuxboot scheiterten. Ich konnte nie von diesem USB-Stick erfolgreich booten. Der Verzweiflung nahe probierte ich viele viele andere Wege irgendwie an mein Image zu kommen (Kubuntu-Live-USB und Image mit partimage, Image mit Redo Backup an Recovery Live-USB). Mit Redo schaffte ich zwar ein Image und das Rücksichern klappte auch, jedoch meldete mir die VM beim Hochbooten, dass der Gast die CPU deaktiviert hätte und man die VM resetten oder stoppen solle (?!).
Wie gesagt, tagelanges Rumprobieren. So ein Image erstellen und Rücklesen dauert ja meistens seine Zeit, die Sucherei nach Lösungswegen sowieso.
Eigentlich wollte ich schon aufgeben, aber dann hat es mich nochmal überkommen und ich startete einen erneuten Versuch mit Clonezilla. Immerhin ist diese Distribution eine vielgerühmte Alternative Images einfach und schnell zu erstellen und rückzuspielen.
Also nochmal von vorne: Ich suche nach einem Weg einen Live-USB-Stick zu erstellen, der natürlich nicht die Bordmittel nutzt und auch nicht Tuxboot. Im eigentlich „alten“ Tool UNetbootin wurde ich dann fündig und installierte es prompt mit:
sudo apt-get install unetbootin
Als ich das schlanke Programm dann ausführte, hatte ich wenig Hoffnung, dass es diesmal funktionieren würde. Wieso? Ganz einfach: Tuxboot ist nichts anderes als Unetbootin und setzt darauf auf. Die Zweifel wurden schnell zerstreut, nachdem ich auf mehreren USB-Sticks ein bootfähiges Clonezilla aus dessen ISO erzeugt hatte (und testweise auch andere Live-Systeme auf den Stick damit bracht: Knoppix, Kubuntu, Redo, …).
Ich erstellte also ein komplettes Festplatten-Image mit Clonezilla (alles in Standardkonfiguration, nur die Pfade habe ich angepasst. Gespeichert habe ich das Image auf eine externe Festplatte) und war bereit für den nächsten Schritt.
2. Virtuelle Maschine mit VMware Player auf Desktop anlegen
Vorausgesetzt, man hat bereits den kostenlosen VMware Player runtergeladen und installiert, legt man sich eine nackte virtuelle Maschine an, mit einer Festplatte, die groß genug ist, um unser Image aufnehmen zu können. Nachfolgend die Einstellungen, wie sie bei mir aussehen (zum Vergrößern klicken):
3. Virtuelle Maschine mit Live-USB starten
Die leere virtuelle Maschine wollen wir jetzt mit dem Live-USB-Stick starten, den wir zuvor auch schon benutzt haben, um unser Image vom Server zu erstellen. Dies stellt uns jedoch vor die Schwierigkeit, dass man im VMware Player keine VM von USB booten kann. Diese Option fehlt schlichtweg im Bootmenü. Allerdings hatte ich auch keine Lust extra eine LiveCD zu brennen und machte mich auf die Suche, wie man dieses Problem umgehen kann.
Abhilfe schafft hier das Plop Bootmanager, den man hier kostenlos runterladen kann. Nachdem ich diesen Boot Manager nur einmal benötige, extrahiere ich nur die Datei plpbt.iso.
Diese ISO binden wir jetzt fest in die VM als CDROM ein (zum Vergrößern klicken):
Nun starten wir die VM und wir bekommen vom Plop Boot Manager jetzt auch USB-Boot angeboten, was wir natürlich auswählen und von unserem LiveUSB-Stick booten. (Natürlich muss der USB-Stick vorher mit der VM verbunden worden sein: Virtual Machine –> Removeable Devices –> den USB-Stick connecten.)
Alternativ dazu kann man auch das ISO von Clonezilla fest als CDROM einbinden, es startet dann automatisch, ohne einen USB-Stick erstellen zu müssen. Man sollte jedoch nicht vergessen, dass man dieses ISO dann auch wieder aushängt, wenn man es nicht mehr benötigt.
4. Netzwerkfreigabe mit dem Image innerhalb der virtuellen Maschine einhängen
Als nächstes müssen wir Zugriff auf das Image erhalten, das ich auf meinem Desktop-PC abgelegt habe. Denkbar wäre natürlich auch, dass man die externe Festplatte direkt in die VM einbindet. Ich erkläre nachfolgend den Weg über die Freigabe.
Auf dem Desktoprechner gebe ich also den Ordner mit dem Image als Samaba-Freigabe frei, um ihn anschließend mit nachfolgendem Befehl in die Live-Umgebung einzubinden.
sudo mkdir /media/freigabe
sudo mount -t cifs -o guest //192.168.1.10/Imageordner /media/freigabe
Die IP-Adresse muss natürlich die eures Rechners sein, auf dem die Freigabe liegt, genauso, wie der Pfad zum Image. Nun haben wir also Zugriff auf das Image.
Alternativ dazu kann man auch einen entsprechenden Share-Ordner in der VM einrichten und so direkt auf das Image verweisen. Oder man geht den Weg über eine externe Festplatte, die man wie einen USB-Stick in die VM verbindet.
5. Image auf die virtuelle Festplatte einspielen
Alternative 1: Image mit dd Rückspielen
Mit diesem Schritt spielen wir unser Image vom realen Server in die Virtuelle Maschine eine. Dies geschieht abermals mit dd und kann einige Zeit in Anspruch nehmen.
sudo dd if=/media/freigabe/imagedatei.img of=/dev/sda
Alternative 2: Image mit Clonezilla rückspielen
Auch hier empfehle ich den Einsatz von Clonezilla, das die Rücksicherung denkbar einfach macht. Einfach dem Dialog folgen und den Pfad zur Imagedatei auf der externen Festplatte oder im Netzwerk angeben und Clonezilla die Arbeit erledigen lassen. Grundsätzlich sei angemerkt, dass Clonezilla bei mir bei der Sicherung und Rücksicherung um den Faktor 10 schneller war als dd.
6. Server in virtueller Umgebung starten und Tests durchführen
Nachdem Clonezilla erfolgreich das Image zurückgesichert hatte (inkl. Grub und MBR) konnte ich meinen virtuellen Ubuntu Server 11.10 ohne Probleme starten. Eine andere IP Adresse verpasst und schon lieferte er mir alle Dienste, wie der „echte“ Server auch.
Im Anschluss daran machte ich ein sudo do-release-upgrade, der einzige Befehl der übrigens dazu nötig ist, sein Ubuntu-System eine Version höher zu bekommen. Im Endeffekt rauschen jetzt haufenweise Meldungen über den Bildschirm und es kommt nur selten zur Interaktionen (meistens wenn es um die Konfiguration von Serverdiensten geht oder wenn angepasste Konfig-Dateien entdeckt wurden).
Das Upgrade ging dann auch relativ schnell von statten und bescherte mir einen schwerwiegenden Fehler: Ich konnte den Imap-Server Cyrus nicht hochrüsten. Es fehlen ihm irgendwelche Abhängigkeiten bzw. kann das Paket cyrus-common in der Version 2.4 nicht konfiguriert werden.
Nach ein paar Recherchen stieß ich darauf, dass wohl ein paar andere User das selbe Problem hatten, jedoch niemand eine Lösung auftischen konnte. Der nächste Schritt wäre, Cyrus zu deinstallieren und in neuer Version zu installieren. Allerdings muss ich mich erst schlau machen, wie ich meine Mail-Datenbank dann in Cyrus importieren kann und ob dies überhaupt etwas bringt.
Bevor ich dieses Problem nicht gelöst habe bleibt der echte Server wie er ist.
Fazit für’s erste: Selbst wenn ich mehrere Tage mit Image-Software gekämpft habe, hat es sich gelohnt die reale Serverumgebung für Test in eine virtuelle Maschine zu bringen. Dieser Artikel wird natürlich komplettiert, sobald ich auch den realen Server hochrüsten konnte.
7. Realen Server hochrüsten und zuvor die Anfragen auf den virtuellen Umleiten.
Steht noch aus.