Anbieter zum Thema
Die Arbeit mit Clonezilla
Um nun mit Clonezilla arbeiten zu können, ist es erforderlich, die Lösung mit ins Client-Boot-Menü einzutragen. Das läuft über das Skript
/opt/drbl/sbin/dcs
Dieses fragt nach dem Start zunächst, ob die nun kommenden Konfigurationsänderungen für alle Systeme gelten, oder nur für bestimmte - per IP- oder MAC-Adresse definierte - Rechner in Kraft treten werden. Danach stehen verschiedene Modi zum Eintrag ins Boot-Menü zur Auswahl, nämlich der Speichertest, das entfernte Starten von FreeDOS, Boot von der lokalen Festplatte, Shutdown, Wake-on-LAN und eben Clonezilla.
Nach der Selektion von Clonezilla möchte das System wissen, ob es sich um einen Sicherungs- oder einen Restore-Vorgang handelt oder ob die diesbezügliche Auswahl auf den Clients vorgenommen wird. Die ersten beiden Einträge ermöglichen beispielsweise das einfache Ausführen von Rollouts praktisch ohne Eingriffe der IT-Abteilung, während der letzte Eintrag direkt auf dem Client nach dem Start der Clonezilla-Software fragt, was zu machen ist.
Für unseren Test entschieden wir uns zunächst für die interaktive Variante. Im nächsten Schritt bringt das Skript den Image-Namen und das zu sichernde Harddisk-Device in Erfahrung. Auch hier können die Administratoren wieder dafür sorgen, dass die entsprechende Abfrage auf dem Client erfolgt. Nun kommt die Reihenfolge dran, in der Clonezilla die einzelnen Cloning-Utilities auf die Clients loslässt. Standardmäßig ist das zuerst ntfsclone, dann Partition Image und zum Schluss dd.
Das lässt sich aber an die Anforderungen der jeweiligen Umgebung anpassen. Zum Beispiel ergibt es keinen Sinn, ntfsclone in reinen Linux-Umgebungen zu verwenden. Anschließend geht es an die Definition der „Advanced Parameters“, die beispielsweise das Ablaufen von Skripts vor oder nach dem Clone-Vorgang steuern, oder die das Anlegen von MD5-Checksummen der Images veranlassen. Zum Schluss erkundigt sich das Skript noch, welche Aktion es nach dem Cloning oder dem Restore durchführen soll (Reboot, Shutdown und so weiter), welche Kompression zum Einsatz kommt (gzip, bzip2, etc.) und ab welcher Größe das Image-File in mehrere Dateien aufgeteilt wird. Jetzt ist Clonezilla betriebsbereit.
Im Betrieb
Nach dem Einschalten eines Clients erschien nun das Boot-Menü und fragte, ob wir unser System von der lokalen Festplatte starten, Clonezilla ausführen oder einen Speichertest durchführen wollten. Nach der Auswahl von Clonezilla startete der Rechner über das Netz Linux, fuhr die Clonezilla-Applikation hoch und fragte, ob er eine Rescue-CD erstellen oder Daten sichern beziehungsweise wiederherstellen sollte. Hier entschieden wir uns zunächst für die Sicherung. Jetzt wollte die Lösung die Namen der Image-Datei und der zu sichernden Festplatte wissen. Nachdem wir die angesprochenen Auswahlen vorgenommen hatten, lief der Clone-Vorgang durch und benötigte für unsere Installation mit etwa sechs GByte an Daten knapp zehn Minuten.
Der Restore-Vorgang funktioniert analog. Nach dem Start von Clonezilla entscheidet sich der Administrator hier aber für die Wiederherstellung, woraufhin die Software die vorhandenen Images anbietet und wissen will, wie die Partitionierung der Client-Festplatte ablaufen soll. Clonezilla ist folglich – anders als andere Tools dieser Art – dazu in der Lage, auch Festplatten zur Restore zu nutzen, die völlig unbenutzt und nicht mal partitioniert sind. Für die Partitionierung gibt es verschiedene Optionen, nämlich das Nutzen der Partitionstabelle aus dem Image, das manuelle Anlegen einer Partition durch den Administrator oder das automatische Erweitern einer Partition auf die maximale Größe der Zielfestplatte. Clonezilla kann also Images auf Systeme mit größeren Festplatten als das Original zurückspielen und dabei die Partitionen gleich so anpassen, dass der gesamte Speicherplatz im Betrieb zum Einsatz kommt. Nach dem Abschluss der Angaben zur Partitionierung lief die Wiederherstellung im Test ohne Probleme durch.
weiter mit: Fazit
(ID:2021779)