Folge dem Video um zu sehen, wie unsere Website als Web-App auf dem Startbildschirm installiert werden kann.
Anmerkung: Diese Funktion ist in einigen Browsern möglicherweise nicht verfügbar.
# Löscht ALLE Partitionen und Daten auf /da/d0
gpart destroy -F da0
# Erstelle eine leere GPT und 3 Partitionen
gpart create -s gpt da0
gpart add -t freebsd-boot -s 256 -l uboot da0
gpart add -t freebsd-swap -s 512M -l uswap da0
gpart add -t freebsd-ufs -l uroot da0
# Den Bootcode schreiben
gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0
# Dateisystem anlegen
newfs -U /dev/gpt/uroot
Jepp, tun sie. 'newfs -L' geht nach /dev/ufs/ und 'gpart add -l' nach /dev/gpt/. Gerade bei Wechseldatenträgern ist es sehr sinnvoll Label zu nutzten, da sich der Device-Name selbst ja auch mal ändern kann.Ich gehe dabei davon aus, dass diese Label wie Dateisystemlabel (mit newfs -L) wirken. Letztere fand man allerdings dann zB in /dev/ufs/Label.
Danke dir, ich hab alles genau so gemacht wie du es hier beschrieben hast und ich hab nicht vergessen das Device da0 anzupassen
Du kannst nach dem Login eine screen Sitzung öffnen, und diese ablösen, oder nach nohup die Kommandos in den Hintergrund legen, in beiden Fällen läuft dein Backup weiter. Im zweiten Fall lasse ich die Ausgaben noch in ein File laufen (tcsh):Du kannst rsync natürlich nutzen und auch später noch Dateien synchron damit halten. Es arbeitet aber anders, als dump. dump, wenn ich das noch richtig weiß, macht eine Art Snap und kopiert dann genau einen Status der Dateien. Wenn sich während rsync was ändert, kann die Information im Ziel schließlich asynchron landen und in einem ganz schlimmen Fall könnte dadurch das Ziel nicht booten oder gar unbrauchbar sein.
nohup dump ... | restore ... >& datei.txt &
Zur Geschmacksfrage ob dump oder restore:
Du kannst nach dem Login eine screen Sitzung öffnen, und diese ablösen, oder nach nohup die Kommandos in den Hintergrund legen, in beiden Fällen läuft dein Backup weiter. Im zweiten Fall lasse ich die Ausgaben noch in ein File laufen (tcsh):
Die Label kannst du nachträglich mit tunefs oder glabel bearbeiten, bin mir gerade nicht sicher, aber das geht imho nur im SingleUser.Code:nohup dump ... | restore ... >& datei.txt &
Edit: Label Ergänzung & Typo
Ja, du kannst das UFS mit dump(8) sichern und mit restore(8) auf ZFS zurückspielen. Das geht sogar per Pipe, ungefähr so:
Code:cd /pfad/zum/neuen/zfs/root dump -0 -af - /dev/$ufs_root | restore -rf -
du hast doch ein bootfähiges UFS auf deiner externen Platte erstellt, mit ZFS geht das analog, nur eben mit ZFS.
Grundsätzlich.
Du hast einen eingebauten HW-Raid und davon will auch bei meinem Rechner ZFS einfach nicht booten. Ich habe den Raid abgeschaltet, also, die HW ist natürlich noch da, aber ich nutze nicht das HW-RAID. Das macht auch gar keinen Sinn mit ZFS. ZFS kann das viel besser, als eine HW und ist letztlich auch sicherer.
Was ich sagen will: es kann sein, dass es einfach misslingt, ein ZFS von deiner HW zu booten, obwohl du alles richtig eingerichtet hast.
Ein einfacher Test wäre, wieder mal auf ein externes Medium zu testen, analog zu dem Versuch mit UFS. Gelingt dies, aber intern über HW-Raid nicht, dann wäre es vielleicht möglich, von einem USB-Gerät zu booten (so mache ich das im Augenblick).
Man will auch kein Hardware-RAID mit ZFS. Damit kombiniert man nur das Schlechte beider Welten.
Alles, was du zu Raid sagst, kann man natürlich nur unterstreichen.
Der einzige Fehler: ZFS macht das alles ebenso und vollkommen ohne HW-Kontroller und deshalb eben besser.
Du kannst bei einem ZFS (in Abhängigkeit verfügbarer Devices natürlich) quasi jede Raid-Konfiguration haben. Ich habe zB in meinem PC inzwischen vier Platten zu einem einzigen Mirror verbunden. In meinem NAS habe ich fünf Platten zu einem "Zraid-5" zusammengelegt, also nur eine Platte Redundanz. ZFS ist da super flexibel und einfach zu handhaben. Sowohl das Erweitern eines Pools als das Ersetzen einzelner Platten gelingt wenigstens so einfach, wie mit einem HW-Kontroller.
Nur, beim HW.Kontroller bist du absolut abhängig davon, dass der auch funktioniert und wenn er mal versagt, kannst du nur mit einem gleichen Kontroller wieder auf die Daten zugreifen, wenn überhaupt. Beim ZFS-Pool kannst du den einfach in einen neuen PC hängen und gut ist. Beispielhaft und vereinfacht gesagt.
ZFS ist:Mir scheint, dass ZFS wie ein Volume-Manager ist
ZFS ist:
* ein Software-RAID
* ein Volume Manager
* ein Dateisystem
Alles in einem. Deswegen will man das ja haben
Und natürlich kannst du ein ZFS Pool auch auf einen RAID Device legen, nur wird das halt nicht empfohlen, weil ZFS besser läuft wenn es um die Plattentopologie weiß.
FreeBSD erkennt den HW-Raid Kontroller und bindet automatisch graid ein. das ergibt dann ein virtuelles LW in /dev/raid/r0 Mit graid kann dann der status abgefragt und auch den Chip im Mainboard konfiguriert werden. Zum beispiel eine weitere Platte einbinden.Sind ada0 und ada1 jeweils Hardware RAID Volumes? Oder direkt die Platten? In dem Fall ist der RAID Controller dann ja nur einfacher Plattencontroller mit Cache.
root@superserver:/compat/linux/downloads # graid status
Name Status Components
raid/r0 OPTIMAL ada0 (ACTIVE (ACTIVE))
ada1 (ACTIVE (ACTIVE))
root@superserver:/compat/linux/downloads # graid list -a
Geom name: Intel-240382fb
State: OPTIMAL
Metadata: Intel
Providers:
1. Name: raid/r0
Mediasize: 121653690368 (113G)
Sectorsize: 512
Mode: r2w2e5
Subdisks: ada1 (ACTIVE), ada0 (ACTIVE)
Dirty: Yes
State: OPTIMAL
Strip: 65536
Components: 2
Transformation: RAID1
RAIDLevel: RAID1
Label: SSD RAID 1
descr: Intel RAID1 volume
Consumers:
1. Name: ada0
Mediasize: 128035676160 (119G)
Sectorsize: 512
Mode: r1w1e1
ReadErrors: 0
Subdisks: r0(SSD RAID 1):1@0
State: ACTIVE (ACTIVE)
2. Name: ada1
Mediasize: 128035676160 (119G)
Sectorsize: 512
Mode: r1w1e1
ReadErrors: 0
Subdisks: r0(SSD RAID 1):0@0
State: ACTIVE (ACTIVE)
Wir verwenden essentielle Cookies, damit diese Website funktioniert, und optionale Cookies, um den Komfort bei der Nutzung zu verbessern.
Siehe weitere Informationen und konfiguriere deine Einstellungen