Clone live System

pom

Well-Known Member
Hallo,

ich möchte mein komplettes System (Platte) auf eine mvme übertragen.

Laufendes System:
zroot ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada1p3 ONLINE 0 0 0
ada0p3 ONLINE 0 0 0


Ziel:
# gpart show
=> 40 1953525088 nvd0 GPT (932G)
40 1024 1 freebsd-boot (512K)
1064 1953524064 2 freebsd-zfs (932G)



# zpool import
pool: tank
id: 6296111688399919208
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:


tank ONLINE
nvd0p2 ONLINE


Mir ist klar, dass das Ziel (tank auf MVME) kein Mirror ist. Ist aber erstmal egal.

Folgendes habe ich schon gemacht:
pool auf MVME angelegt (siehe oben)
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 nvd0
zpool import -fR /mnt tank


Ist folgendes der richtige Weg:
zfs snapshot -r zroot@backup

Wie bekomme ich den Snapshot jetzt auf die importierte MVME?

zfs send -R zroot@backup | zfs recv xxxx

Wie muss der Rest des recv Befehls ausehen damit alles unter /mnt landet? Der Snapshot nimmt alles Datasets von zroot mit - oder (d.h. z.B. /home das unter zroot/home liegt)?

zpool set bootfs ... was muss ich hier tun?

Und wie exportiere ich die MVME wieder und mach dem System klar, dass es dann von "tank" booten soll?

Oder würde man das sowieso besser anders machen?

Danke,
Peter
 
mach dem System klar, dass es dann von "tank" booten soll?
das habe ich auch noch nicht so wirklich verstanden.

Aber, ganz wichtig zunächst: bootest du (U)EFI oder Legacy (BIOS)?
du hast nämlich die nvme bisher für BIOS und nicht für EFI präpariert.

Mir ist bei inzwischen bei drei Rechnern aufgefallen, dass es doch besser ist, im EFI-Modus zu booten, weil dabei die Auflösung der Konsole auf eine Art und Weise gesetzt wird, die es mir dann ermöglicht, später aus dem laufenden X auf diese zuzugreifen.
Das geht natürlich nur bei Rechnern, die schon EFI können aber wenn sie nvme können, machen sie sicher auch EFI.

Ich habe das gerade eben erst für einen Rechner auf EFI durchexerziert und es hat funktioniert. Ob das gut ist, was ich gemacht habe, weiß ich auch nicht. Ich habe nicht so viel gelesen (diesmal) und mir viele Kommandos einfach aus meiner Mitschrift vom Umzug meines Systems auf SSD kopiert. Das war allerdings BIOS. Nun musste ich das auf EFI bringen und wie gesagt, es hat funktioniert.

Was ich am wenigsten verstanden habe:
-Wie ich dem System beibringen soll, einen bestimmten Pool zu booten und dann auch nur diesen zu nutzen.
-Welche Eigenschaften des alten Pools in den neuen übernommen werden (mit zfs send | recv) und im Umkehrschluss, was tatsächlich vorab gesetzt werden muss.
-Wann genau man das bootfs setzen muss.

Was du zusätzlich liefern solltest ist ein gpart show der aktuellen Konfiguration, die du ja nachbauen möchtest. Hast du die nachgebaut, werden die Daten, also der alte Pool, mit zfs send | recv überspielt, anschließend dieser evtl gemounted, um Sachen wie die rc.conf, fstab und loader.conf anzupassen, bevor man neu bootet.
Das BIOS-UEFI muss das Gerät (nvme) als Bootdevice natürlich akzeptieren und es muss entsprechend gesetzt sein.
Das alles ist kein großes Problem.
Aber, was mir bei meinen Tests passierte: ein System von USB (der Klon des laufenden Systems) nahm automatisch auch das alte System wahr und band auch diesen Pool mit ein, so dass einige DataSets quasi aus zwei unterschiedlichen Pools auf die gleichen Verzeichnisse verwiesen hatten. Ich habe das schnell durch Auswurf des einen Pools korrigieren können, aber das solltest du vorher besser genauer geklärt haben.
Also, was du so ungefähr machen solltest (EFI), zeige ich einfach aus meiner Mitschrift mal, vollkommen unverbindlich und ohne GWL und eben, wie ich es mir gedacht hatte. Das war ein Klon aus einem System auf ein USB-Gerät:
Code:
#USB-Gerät da0 vorbereiten:

gpart create -s gpt da0

gpart add -t efi -l efi -a 1m -s 40m da0

gpart add -b 1m -t freebsd-swap -l swap -a 1m -s 4g da0

gpart add -t freebsd-zfs -l mileno -a 1m da0

#füllen:

gpart bootcode -b /boot/pmbr -p /boot/boot1.efifat -i 1 da0 #wichtig ist die Efi-Partition mit allem drin, nicht der pmbr

zpool create -R /tmp/mileno mileno /dev/da0p3 #einen temporären mountpoint für den Pool mileno mitgeben
#einige Einstellungen, die ich immer setze und wo ich nicht weiß, ob die vom alten Pool übernommen worden wären:
zfs set compression=lz4 mileno
zfs set checksum=fletcher4 mileno
zfs set atime=off mileno

zfs send -R zroot@backup | zfs recv -Fduv mileno #den aktuellen backup vom alten zroot zum neuen mileno

zfs mount mileno/ROOT/default && mount | grep mileno #mounten und sehen, ob der tatsächlich geklappt hat
# bei mir: mileno/ROOT/default on /tmp/mileno

cd /tmp/mileno && ls #sieht man die Verzeichnisse, dann

#ACHTUNG!!! relativen Pfad!
ee etc/rc.conf
ee boot/loader.conf
ee etc/fstab
...

cd ..
zfs umount mileno/ROOT/default

zpool set bootfs=mileno/ROOT/default mileno #hätte vielleicht auch zuvor passieren können

zfs set mountpoint=/mileno mileno #hatte nicht gewirkt, machte ich dann im System, das vom neuen Medium lief nochmal
                                  #das setzt nur den mountpoint neu, ansonsten wird der alte genommen, was nicht schlimm ist

zpool export mileno

edit: Nachsatz: in meiner loader.conf steht ja so etwas wie:
Code:
vfs.root.mountfrom="zfs:mileno/ROOT/default"
das sollte eigentlich sagen, welcher Pool geladen wird, also von welchem gebootet werden soll.

edit2: den Label der efi-Partition kann man sich auch schenken. Soweit ich sehe wird der automatisch zu EFISYS umgeswitched, wenn die Partition nicht manuell mit Leben gefüllt wird. Aber das Schreiben von boot1.efifat ist wirklich elegant und Fehlerfrei und viel schneller, als Handarbeit.
 
Hallo pit234a,

danke für die ausführliche Rückmeldung. Ich habe mich entschlossen ein neues System auf die NVME zu zu installieren und die Daten aus /etc /usr/local/etc ... per rsync rüberzuziehen.

Hat auch gut geklappt.

Gruß,
Peter
 
Mal so im Nachtrag, mein aktuelles System ist durch einen Live Umzug entstanden. Einfach die NVMEs zum zfs mirror hinzufügen und nach dem resilver die alte Platte aus dem pool entfernen. Das funktioniert am laufenden System ohne reboots (dank swapon/swapoff auch mit der swap Partition). Alternativ kann man mit zpool split den Pool forken und zukünftig unabhängig voneinander weiterleben lassen.
 
Zurück
Oben