[teilweise gelöst] Debian Klonen

[joe2017]

Hallo Zusammen,

hat jemand Erfahrung mit dem Klonen von debian? Ich muss ca. 150 Debian Installationen bereitstellen und wollte hierzu einfach die vorhandene MASTER Installation Klonen.

Ich hab das jetzt mit CLONEZILLA und DD getestet. In beiden fällen wird durch das Klonen der /dev/sdb zu /dev/sdc die gesamte Festplatte geklont. leider auch der nicht benutzte Speicherplatz.
Gibt es eine Möglichkeit nur den verwendeten Speicher zu klonen? Bei DD habe ich jetzt nichts gefunden. Ich könnte zwar die Partition klonen. Jedoch muss ich hierzu auch sämtliche Partitionen auf der leeren Festplatte anlegen oder?

Gibt es hierzu eine einfache Lösung?

[ThorstenS]

Wir haben einen Wikieintrag dazu: Vollständiges_Sichern_einer_ganzen_Platte
Ich empfehle dir vor einem blockbasierten Clonen zerofree über deinen master laufen zu lassen.
Wenn du pv benutzt, nimm ein tool zum Komprimieren, welches mehrere CPUs auslasten kann, wie z.B. pigz

Ich arbeite gerne mit clonezilla, eben weil es nicht stumpf blockbasiert sichert, sondern bei unterstützten Dateisystemen nur belegte Blöcke sichert.

Wenn du diese 150 Installationen immer wieder mal resetten/erweitern sollst, würde ich mir allerdings dringend einen anderen Weg ausdenken.
Meine Empfehlung lautet [url=https://fai-project.org/]fai[url] und ggflls weitere Anpassungen mit ansible einspielen.

[joe2017]

Ich habe folgendes gefunden und einmalig getestet.

Ich habe eine 240GB große SSD. Nach meiner Installation bekomme ich mit sudo du -sh / angezeigt das ich 4,6GB in Verwendung habe.

Wenn ich folgendes ausführe dauert das ganze ca. 25 Minuten. Hier wird die gesamte SSD geklont (240GB).

Code: Alles auswählen

sudo dd if=/dev/sdb of=/dev/sdc bs=64K status=progress

Mit folgendem Befehl hat das ganze vielleicht 3 Minuten gedauert. Hier wird nur 6GB geklont.

Code: Alles auswählen

sudo dd if=/dev/sdb of=/dev/sdc bs=1M count=6144 status=progress

In meinem ersten Test sah alles bestens aus. Hat jemand von euch Erfahrungen hiermit?

[joe2017]

Ich arbeite gerne mit clonezilla, eben weil es nicht stumpf blockbasiert sichert, sondern bei unterstützten Dateisystemen nur belegte Blöcke sichert.

clonezilla habe ich auch bereits getestet (device to device). Leider hat dies auch ca. 25 Minuten gedauert. Somit wurden hier wohl auch die leeren Blöcke gesichert. Muss man explizit angeben, dass leere Blöcke nicht gesichert werden?

[Buerste]

Ob das eine gute idee ist weiss ich nicht aber ich werfe es mal in den Raum...
Die zu klonende FP/Partition einfach mit https://sourceforge.net/projects/qt4-fsarchiver/ sichern (sichert nur den belegten Speicherplatz) und lässt sich auf jede x-beliebige FP zurückspielen. Unterschiedliche große FP's oder Partitionen werden beim zurückspielen automatisch angepasst. Klappt aber nicht mit UEFI (FSArchiver erkennt die spezielle UEFI Partition nicht).

[DeletedUserReAsG]

Ich habe folgendes gefunden und einmalig getestet.
[…]

Es gibt keinerlei Garantie, dass die Daten sich am Anfang der Partition befinden. Hingegen gibt’s ’ne Garantie, dass das nach einiger Zeit ganz sicher nicht mehr so sein wird – selbst, wenn’s mal so gewesen sein sollte. Dein Image ist so oder so kaputt, wenn du nur den ersten Teil eines FS kopierst.
Wenn du den Weg über ein Image gehen willst, dann verkleinere die betreffende Partition und das darauf befindliche FS auf die Größe der Daten, und blase sie auf dem Zielsystem halt wieder wunschgemäß auf. Dann ist die Wahrscheinlichkeit für Datenverlust und kaputte Dateisysteme schonmal erheblich geringer als die 100%, die sie bei deiner Methode wäre.

Sinnvollere Vorschläge als das Hantieren mit dd, obwohl dessen Kernfunktionalität explizit nicht gewünscht wird, wurden hier ja schon gemacht.

[ThorstenS]

clonezilla habe ich auch bereits getestet (device to device). Leider hat dies auch ca. 25 Minuten gedauert. Somit wurden hier wohl auch die leeren Blöcke gesichert. Muss man explizit angeben, dass leere Blöcke nicht gesichert werden?

· Hast du zerofree laufen lassen? Das ist essentiell wichtig.
· Bei device2device brauchst du imho keine Komprimierung - hast du die abgeschaltet?
· clonezilla benutzt nur als fallback, sprich wenn es das Dateisystem NICHT erkennt, dd. Ansonsten wird immer ein tool benutzt, welches nur die eigentlichen Daten sichert¹.

clonezilla ist meiner Meinung nach die einfachste und schnellste Möglichkeit ein System stumpf zu klonen. Wenn ich kein Netzwerk habe, mache ich das über eine ext. USB3 Platte mit clonezilla auf der 1. Partition und den Imagen auf der 2. Das Zurückspielen dauert bei 60GB Daten weniger als 10 Minuten. Das Erstellen des Images kann natürlich eine Weile in Anspruch nehmen, wenn du eine zu hohe Komprimierung eingestellt hast. Aber dank pigz werden alle verfügbaren Kerne benutzt.

[1]lies apt show partclone. Das ist in den Recommends von clonezilla aufgeführt…

[wanne]

Gibt es hierzu eine einfache Lösung?

Ganz so einfach ist sie nicht. Aber:
Zu kannst je nach Dateisystem den Inhalt einzelnen Partitionen kopieren (von sdx nach sdy)
ext: e2image -ra /dev/sdxX /dev/sdyX
btrfs: btrfs send /home | btrfs recive /media/nwohome # Wohlgemerkt: Das erwartet eine schon formatierte btrfs-Partition. (Erspart das verkleinern.)
ntfsclone: ntfsclone -O /dev/sdyX nach /dev/sdxX # Man achte auf die verdrehten argumente
Ändert nichts daran dass das Dateisystem gleich groß bleibt. Die meisten Dateisystem (außer xfs) kannst du aber ohne probleme vorher verkleinern.(Du musst nur das Dateisystem nicht die Partitionen verkleinern.) (je auf 2 GiB)
ext: resize2fs /dev/sdxX 2G
btrfs: btrfs filesystem resize 2G /dev/sdxX
ntfs: ntfsresize --size 2G /dev/sdxX

Das nächste Problem ist, dass du falls du per BIOS und nicht UEFI bootest noch den bootloader kopieren musst.
Das geht mit

Code: Alles auswählen

head -c 440 /dev/sdx > /dev/sdy

Du musst also der Reihe nach
1. Neue (kleinere) Partitionen auf neuer Platte anlegen.
2. Die Dateisysteme auf alter Platte so weit verkleinern, dass die auf die Partitionen der neue platte passen.
3. Dateisysteme Kopieren.
4. Bootloader kopieren.
5. Die Dateisysteme im Original.Plattte wieder vergrößern.

Ich gehe immer so vor, dass ich deutlich stärker verkleinere als nötig und danach wider sowohl auf der neuen wie auch auf der alten Platte maximiere. Dann hat man keine Probleme damit, dass man durch irgend welche rundungen zu klein wird. Btrfs brauch die Verkleinerung im übrigen gar nicht. Das passt sich automatisch an.
Maximieren:
ext: resize2fs /dev/sdxX
btrfs: btrfs filesystem resize max /dev/sdxX
ntfs: ntfsresize /dev/sdxX

[joe2017]

· Hast du zerofree laufen lassen? Das ist essentiell wichtig.
· Bei device2device brauchst du imho keine Komprimierung - hast du die abgeschaltet?
· clonezilla benutzt nur als fallback, sprich wenn es das Dateisystem NICHT erkennt, dd. Ansonsten wird immer ein tool benutzt, welches nur die eigentlichen Daten sichert¹.

• Zerofree hab ich nicht laufen lassen. Das kannte ich aktuell noch nicht. Bringt das clonezilla mit? Oder muss ich hierzu eine zu klonende SSD an mein Linux anschließen, mounten, und dann zerofree über den mountpoint laufen lassen?

• Ist die Komprimierung standardmäßig immer aktiv?

• Hast du zufällig für clonezilla eine commandline?

[ThorstenS]

ad 1)
zerofree habe ich in meinem 1. Post erwähnt und ist im verlinkten WikiArtikel beschrieben

ad2)
ja, im einfachen Modus ist es meiner Meinung nach aktiv.

ad3)
nein, hab ich nicht. Aber kurz vor dem Klonen schreibt dir clonezilla den kompletten Aufruf einmal auf das Terminal. Damit kannst du es beim nächsten Mal aufrufen, ohne durch die Menüs zu gehen.

Ich weiß nicht wie groß dein Druck ist die 150 Maschinen fertig zu bekommen. Aber ich empfehle dir die Tipps der Leute hier aufmerksam zu lesen und dir eigene Notizen zu machen…

[joe2017]

Ich hab das ganze jetzt mal mit zerofree getestet.

Ich lass mir erst einmal meine Festplatten anzeigen.
fdisk -l

Ich sehe meine Platte von der ich gebootet habe und meine angeschlossene Platte welche ich klonen möchte

Code: Alles auswählen

sdb
sdb1 Typ=Linux
sdb2 Typ=Extended
sdb5 Typ=LinuxLVM

sudo zerofree -v /dev/sdb1 funktioniert. Bei /dev/sdb2 und /dev/sdb5 erhalte ich eine Fehlermeldung
Failed to open Filesystem. Anscheinend werden diese nicht von zerofree unterstützt?

[DeletedUserReAsG]

Anscheinend werden diese nicht von zerofree unterstützt?

Meine Glaskugel zeigt „Fehler 42“, mag am Wetter liegen. Könntest du dann schnell verraten, um welche FS es sich denn handelt, damit jemand für dich nachsehen kann, ob es unterstützt wird oder nicht?

[wanne]

Nochmal so als Anmerkung: Zerofree ist ein hässlicher Hack und e2image in allen Hinsichten unterlegen. Genau wie dd ein Relikt aus einer Zeit, die die wohl einige hier nichtmal erlebt haben. Lasst es sein.

[joe2017]

Das bedeutet, du würdest images von den einzelnen Partitionen erstellen und diese auf eine vorbereitete Platte (mit angelegten Partitionen) entpacken?

Kann man so machen.
Aber wie gesagt mit -r kann e2image auch direkt von Partition zu Partition kopieren. Mit dem Unterschied, dass es eben nur genutzte Blöcke kopiert werden.
Wie gesagt:

Code: Alles auswählen

e2image -pra /dev/sdxX /dev/sdyX

Unter der Voraussetzung, dass die Partitionen gleich groß sind.
Von einer kleineren auf eine Größere Partition:

Code: Alles auswählen

e2image -pra /dev/sdxX /dev/sdyX
resize2fs /dev/sdyX

Von einer größeren auf eine Kleinere (Im Beispiel Sind weniger als 20G belegt und die kleienre Partition ist größer als 20G)

Code: Alles auswählen

resize2fs -p /dev/sdxX 20G
e2image -pra /dev/sdxX /dev/sdyX
resize2fs /dev/sdxX
resize2fs /dev/sdyX

Das ganze spiel über einen Image File:

Code: Alles auswählen

e2image -pQa /dev/sdxX - | pigz -1 > /path/image.qcow2.gz
cat /path/image.qcow2.gz | pigz -d |  e2image -pra - /dev/sdxX

Edit: Wer das unnötige cat findet, darf es behalten

[smutbert]

vielleicht trotzdem ein Versuch es zu erklären:

[…]

Code: Alles auswählen

sdb
sdb1 Typ=Linux
sdb2 Typ=Extended
sdb5 Typ=LinuxLVM

[…] Bei /dev/sdb2 und /dev/sdb5 erhalte ich eine Fehlermeldung
Failed to open Filesystem. Anscheinend werden diese nicht von zerofree unterstützt?

Ohne zerofree genau zu kennen, würde ich als allererstes vermuten, dass es daran scheitert, dass weder auf der erweiterten Partition (/dev/sdb2) noch dem logischen Laufwerk darin (/dev/sdb5) ein Dateisystem liegt, jedenfalls nicht direkt.
Erweiterte Partitionen dienen nur dazu die Beschränkung auf 4 (primäre) Partitionen zu umgehen, indem darin logische Laufwerke angelegt werden und das logische Laufwerk könnte zwar ein Dateisystem enthalten, wird in deinem Fall aber offensichtlich als physical Volume für lvm2 verwendet. du müsstest zerofree also vermutlich auf die logischen Volumes von lvm2 loslassen.

Ob es überhaupt eine besonders gute Idee ist physical Volumes mit dd oder clonezilla zu klonenm, wage ich zu bezweifeln – bei manchen Dateisystemen genügt es ja schon ein ganz normales Dateisystem zu klonen um in Teufels Küche zu geraten (zB bei xfs und besonders btrfs, weil die empfindlich reagieren, wenn es plötzlich mehrere Dateisysteme mit derselben UUID gibt).
Überraschungen gibt es unter Umständen noch zusätzlich, wenn ein ganzer Haufen geklonter Systeme, denselben Hostnamen, dieselben ssh-Hostkeys und dieselbe »/etc/machine-id« (bei letzterer weiß ich nicht wofür die verwendet wird) hat.

(ich würde eher Dateien/Verzeichnisse kopieren und mich getrennt um Partitionierung, Formatierung und Bootloader kümmern, eventuell mit einem Skript oder debootstrap/grml-debootstrap verwenden, gegebenenfalls wieder in einem Skript oder ThorstenS Empfehlung folgen und fai und ansible näher ansehen.)

[wanne]

Ob es überhaupt eine besonders gute Idee ist physical Volumes mit dd oder clonezilla zu klonenm, wage ich zu bezweifeln – bei manchen Dateisystemen genügt es ja schon ein ganz normales Dateisystem zu klonen um in Teufels Küche zu geraten (zB bei xfs und besonders btrfs, weil die empfindlich reagieren, wenn es plötzlich mehrere Dateisysteme mit derselben UUID gibt).

Deswegen nimmt man bei btrfs auch btrfs send. Da werden UUIDs nicht mitkopiert.

Überraschungen gibt es unter Umständen noch zusätzlich, wenn ein ganzer Haufen geklonter Systeme, denselben Hostnamen, dieselben ssh-Hostkeys und dieselbe »/etc/machine-id« (bei letzterer weiß ich nicht wofür die verwendet wird) hat.

Wird doch großteils erst nach dem ersten boot erzeugt. Ansonsten ist das eine ziemlich abschließende Aufzählung, was man ändern muss.

(ich würde eher Dateien/Verzeichnisse kopieren und mich getrennt um Partitionierung, Formatierung und Bootloader kümmern, eventuell mit einem Skript oder debootstrap/grml-debootstrap verwenden, gegebenenfalls wieder in einem Skript oder ThorstenS Empfehlung folgen und fai und ansible näher ansehen.)

Ist halt deutlich langsamer. Daneben hat man das roblem, dass man alle ACLS und weiß der kuckuck noch alles mitkopiert ich glaube selbst rsync -AaHaXx erwischt nicht immer alles. Aber ansonsten wahrscheinlich die problemlosere Variante.

[wanne]

Das Thema zur automatischen Installation nach TID 170343 automatische Intsallation verschoben