ZFS Backup auf neue HDD

schorsch_76

schorsch_76

FreeBSD Fanboy
Hallo zusammen,

nicht zur Strafe sondern nur zur Übung hab ich gestern mal mein ZFS Backup auf eine neue Platte spielen wollen um zu sehen ob ich im Fehlerfall auch alles hin bekomme. Leider Hab ich noch ein Problem :confused:

Ich habe die Partitionstabelle mit "gpart show ada2 > ada2.txt" ins backup gepackt. Es handelt sich um eine GPT Tabelle.
ada2p1 = EFI (200M)
ada2p2 = freebsd-swap (2G)
ada2p3 = freebsd-zfs

p1+p2 hab ich per "dd if=/dev/ada2p(1|2) of=ada2p(1|2).img bs=1M" gesichert. zroot per
zfs -r zroot@backup zfs send -R zroot@backup > /mnt/backupspace

Soweit so gut dachte ich.

Mit einem 13.1-RELEASE USB Stick bewaffnet hab ich die alte Platte entfernt und gegen die neue Platte ersetzt. Im LiveCD Modus (großes image vom Download) hab ich eine neue Tabelle angelegt.
gpart create -s gpt ada2 gpart add -i 1 -t efi -s 200M ada2 gpart add -i 2 -t freebsd-swap -s 2G ada2 gpart add -i 3 -t freebsd-zfs ada2

Dann ada2p1und p2 per dd aufgespielt und anschließend das zroot aufgespielt

zpool create zroot -R /tmp/zroot /dev/ada2p3 nc -l 0.0.0.0 10000 | zfs receive -Fuv zroot (vom Backup Space das Backup zugespielt)

Daten waren da und ich dachte ich bin fertig. Der loader.efi wurde per "UEFI Bootmenü" gestartet. Jetzt geht das erste Problem los: Der loader kann den Kernel nicht finden. "currdev=zfs:zroot:". mit "set currdev=zfs:zroot/ROOT/default:" und einem "boot" wird der Kernel gestartet aber der Kernel findet das rootfs nicht. Er beschwert sich das wohl vfs nicht passt (hab die Meldung gerade nicht 100% im Kopf und leider kein Foto).

Nach dem Studium von man uefi dachte ich, dass ich eigentlich alles hätte... Bei GPT gibt es doch kein Bootflag mehr. Das ist ein reines UEFI Setup. Im BIOS ist der Bootmode auf UEFI only gesetzt. Die alte Platte bootet 1a.... In der loader.conf ist auch kein "vfs=... " eingetragen. Ich kann mich dunkel erinnern das ich bei Experimenten mit dem Pi4 und FreeBSD da mal was gebraucht hatte....

Wo hab ich einen Fehler gemacht? :o
 
schorsch_76 schrieb:
In der loader.conf ist auch kein "vfs=... " eingetragen. Ich kann mich dunkel erinnern das ich bei Experimenten mit dem Pi4 und FreeBSD da mal was gebraucht hatte....
Zum Vergrößern anklicken....
Das braucht man nicht mehr. :) Und das wird auch der Fehler sein. Es ist jetzt ein Pool Property, was auf dem Bootpool gesetzt wird: zpool set bootfs=zroot/ROOT/default zroot Macht man es anders, funktionieren Boot Environments nicht.
 
schorsch_76 schrieb:
zfs send -R zroot@backup > /mnt/backupspace
Zum Vergrößern anklicken....
Noch ein Tipp: Sowas sollte man vermeiden. Stattdessen besser gleich in ein zfs receive pipen. Denn zfs receive bricht eiskalt beim ersten gekippten Bit ab. Auch wenn das nur in einer Filmdatei ist, wo es niemanden interessiert. Dann geht das Hacken vom Quellcode los, um den Fehler zu überspringen. Hab ich gemacht, war nicht schön... Wenn man es gleich wieder in ein Dateisystem ausschreibt, weiß man sofort, wenn beim Senden was schief gegangen ist. Und wenn durch die Lagerung im Schrank später ein Bit gekippt ist, ist zwar eine Datei futsch, aber nicht das ganze Backup.
 
Yamagi schrieb:
Noch ein Tipp: Sowas sollte man vermeiden. Stattdessen besser gleich in ein zfs receive pipen. Denn zfs receive bricht eiskalt beim ersten gekippten Bit ab. Auch wenn das nur in einer Filmdatei ist, wo es niemanden interessiert. Dann geht das Hacken vom Quellcode los, um den Fehler zu überspringen. Hab ich gemacht, war nicht schön... Wenn man es gleich wieder in ein Dateisystem ausschreibt, weiß man sofort, wenn beim Senden was schief gegangen ist. Und wenn durch die Lagerung im Schrank später ein Bit gekippt ist, ist zwar eine Datei futsch, aber nicht das ganze Backup.
Zum Vergrößern anklicken....
Du meinst, das Backup sollte ein zpool sein? In meinem Fall ist das Backup ein Sambalaufwerk auf ZFS. Ich hab dort einen Folder in dem die Dateien wie zpool.20220317.zfs.gz liegen.
 
Das wäre dann natürlich besser:
Example 13: Using the zfs receive -d Option
The following command sends a full stream of poolA/fsA/fsB@snap to a
remote machine, receiving it into poolB/received/fsA/fsB@snap. The
fsA/fsB@snap portion of the received snapshot's name is determined from
the name of the sent snapshot. poolB must contain the file system
poolB/received. If poolB/received/fsA does not exist, it is created as
an empty file system.
# zfs send poolA/fsA/fsB@snap |
ssh host zfs receive -d poolB/received
Zum Vergrößern anklicken....

zfs(8)

www.freebsd.org www.freebsd.org

Das hält die Daten einfach zugreifbar und Bitrot trifft nur einzelne Dateien und nicht den Rest. Da hat @Yamagi :belehren: sicher recht und wie beschrieben hart selbst erfahren. Wenn ich darüber nachdenke: An dieses Problem habe ich nicht gedacht. Ein zweites dickes Danke! :)
 
Kein Problem. :) Das sind mit Schmerzen gemachte Erfahrungen. Bei mir war es der Klassiker: Immer schön Backup geschrieben, auch getestet und die Platte in so einer staubdichten Schutzhülle im Schrank gelagert. Vielleicht nicht perfekt, aber halt der Ablauf, den man zu Hause macht. Dann musste ich zurückspielen und es ging nicht, weil in dem Stream ein Bit gekippt war. Da sich nicht rausfinden ließ, welche Stelle im Stream es war, habe ich dann das Kernelmodul gehackt... Was genau der Fehler war, habe ich nie rausgefunden. Das die Platte das Bit gekippt hat, kann eigentlich nicht sein. Das sollte als nicht korrigierbarer Fehler im SMART auftauchen. Sollte. Vielleicht der Controller oder das Kabel beim Schreiben. Zumindest habe ich seitdem ein engeres Backupkonzept mit zwei Offside-Kopien.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben