Die Installation der Virtualbox mit diversen VMs auf einer ganz normalen 320 GB Festplatte ist zwar schön, doch inzwischen sind die 500GB SSDs so preiswert geworden, daß man den Faktor 10 an Geschwindigkeitsgewinn unbedingt nutzen sollte.

Darum war die erste und auch wichtigste Aufgabe, die vorhandene bereits installierte Umgebung (WIN 2000 + WIN XP + WIN 7) von der 320 GB WD Platte auf die 480 GB SSD "eins zu eins" funktionsfähig zu übertragen. Doch das erwies sich als ungemein aufwendig.

Dabei gibt es bei mir sowieso eine Grundvoraussetzung, daß ich eine wie auch immer geartete (nachvolllziehbare) Prozedur für die kürzest mögliche Wiederanlaufzeit ausprobieren muß.
.

Aus bitterer Erfahrung trenne ich bei virtualisierten "Maschinen" aller Art das Basis-System von dem VMs und das sowohl unter "XEN" (das sind bei mir die Server) wie auch unter "Virtualbox" (bei mir die Windows PCs). So hatte ich auf der 320 GB WD Platte 2 Primärpatitionen und eine maximal große Extended Partition angelegt.

In der Extended Partition ist immer jeweils eine eigene logische Partition pro VM angelegt. So kann mir zwar das Grundsystem (die DOM 0) "abfackeln" oder gekillt werden, die VMs betrifft das aber nicht, weil sie nicht im Filesystem der DOM 0 "wohnen". Jede angelegte Partition ist dabei (weltweit) eindeutig mit einer UUID nummeriert.
.

Bei mir wird auf dem Basis-System, der DOM 0 unter opensuse Linux, nicht "gearbeitet". Dieses Basis-System hostet nur die diversen Windows-VMs und das sind bei mir unterschiedliche Windows Varianten. Die Partitionierung der Festplatte (alle mit yast angelegt) sieht in der funktionierenden Muster-Installation so aus :

disk:
  /dev/sda             WDC WD3200AAKX-0
partition:
  /dev/sda1            Partition = swap
  /dev/sda2            Partition = opensuse 13.3
  /dev/sda3            Partition = extended filesystem
  /dev/sda5            Partition = 20GB win 2000
  /dev/sda6            Partition = 40GB win XP
  /dev/sda7            Partition = 60GB win 7
  /dev/sda8            Partition = der gesamt unbenutze Rest der Platte
cdrom:
  /dev/sr0             Optiarc DVD RW AD-5260S
.
Die aktuellen UUIDs der Quell-Platte können sie mit der installierten opensuse Version online auslesen (und unbedingt aufgeben/abspeichern). Ich starte auf der Quelle immer den SSH-Server und verbinde mich mit dem "putty" Programm auf diese Umgebung. Damit kann ich die Bildschirmausgaben direkt (zum Beispiel in meine Outlook Objekt-Karteikarten oder) in eine Textdatei eintragen.
.

Erst im Nachhinein weiß man besser, was man unbedingt aufheben sollte:

Der Befehl heißt : "blkid" und das ist die Ausgabe :

/dev/sda1: UUID="a69f37c6-4076-411a-bfd2-51701715678c" TYPE="swap" PARTUUID="0001138c-01"
/dev/sda2: UUID="d7bc7dbd-7902-4835-8661-3905b5732f4e" TYPE="ext4" PTTYPE="dos" PARTUUID="0001138c-02"
/dev/sda5: UUID="65f9e98d-9142-40d1-bb5b-2dd2b525d4be" TYPE="xfs" PARTUUID="0001138c-05"
/dev/sda6: UUID="d068a579-7ce3-4241-a601-6c494bcd5791" TYPE="xfs" PARTUUID="0001138c-06"
/dev/sda7: UUID="724c9bef-3bab-4bbf-b1a6-f81654814d04" TYPE="xfs" PARTUUID="0001138c-07"
/dev/sda8: UUID="87645abf-3d55-4295-b7a0-4652af4183f1" TYPE="ext4" PARTUUID="0001138c-08"
.

ein zweiter Befehl - "ls -l /dev/disk/by-uuid" - gibt folgendes aus :

lrwxrwxrwx 1 root root 10  2. Jan 22:07 a69f37c6-4076-411a-bfd2-51701715678c -> ../../sda1
lrwxrwxrwx 1 root root 10  2. Jan 22:07 d7bc7dbd-7902-4835-8661-3905b5732f4e -> ../../sda2
lrwxrwxrwx 1 root root 10  2. Jan 22:07 65f9e98d-9142-40d1-bb5b-2dd2b525d4be -> ../../sda5
lrwxrwxrwx 1 root root 10  2. Jan 22:07 d068a579-7ce3-4241-a601-6c494bcd5791 -> ../../sda6
lrwxrwxrwx 1 root root 10  2. Jan 22:07 724c9bef-3bab-4bbf-b1a6-f81654814d04 -> ../../sda7
lrwxrwxrwx 1 root root 10  2. Jan 22:07 87645abf-3d55-4295-b7a0-4652af4183f1 -> ../../sda8

und ein dritter Befehl "blkid -o list" gibt das hier aus :

device fs_type label mount point UUID
-------------------------------------------------------------------------------------
/dev/sda1 swap [SWAP]               a69f37c6-4076-411a-bfd2-51701715678c
/dev/sda2 ext4 /                           d7bc7dbd-7902-4835-8661-3905b5732f4e
/dev/sda5 xfs /usr/sda5-20GB       65f9e98d-9142-40d1-bb5b-2dd2b525d4be
/dev/sda6 xfs /usr/sda6-40GB      d068a579-7ce3-4241-a601-6c494bcd5791
/dev/sda7 xfs /usr/sda7-60GB       724c9bef-3bab-4bbf-b1a6-f81654814d04
/dev/sda8 ext4 (not mounted)         87645abf-3d55-4295-b7a0-4652af4183f1
.

Damit haben Sie den Urzustand der Quelle gesichert.

Das war ein zweitägiges Experimentieren und Ausprobieren aller vorhandenen Varianten und Versionen von Partitionierungs- und Sicherungsprogrammen.

Also mit GHOST geht es gar nicht. GHOST hat Probleme mit dem Linux-Filesystem und dem MBR. Selbst unter WIN7 Live mit GHOST 32 dauert es Stunden, bis man auf der Ziel-SSD dann doch nichts Gescheites vorfindet.

Bleiben noch gparted, clonezilla, partimage und partmagic.

Angefangen hatte ich mit einer PCWELT Notfall DVD 5.1 aus 08/2015 und der dortigen Debian Version von clonezilla 2.3.xx. Denn eigentlich hatte sich an den Linux-Filesystemen "ext4" und "xfs" seit Jahren nichts mehr geändert. Ich installiere nach wie vor alle meine Linux root Systeme auf ext4 Filesystemen und noch nicht auf dem neuen BTRFS. Doch diese clonzilla Version konnte die drei VMs auch offline nicht sichern, ein unbekannter Fehler ....... Dann folgten diverse Versuche mit anderen Programmen - leider alle zeitraubend und am Ende unerfolgreich.
.

Alle nicht funktionierenden Programmversionen für die Sicherung der kompletten Platte oder der Partitionen will ich mal weglassen und nur noch die Versionen herausstellen, die am Ende funktionieren.

Das Sichern der einzelnen Partitionen ist aus meiner Sicht sinnvoller als das Sichern der ganzen Platte, weil Sie sonst gezielt einzelne Partitionen nicht zurücksichern können. Und das wäre wichtig für die Zukunft.

Sie brauchen also eine aktuelle Live-Version von "gparted 0.33.0-1" (das ist ein 325 MB iso File). Gleiches gilt für die aktuelle Live-Version von "clonezilla 2.5.6" (ein 244MB iso File). Die Vorläufer Versionen (quasi alle vorherigen Versionen) hatten alle irgendwelche nervigen zeitraubenden Macken. Mit den Live-Versionen sind sowohl Quell-Platte als auch Ziel-Platte immer offline. Das ist wichtig. Ich habe diese beiden Live-Versionen estmal auf CDs gebrannt, der erst mal einfachste Weg.

Weiterhin brauchen Sie zum Speichern der Partitions-Images einen ausreichend großen USB Stick, bei mir 2 x 32 GB (oder 1 x 64 GB).

Hilfreich ist später ein zusätzlicher Rescue Boot-Stick unter einem leidlich aktuellen Linux, egal welcher Distribution, damit die aktuellen SATA Plattentreiber funktionieren.
.

Die nächtliche Eingebung, doch nochmal nach der ganz neuen bzw. letzten iso-Datei von clonzilla Live zu suchen, war richtungsweisend und ein Volltreffer. Was immer die Autoren am Institut in Taiwan verbessert haben, auf einmal funktioniert es.

Mit der gparted Live habe ich mir die Partitionstabellen anzeigen lassen und aufgeschrieben bzw. fotografiert sowie die boot-Eigenschaften (den MS-DOS MBR record) kontrolliert.

Und dann habe ich in der ganz einfachen - fast für Laien - geführten Sicherungsabfrage "Partitions to images" die Partition 1 und 2 (mein opensuse root System) und danach im zweiten Durchlauf (also das Programm clonezilla nochmal im laufenden Linux neu gestartet) die drei VMs (meine part 5 und 6 und 7) jeweils in drei eigene Images geschrieben.

Bei dieser aktuellen clonezilla 2.5.6-22 trat jetzt kein technischer Fehler mehr auf, dafür war jetzt (in dieser Version) die deutsche Übersetzung alles andere als "glücklich". Wie sagte mal einer "nobody is perfect". Stimmt.
.

Wie am Anfang gesagt, eine funktionierende Datensicherung der VMs ist unerläßlich, auch wenn alle meine bewegten Daten auf zwei NAS Servern lagern, also die Windows Clients gar keine (bzw. nur ganz wenige) Daten enthalten.

Alleine eine funktionierende Windows-Umgebung samt der Programme neu aufzusetzen dauert fast einen ganzen Tag. Also die VMs müssen periodisch gesichert werden. Und das hier war mein Test.

Nach dem Tausch der 320er WD Platte gegen die völlig nackte 480GB SSD (von Intenso) musste erst mal mit der gparted Live CD der masterboot record neu erstellt werden. Clonzilla wollte die Platte ohne vorherigen MBR nicht als Ziel akzeptieren bzw. hatte sie gar nicht als Platte erkannt.

Aus Erfahrung hatte ich dann aber auch gleich die ersten beiden Primär- Partitionen sowie die - den gesamten Rest der SSD umfassende - extended Partition angelegt und mit der WD Quell-Platte verglichen.

Dann wieder die Clonezilla live gestartet und meinen ersten 32GB Stick mit part 1 und 2 zurück geschrieben. Das funktionierte super. Doch clonezilla hat sowohl in Part 1 als auch Part 2 neue UUIDs reingeschrieben. Das war nicht so glücklich, weil ich ja ein exaktes Partitionsabbild zurückgesichert haben wollte. Das macht Clonzilla also nicht. Das wußte ich aber erst hinterher.

Im zweiten clonezilla Durchgang nach dem Tausch des 2. USB Sticks hatte ich die VM-Partitionen 5, 6 und 7 zurückgesichert.

Diese Clonezilla Version hat das alles klaglos gemacht, ohne Fehler anzuzeigen, im Gegenteil "like a charme". Das war sehr erfreulich nach 2 Tagen Rumprobieen
.

Um hier etwas vorzugreifen, Sie brauchen eine Rescue CD oder einen Stick unter Linux, der eine Netzwerk-Installation mit all den möglichen Chip- oder Karten- Treibern und einen SSH Server bereits vorbereitet hat, den Sie aktivieren können.

Das wäre zum Beispiel die HIRENS CD 15.2 als Stick oder CD (oder diese neue gparted Live CD). Dort können Sie die Netzwerkumgebung per Click samt DHCP Funktion anwerfen und in der ganz normalen Text-Konsole nach Anlegen eines root" passwortes den SSH Server starten. Dann können Sie wie gehabt per putty auf den PC zugreifen und alles per "Drag and Drop" mit diesen komisch langen von der Quelle-Platte gespeicherten UUIDs in die Kommandozeile reinkopieren. Das geht so natürlich viel viel einfacher, als diese Zahlenketten von Hand zu tippen.
.

Wir benutzen jetzt - wiederum in der putty Konsole - die gleichen Befehle wie anfänglich unter opensuse auf der Quellplatte. Und so sieht das Ergebnis aus :
.
Abfrage : "ls -l /dev/disk/by-uuid"

insgesamt 0
lrwxrwxrwx 1 root root 10  2. Jan 22:56 01cf4a34-8358-41c6-b818-bb9a5c8771ee -> ../../sda1
lrwxrwxrwx 1 root root 10  2. Jan 22:56 d7bc7dbd-7902-4835-8661-3905b5732f4e -> ../../sda2

lrwxrwxrwx 1 root root 10  2. Jan 22:56 65f9e98d-9142-40d1-bb5b-2dd2b525d4be -> ../../sda5
lrwxrwxrwx 1 root root 10  2. Jan 22:56 d068a579-7ce3-4241-a601-6c494bcd5791 -> ../../sda6
lrwxrwxrwx 1 root root 10  2. Jan 22:56 724c9bef-3bab-4bbf-b1a6-f81654814d04 -> ../../sda7
.

oder einfacher

[virtbox1.inhaus - root] /etc $ blkid -o list
device fs_type label mount point UUID
--------------------------------------------------
/dev/sda1 swap (not mounted)         01cf4a34-8358-41c6-b818-bb9a5c8771ee
/dev/sda2 ext4 /                             d7bc7dbd-7902-4835-8661-3905b5732f4e

/dev/sda5 xfs /usr/sda5-20GB          65f9e98d-9142-40d1-bb5b-2dd2b525d4be
/dev/sda6 xfs /usr/sda6-40GB         d068a579-7ce3-4241-a601-6c494bcd5791
/dev/sda7 xfs /usr/sda7-60GB         724c9bef-3bab-4bbf-b1a6-f81654814d04
[virtbox1.inhaus - root] /etc $
.

Bei sda1 (swap) lesen Sie schon : not mounted - also diese (neue) UUID stimmt nicht mit der alten UUID in der fstab Tabelle überein !! Die anderen UUIDs stimmen aber bereits. Die swap Partition kann nicht gemounted werden, weil sie für den Kernel einfach nicht da ist.
.

Nur die Part 1 (swap) hat eine neue UUID bekommen, die natürlich mit den zurückgesicherten UUIDs aus der originalen zurückgesicherten /etc/fstab Tabelle nicht übereinstimmt.

Wir müssen also nur die erste UUID (part 1 = sda1) mit den alten Werten korrigieren und das geht so :

root@sysresccd /root % tune2fs -U a69f37c6-4076-411a-bfd2-51701715678c /dev/sda1

und wenn jetzt ein (bzw. dieser) Fehler kommt,

tune2fs 1.42.10 (18-May-2014)
tune2fs: Bad magic number in super-block while trying to open /dev/sda1
Couldn't find valid filesystem superblock.

wird es ernst.


Dann doch erst mal das System booten von der neuen SSD und alle Boot-Fehler ignorieren, bis er komplett hochgekommen ist.

Anmerkung : Das Erstellen und Formatieren der neuen swap Partition sda1 auf der SSD mit "gparted" hatte also nicht geklappt, eine alte Superblock-Version 1 wurde eingetragen und die wird angemeckert.

Der yast partitioner von opensuse leap 42.3 kann es aber richtig. Also mit dem yast partitioner die neue swap partition formatieren und überprüfen :

[virtbox1.inhaus - root] ~ $ blkid -o list
device fs_type label mount point UUID
-----------------------------------------------------------------------------------------------
/dev/sda1 swap [SWAP] - d7be8902-c777-46f8-a228-adda5a07ffc7
/dev/sda2 ext4 / - d7bc7dbd-7902-4835-8661-3905b5732f4e
/dev/sda5 xfs /usr/sda5-20GB - 65f9e98d-9142-40d1-bb5b-2dd2b525d4be
/dev/sda6 xfs /usr/sda6-40GB - d068a579-7ce3-4241-a601-6c494bcd5791
/dev/sda7 xfs /usr/sda7-60GB - 724c9bef-3bab-4bbf-b1a6-f81654814d04
[virtbox1.inhaus - root]

Wir sehen, daß die UUID der Partition sda1 schon wieder unterscheidlich ist und auch nicht mit der originalen UUID übereinstimmt. Doch yast hat beim Formatieren und dann beim Abspeichern den /etc/fstab Eintrag auch mit korrigiert !!!. Ich muß da also von Hand nicht mehr eingreifen.

Die Kontrolle des fstab Inhaltes zeigt :

UUID=d7be8902-c777-46f8-a228-adda5a07ffc7 swap swap defaults 0 0
UUID=d7bc7dbd-7902-4835-8661-3905b5732f4e / ext4 acl,user_xattr 1 1
UUID=d068a579-7ce3-4241-a601-6c494bcd5791 /usr/sda6-40GB xfs defaults 1 2
UUID=65f9e98d-9142-40d1-bb5b-2dd2b525d4be /usr/sda5-20GB xfs defaults 1 2
UUID=724c9bef-3bab-4bbf-b1a6-f81654814d04 /usr/sda7-60GB xfs defaults 1 2

Jetzt stimmen die UUIDs aller Partitionen alle wieder mit der von yast aktualisierten fstab Tabelle überein und !!!! die 3 UUID Einträge unserer drei VMs stimmen mit den Einträgen im Virtbox-Manager überein. Ein "reboot" zeigt jetzt keinen ernsthaften Fehler mehr an und startet extrem schnell.

Das Linux leap 42.3 System startet bei mir von nun an ohne Fehler und auch noch ganz erstaunlich schnell.
.
Im Übrigen habe ich den Linux Boot-Vorgang im grub2 Bootmanager komplett sichtbar (am Bildschirm ablaufend) eingestellt. Ich will immer sehen, was da abgeht, auch wenn es auf diesem 4-Kern PC sehr sehr schnell abläuft.
.

Man muß sich immer nach der Installation bzw.einer Änderung alle UUIDs der funktionierenden und laufenden Virtualbox- Umgebung sowie die fstab Tabelle (mit Hilfe einer SSH Konsole) anzeigen lassen und aus dieser Konsole komfortabel in eine Textdatei rüberkopieren bzw. abspeichern. Das geht mit "putty" am komfortabelsten.

Bei der Rücksicherung der Images der Partitionen auf eine neue ungebrauchte Platte bleiben die UUIDs des Linux root-Systems und der jeweiligen VM Images erhalten. Die UUID der swap Partition muß mit opensuse yast korrigiert werden und sicherheitshalber mit der neuen fstab Tabelle verglichen werden.

Die im Virtmanager der Virtualbox eingetragenen und angezeigten VMs und deren UUIDs der Partitionen (sowie der darin enthaltenen Dateien) müssen mit denen in den VMS übereinstimmen, werden aber sowieso bei der Rücksicherung der Images mit der aktuellen clonezilla Version im original rückübertragen bzw. nicht verändert.
.
Und hilfreich bzw. ganz wichtig beim Umstieg oder einer Rücksicherung, in einer separaten Textdatei auf einem 2. PC jeden Schritt und jedes Kommando protokollieren.
.