Backup, UFS, ZFS

Xartax

Well-Known Member
Hallo Leute,

ich hab da mal eine Frage, meine FreeBSD Installation ist auf einem Raid1(r0) mit 2 ssd 128GBit Disks aufgesetzt. Parallel dazu hab ich noch einen Raid5 (da0) MegaRaid mit 3 RedNAS 4TB platten. was 8TB an Speicherplatz ergibt.

Die SSD sind Hot Plug. Jedoch schütz das mein FreeBSD nicht anderen Fehlern. Irgendwie möchte ich das sicherer machen. Dahab ich mir folgendes gedacht (booten geht nur von r0:

1. partition in da0 einrichten und mit zfs formatieren ich nenne die mal da0sx
1.1 / auf die neue da0sx das komplette / Verzeichnis kopieren.
1.2 r0 nur noch zum booten des systems verwenden.

oder
2. irgendwie r0 komplett auf da0 in eine Datei sichern.

oder
3. irgendwie r0s1 von ufs nach zfs migrieren. ach ja, der server hat 16 GByte Ram

ich weiß aber nun nicht was das beste ist. ich würde 3. vorziehen in Kombination von 2.
1. hat auch scharm, auch da könnte man dann eine boot cd herstellen

ach und da fällt mir noch eine 4. Möglichkeit ein:
4. Recovery system einrichten zum wieder herstellen des raid1 auf cd oder im raid5 da0

wie oben schon erwähnt, hab ich keine Ahnung was das beste ist vielleicht eine Kombination von all dem
 
Versuche es so einfach wie möglich zu halten:

Auf das SSD Raid 1 mit 128 GB kommt ein zpool mit dem Basissystem und gut. Wiederherstellung über SingleUser oder Shell einer FreeBSD CD.

Backups über zfs snapshots, send und recive.

Das MegaRaid erhält einen zweiten zpool für deine Daten, Jails, oder was auch immer.

Komplizierter geht immer, aber was soll bei dem Setup schon passieren?
 
Versuche es so einfach wie möglich zu halten:

Auf das SSD Raid 1 mit 128 GB kommt ein zpool mit dem Basissystem und gut. Wiederherstellung über SingleUser oder Shell einer FreeBSD CD.

gibt es eine Möglichkeit das ufs auf dem ssd raid in ein zfs zu migrieren? Komplette Neuinstallation scheidet aus weil der server in Betrieb ist. Eine schrittweise Migration wäre auch denkbar. Zum Beispiel das komplette system auf den Raid5 verschieben, aber von dem kann ich nicht booten, booten dann von cd. Dann wäre das ssd raid für eine Neuinstallation eines zfs frei. Dann wieder zurück verschieben, ist das so möglich oder geht es auch einfacher. Zu Beispiel direktes migrieren des ufs zu einem zfs?
 
gibt es eine Möglichkeit das ufs auf dem ssd raid in ein zfs zu migrieren?
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 -
Ich habe schmerzhaft lernen müssen, dass es immer eine gute Idee das UFS direkt vor dem Aufruf von dump(8) einmal mit fsck(8) zu prüfen. Denn dump(8) reagiert sehr allergisch auf Fehler im Dateisysten, kommuniziert es aber oft nicht.
 
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 -

Da der server im wirk-Betrieb ist und ein längerer Ausfall mehr als peinlich ist, will ich da mit größter Sorgfalt vorgehen. Ich hab da einen Plan jedoch weiß ich nicht ob der auch gut ist.

1. System komplett auf eine andere Disk UFS-Partition kopieren. Wie ?
2. Eine Boot CD Herstellen mit allen notwendigen Treibern. Wie ?
3. Die alte UFS Partition durch ein bootfähiges ZFS ersetzen. Wie ?
4. wie oben beschrieben das gesicherte System auf das neue ZFS kopieren.

Ist das ein guter plan?
 
Zuletzt bearbeitet:
1.) wurde vom @Yamagi beantwortet:
cd /pfad/zum/neuen/zfs/root dump -0 -af - /dev/$ufs_root | restore -rf -
Das Handbuch erläutert wie du den Server vom Ziel booten kannst.

2.) Wenn du den GENERIC Kernel nutzt, kannst du dein System mit jedem passenden Image booten, bei spezieller Hardware, also eigenem Kernel hilft dir das Handbuch.

3.) mit dd alles überschreiben, mit bsdinstall den Zpool erstellen

4.) Zurück kopieren wieder wie beschrieben, zwingend prüfen ob in der /boot/loader.conf: das zfs_load="YES" steht, und in der /etc/rc.conf eine Zeile zfs_enable="YES".

Wenn es nicht zeitkritisch ist, spiele das ganze mit einem minimalen System virtuell durch.
 
1.) wurde vom @Yamagi beantwortet:

Danke für deine Antwort. Leider war wohl mein Post missverständlich :(

Wenn ich das System mit dump auf eine andere Festplatte kopiere, kann mein Board nicht von dieser Festplatte booten. Als Bootfähige Systeme stehen das Raid1 mit den ssd oder das DVD LW zur Verfügung. Das Raid1 will ich mit einem ZFS ausstatten, also steht dann als Bootfähiges Laufwerk nur noch das DVD LW zur Verfügung. Auf diese CD soll dann eine minimale Kopie das aktuellen Festplatte jedoch mit dem Unterschied dass in der fstab auf die neue Festplatte verweisen wo das komplette system sich befindet. Und das ist nun das problem, wie stelle ich eine solche CD her? Es muss im Prinzip all das enthalten was das aktuelle system zum booten und initialisieren enthält. Auf eine CD/DVD passt halt nicht das ganze system mit 128 GByte

Oder wäre das ein Ansatz, alle Unterverzeichnisse auf eine andere Partition verschieben, so wie ich es mit /home bereits gemacht habe bis auf das was man zum booten braucht /boot /etc /bin /sbin usw? Das ganze sio weit abspecken bis es auf eine DVD/CD passt? Dann könnte ich von CD/DVD booten?

Wäre es so möglich? Dann muss ich wissen welche Verzeichnisse zum Booten benötigt werden und welche auf eine andere Disk verschoben werden können. :confused:

Ach ja, auf den SAS MegaRaid kann erst zugegriffen werden wenn während des Bootvorgangs der richtige Treiber initiiert wird.
 
Noch einmal der Hinweis, versuche es so einfach wie möglich zu halten:
Die SSD sind Hot Plug. Jedoch schütz das mein FreeBSD nicht anderen Fehlern. Irgendwie möchte ich das sicherer machen. Dahab ich mir folgendes gedacht (booten geht nur von r0:

1. partition in da0 einrichten und mit zfs formatieren ich nenne die mal da0sx
1.1 / auf die neue da0sx das komplette / Verzeichnis kopieren.
1.2 r0 nur noch zum booten des systems verwenden.
Es spricht nichts gegen den Boot vom SSD Raid, das ist flott und redundant. Dir stehen 128 GB zur Verfügung, damit ist ein Basissystem in den nächsten Versionen mehr als zufrieden. Das Aufteilen von Boot und Root ergibt imho keinen Sicherheitsvorteil. Man kann das jetzt kaputt argumentieren, letzten Endes verkompliziert dies das Setup.

Wenn ich deine Ausführungen korrekt interpretiere, dann wünschst du dir eine Migration von UFS zu ZFS. Die Schritte dazu wurden hinreichend erläutert.

Da du nur von r0 oder von DVD booten kannst und der Start vom Raid 5 nur temporär sein soll, würde ich ganz drauf verzichten. LiveCD oder SingleUser starten, Migration wie beschrieben, Stoßgebet absetzen und fertig. Persönlich würde ich das alte System sichern, auf der SSD in den Zpool ein frisches FreeBSD (binär) installieren und entsprechend der alten Konfig einrichten.

Was macht denn der "Wirk-Server" und was ist den das für ein spezieller Treiber um das Mega Raid zu laden? Bzw, wie wird er jetzt geladen?

Zeig doch bitte einen entsprechenden Auszug zum Raid 5 aus dmesg.

Für angepasste Boot Images kann ich dir mfsBSD wärmstens empfehlen. Eigentlich dazu gedacht schlanke Images zu erzeugen, können beim Erstellen komfortabel eigene Treiber und Parameter, bis hin zur fstab, hinzugefügt und angepasst werden. Aber wenn du ans Laufwerk kommst, dann hast du doch lokalen Zugriff und kannst Treiber von Hand laden?!?
 
Wenn ich deine Ausführungen korrekt interpretiere, dann wünschst du dir eine Migration von UFS zu ZFS. Die Schritte dazu wurden hinreichend erläutert.

Richtig, und wenn ich es richtig verstanden habe geht das nicht direkt sondern nur indirekt. Das bedeutet, dass ich das Raid r0 frei für Neuformatierung machen muss. Eine CD ode DVD ist aber readonly, das bedeutet wieder, dass ich alle Verzeichnisse wo das Sytsem reinschreiben will auslagern muss. Das hab ich bereits mit /home /usr/home gemacht. Die beiden Verzeichnisse sind bereits auf dem Raid5.

Was macht denn der "Wirk-Server" und was ist den das für ein spezieller Treiber um das Mega Raid zu laden? Bzw, wie wird er jetzt geladen?
Der Server ist die Verbindung nach draußen, ohne diesen ist zum Beispiel diese Kommunikation nicht mehr möglich. Telefon, Fernsehen, alles geht über diesen Server. Wenn der ausfällt, ist die komplette Verbindung nach draußen abgeschnitten. Kein Telefon, kein Fernsehen, kein Internet, nichte geht dann mehr. Also darf der Ausfall nicht länger dauern als ein reboot. Wenn also eine Boot CD hergestellt wird, dann muss nach dem Reboot von CD das system wieder voll funktionsfähig sein wie jetzt. Dann hat man Zeit auf dem dann frei gewordenen Raid1 r0 ein komplett neues FreeBSD aufzusetzten. Da darf nichts schief laufen.

Zeig doch bitte einen entsprechenden Auszug zum Raid 5 aus dmesg.


Am besten wäre es wohl das aktuelle FreeBSD so weit abzuspecken(Teile auf den Raid5 da0 auslagern) bis es auf eine DVD passt

Code:
AVAGO MegaRAID SAS FreeBSD mrsas driver version: 06.709.07.00-fbsd
mrsas0: <AVAGO Fury SAS Controller> port 0xe000-0xe0ff mem 0xdf200000-0xdf20ffff,0xdf100000-0xdf1fffff irq 17 at device 0.0 on pci2
mrsas0: Using MSI-X with 4 number of vectors
mrsas0: FW supports <96> MSIX vector,Online CPU 4 Current MSIX <4>
mrsas0: MSI-x interrupts setup success


Code:
root@superserver:~ # cat /boot/loader.conf
mrsas_load="yes"
vboxdrv_load="YES"
linux_enable="yes"
ip_mroute_load="yes"

Code:
root@superserver:~ # cat /etc/rc.conf
hostname="superserver"
keymap="german.iso.kbd"


# VLAN-Interface konfigurieren, bge0 ist mein Ethernet-Interface. Ggf. anpassen.
ifconfig_re0="up"

cloned_interfaces="vlan4 vlan5 vlan6 vlan7 vlan8"
create_args_vlan4="vlan 4 vlandev em0 mtu 1492"
create_args_vlan5="vlan 5 vlandev em0 mtu 1492"
create_args_vlan6="vlan 6 vlandev igb0 mtu 1492"
create_args_vlan7="vlan 7 vlandev re0 mtu 1492"  # pppoe
create_args_vlan8="vlan 8 vlandev em0 mtu 1492"
create_args_vlan9="vlan 9 vlandev igb0 mtu 1492" # multicast


# PPP-Client automatisch starten
ppp_enable="YES"
ppp_mode="ddial"
ppp_nat="YES"
ppp_profile="telekom"


gateway_enable="YES"


ifconfig_em1=" inet 172.16.20.1 netmask 255.255.0.0"
ifconfig_igb0="inet 172.17.20.1 netmask 255.255.0.0"
ifconfig_em0=" inet 172.18.20.1 netmask 255.255.0.0"
ifconfig_re0=" inet 172.19.20.1 netmask 255.255.255.0"

ifconfig_vlan4=" inet 192.168.4.1 netmask 255.255.255.0"
ifconfig_vlan5=" inet 192.168.5.1 netmask 255.255.255.0"
ifconfig_vlan6=" inet 192.168.6.1 netmask 255.255.255.0"
# vlan7 bekommt keine IP
ifconfig_vlan8=" inet 192.168.8.1 netmask 255.255.255.0"
# vlan9 bekommt keine IP


#defaultrouter="192.168.8.2"

netwait_enable="YES"
netwait_iface="tun0"
netwait_iface_timeout="300"


## Firewall und Nat
ipfilter_enable="YES"
ipfilter_rules="/etc/ipf.conf"
ipnat_enable="YES"
ipnat_rules="/etc/ipnat.rules"
ipmon_enable="YES"
ipmon_flags="-Ds"

rsyslogd_enable="yes"
rsyslogd_pidfile="/var/run/syslog.pid"
syslogd_enable="no"
#syslogd_flags="-a '172.16.0.0/12:*' -v -v"

# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="NO"

sshd_enable="YES"

zfsd_enable="NO"

samba_server_enable="YES"



named_enable="yes"
dhcpd_enable="YES"

# IP-TV Entertain
igmpproxy_enable="YES"


smartd_enable="YES"
ntpd_enable="YES"
postfix_enable="yes"

lpd_enable="YES"


#ipsec_enable="YES"
#ipsec_program="/usr/local/sbin/setkey"
#ipsec_file="/usr/local/etc/racoon/setkey.conf"
#racoon_enable="YES"
#racoon_flags="-l /var/log/racoon.log"
#mpd_enable="YES"

Code:
root@superserver:~ # df
Filesystem       1K-blocks      Used     Avail Capacity  Mounted on
/dev/raid/r0s1a  110691772  17630468  84205964    17%    /
devfs                    1         1         0   100%    /dev
/dev/da0p1      1040027300     99540 956725576     0%    /mnt/disk1
/dev/da0p2      1040027300  24307160 932517956     3%    /mnt/disk2
/dev/da0p3      1040027300 334220264 622604852    35%    /mnt/disk3
/dev/da0p4      1040027300   1150180 955674936     0%    /mnt/disk4
/dev/da0p5      1040027300    186304 956638812     0%    /mnt/disk5
 
Am besten wäre es wohl das aktuelle FreeBSD so weit abzuspecken(Teile auf den Raid5 da0 auslagern) bis es auf eine DVD passt
Ich hab das lange genug professionell gemacht um dir einen gut gemeinten Rat geben wollen: Lass es! Je mehr du verkomplizierst um ein paar Minuten Downtime einzusparen, umso größer wird das Risiko, dass du einen kapitalen Fehler machst und dann erst recht Ausfallzeit produzierst. ich würde mir an einem eh verregnetem Sonntagnachmittag einfach 2 Stunden Downtime nehmen und es in aller Ruhe machen. Die Maschine vom USB-Stick booten - da bietet sich FreeBSDs offizielles USB-Image für Installationen an, es hat ein Live-System dabei - und r0 per dump(8) auf den Stick oder eine externe Platte sichern. Dann r0 auflösen, als zpool neu aufsetzen, bootbar machen und die Daten zurückspielen. Den HBA fasst du gar nicht an.

Wenn es partout nicht mit Downtime geht (wieso ist das System dann nicht redundant ausgelegt? :)), würde ich mit 'dump -L' arbeiten. Aus dem laufenden System heraus auf eine externe Platte kopieren, von der booten. Dort r0 auflösen, den zpool anlegen und wieder von der Platte im laufenden Betrieb auf den zpool kopieren. Aber, wie gesagt, dass ist schon recht bastelig und gefährlich.
 
Eine CD ode DVD ist aber readonly, das bedeutet wieder, dass ich alle Verzeichnisse wo das Sytsem reinschreiben will auslagern muss.
Du kannst aber von einer CD booten und die betroffenen Teile rw-mounten und umkopieren. Ich glaube, das war hier so in etwa der Tenor.
Du wirst nicht vollständig im laufenden Betrieb das System von UFS nach ZFS umbauen können. Selbst, wenn du von einem zweiten Medium booten könntest, müsste ja ein reboot erfolgen. Wenn das nicht geht, wie du ja sagst, dann hast du nur die eine Wahl, nämlich das Bootmedium selbst zu ändern und mit ZFS zu versehen. Das geht nicht on the fly, wie ich die Kommentare von oben deute.
Das bedeutet wiederum, dass du jedenfalls einen Ausfall des Servers haben wirst. Egal, wie kompliziert du da auch immer vorgehen willst.
Ein Ausfall mit Start einer Live-CD und dann umkopieren des Systems und anschließendem Neustart dauert etwa so lange, wie das hin und her kopieren der Daten eben dauert. Für diese Zeitspanne hättest du keinen Server. Du kannst die Zeit halbieren, indem du das "hin-kopieren" vorab erledigst. Aber weniger dürfte wohl nicht machbar sein. Du brauchst ja das neue Zielmedium und musst es frei machen und da dieses Ziel dein derzeitiges System-medium ist, wird es wohl nicht anders zu machen sein.

Worüber ich indessen nachdenke: wenn du nur ein SSD als neues ziel auswählen würdest, die raid-Funktion also abschalten und nur eine SSD neu als ZFS anlegen würdest, dahin kopieren und dann beim nächsten Start davon booten und die nun nicht mehr gebrauchte SSD dann dem Pool hinzufügst, das sollte vielleicht gehen. Du brauchst kein HW-Raid mit ZFS. Aber vielleicht habe ich da auch was falsch verstanden.
 

Ähm, Reboot ist kein Problem, aber eine längere Ausfallzeit von mehren Minuten oder gar Stunden schon.
Warum will ich das machen? Aktuell benutze ich ein Raid1 mit 2 SSD Festplatten.
Warum benutze ich einen Raid mit SSD HD's? Weil mir schon mal eine SSD während des Betriebs verreckt ist. Seit dem benutze ich keine SSD mehr ohne Redundanz. Ok, das System ist nun redundant mit UFS. UFS ist eigentlich ein gutes zuverlässiges Filesystem warum will ich dann auf ZFS? Weil ich mir da einen snapshot machen kann und so den aktuellen Systemzustand "einfrieren" kann. Geht was bei den folgenden Basteleien schief kann ich zurück

Deine Idee eine USB Festplatte zu verwenden ist gut. Und manchmal hat man ein richtig großes Brett vom Kopf. Da kann ich ja das ganze System drauf packen und davon booten und die SSD sind für Neuformatierung mit ZFS frei. So, ich besorg mir eine USB Festplatte, vielleicht that mein Schwager noch eine rumliegen (ist Sammler)

Dann muss ich nur noch wissen wie das System bootfähig auf die USB Disk kommt. :):):)

Update:
ich geh nun eine USB Disk kaufen :)
 
Ich seh es wie @Yamagi: richte dir eine Downtime ein. Spiel das ganze vorher in einer VM mal durch, dann dürfte die ganze Sache am echten System nicht länger als eine halbe Stunde dauern. Sollte zu verschmerzen sein :).
 
So, die USB Festplatte ist angeschlossen

Code:
usb_alloc_device: set address 3 failed (USB_ERR_IOERROR, ignored)
ugen1.3: <Seagate> at usbus1
umass0: <Seagate M3 Portable, class 0/0, rev 3.00/7.08, addr 2> on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0xc101
umass0:11:0: Attached to scbus11
da1 at umass-sim0 bus 0 scbus11 target 0 lun 0
da1: <Seagate M3 Portable 0708> Fixed Direct Access SPC-4 SCSI device
da1: Serial Number NM13T8KE
da1: 400.000MB/s transfers
da1: 476940MB (976773167 512 byte sectors)
da1: quirks=0x2<NO_6_BYTE>

nun das system kopieren. Das Problem die neue hat 500GByte die ssd's 128GByte. Da muss ich wohl vorher neu Partitionieren. Frage müssen die Partitionen gleich groß sein?
 
Das Problem die neue hat 500GByte die ssd's 128GByte.
umgekehrt wäre doch viel problematischer.

ich möchte mich den geäußerten Warnungen noch mal anschließen.
Es gibt ein sehr hohes Potenzial dafür, dass du mehr als einen kurzen Ausfall des Servers produzierst, wenn du mit Übereifer an die Sache gehst.
So genügt es nicht, nur das momentane System auf die externe Platte zu schreiben. Du brauchst dort einen passenden Bootmechanismus und der muss gemäß deiner Forderung zu 100% beim Restart auch funktionieren.
Meiner leidigen Erfahrung nach gibt es zu 95% eher ungeahnte Schwierigkeiten.
 
umgekehrt wäre doch viel problematischer.

ich möchte mich den geäußerten Warnungen noch mal anschließen.
Es gibt ein sehr hohes Potenzial dafür, dass du mehr als einen kurzen Ausfall des Servers produzierst, wenn du mit Übereifer an die Sache gehst.
So genügt es nicht, nur das momentane System auf die externe Platte zu schreiben. Du brauchst dort einen passenden Bootmechanismus und der muss gemäß deiner Forderung zu 100% beim Restart auch funktionieren.
Meiner leidigen Erfahrung nach gibt es zu 95% eher ungeahnte Schwierigkeiten.

Ja, und darum bin ich hier, damit nichts schief geht. Als folgender Schritt ist die USB disk so anpassen dass ich das system drauf kopieren kann und das dauer bestimmt ein paar Tage bis ich das so hab dass es passt.
Beim eigentlichen neustart muss ich das bios sowieso anpassen, dass es von USB auch bootet und das kann ich erst dann machen wenn niemand telefonieren oder 'fern' sehen will :)

Und ja, es besteht ein Risiko, und darum zieh ich auch eine der beiden ssd's aus dem Schacht um wenn etwas schief geht einen Fallback zu haben.

Aber nun erst mal zu neuen USB Disk. muss die Partition so groß sein wie die aktuelle root Partition?
 
Nein. Wichtig ist nur, dass alles raufpasst. Ich würde empfehlen, die Platte soweit vorzubereiten und auf einem anderen System zu testen, ob sie bootet.

Rob

ok das kann ich machen indem ich sie an mein Laptop anschließe und wie kopiere ich nun die ssd' da ist auch noch die swap drauf

Code:
Geom name: raid/r0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 237604863
first: 63
entries: 4
scheme: MBR
Providers:
1. Name: raid/r0s1
   Mediasize: 121332826112 (113G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32768
   Mode: r2w2e3
   attrib: active
   rawtype: 165
   length: 121332826112
   offset: 32768
   type: freebsd
   index: 1
   end: 236978239
   start: 64
Consumers:
1. Name: raid/r0
   Mediasize: 121653690368 (113G)
   Sectorsize: 512
   Mode: r2w2e5

Geom name: raid/r0s1
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 236978175
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: raid/r0s1a
   Mediasize: 117037858816 (109G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32768
   Mode: r1w1e1
   rawtype: 7
   length: 117037858816
   offset: 0
   type: freebsd-ufs
   index: 1
   end: 228589567
   start: 0
2. Name: raid/r0s1b
   Mediasize: 4294966784 (4.0G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1073774592
   Mode: r1w1e0
   rawtype: 1
   length: 4294966784
   offset: 117037858816
   type: freebsd-swap
   index: 2
   end: 236978174
   start: 228589568
Consumers:
1. Name: raid/r0s1
   Mediasize: 121332826112 (113G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32768
   Mode: r2w2e3
 
swap lässt du weg, also, du kannst eine swap-Partition auf einem USB-Gerät anlegen, damit eine vorhanden ist, aber du kopierst nichts aus dem aktuellen SWAP dorthin. Da du UFS hast und für die Kopie nehmen wirst, wirst du die Platte mit UFS einrichten und später die /etc/fstab korrigieren.

Du legst außer der SWAP eine Partition an und machst diese Bootbar. ich will die Kommandos dazu nicht nachsehen, nur das Prinzip nennen. Dann nimmst du jede Partition auf deinem System und dump & rerstored sie auf das USB-Gerät und zwar dort direkt ins Verzeichnis statt auf den Mountpoint. Du nimmst also keine Partitionen sondern führst das System auf eine bootbare Partition zusammen.
 
swap lässt du weg, also, du kannst eine swap-Partition auf einem USB-Gerät anlegen, damit eine vorhanden ist, aber du kopierst nichts aus dem aktuellen SWAP dorthin. Da du UFS hast und für die Kopie nehmen wirst, wirst du die Platte mit UFS einrichten und später die /etc/fstab korrigieren.

Du legst außer der SWAP eine Partition an und machst diese Bootbar. ich will die Kommandos dazu nicht nachsehen, nur das Prinzip nennen. Dann nimmst du jede Partition auf deinem System und dump & rerstored sie auf das USB-Gerät und zwar dort direkt ins Verzeichnis statt auf den Mountpoint. Du nimmst also keine Partitionen sondern führst das System auf eine bootbare Partition zusammen.

Also, die logischen Schritte
1. neue Platte partitionieren
2. die root partition mit dump & restore kopieren (es gibt ohne swap nur eine partition)

Frage, wenn ich nicht das Gerät sondern den Inhalt des Filesystems kopiere, dann ist die Partitionsgröße eigentlich egal es muss nur genügend platz haben? Ist das richtig?
 
hi,
so langsam kommt Licht ins dunkel.

Da ich von ZFS absolut keine Ahnung habe, muss ich den Umgang damit üben. Ich versuch das mal und melde mich wenn ich Probleme damit habe
 
dann ist die Partitionsgröße eigentlich egal es muss nur genügend platz haben? Ist das richtig?
ja.

du kopierst.
Achte aber vielleicht darauf, wenn das bei dir eine einzige Partition ist, dass du nicht unnötig Dinge aus /tmp oder so mit nimmst und auch nichts auf einen Verzeichniseintrag gemountet ist. Du hast ja /home schon wegkopiert? wenn es eingehangen ist, musst du darauf achten, es nicht unnötig zu kopieren (wenn du das möchtest, ist es ja OK, aber wenn du zB auch /Daten irgendwo hast und das viele Daten auf einem anderen Medium sind, dann möchte man das ja nicht).

dump_n_restore kann man auf ein Live-benutztes System anwenden. Deshalb ist das von Vorteil. Ansonsten kann es Probleme bei geöffneten Dateien geben. Ich habe schon deshalb immer lieber offline gearbeitet und rsync genommen, weil ich das auch besser kenne. dump - restore geht anders, ich habe keine Erfahrung damit gemacht und nur darüber gelesen.
 
ja.

du kopierst.
Achte aber vielleicht darauf, wenn das bei dir eine einzige Partition ist, dass du nicht unnötig Dinge aus /tmp oder so mit nimmst und auch nichts auf einen Verzeichniseintrag gemountet ist. Du hast ja /home schon wegkopiert? wenn es eingehangen ist, musst du darauf achten, es nicht unnötig zu kopieren (wenn du das möchtest, ist es ja OK, aber wenn du zB auch /Daten irgendwo hast und das viele Daten auf einem anderen Medium sind, dann möchte man das ja nicht).

dump_n_restore kann man auf ein Live-benutztes System anwenden. Deshalb ist das von Vorteil. Ansonsten kann es Probleme bei geöffneten Dateien geben. Ich habe schon deshalb immer lieber offline gearbeitet und rsync genommen, weil ich das auch besser kenne. dump - restore geht anders, ich habe keine Erfahrung damit gemacht und nur darüber gelesen.

Ja das wollte ich schon fragen, ob man nicht auch rsysnc verwenden kann. Das hätte den scharm, dass ich die USB Platte mitlaufen lassen kann und die aktuellen Änderungen gleich synchron habe. Und am Tag X die kopiererei wegfällt und nur noch die fstab angepasst werden muss.

Und das wollte ich noch fragen, wie geht dump mit symbolic links um? Anbei meine fstab, da ist einige eingehängt. würde das alle "mitkopiert" werden wenn man es nicht ausdrücklich untersagt?


Code:
/dev/raid/r0s1a /               ufs     rw      1       1
/dev/raid/r0s1b none            swap    sw      0       0
/dev/da0p1      /mnt/disk1      ufs     rw      1       1
/dev/da0p2      /mnt/disk2      ufs     rw      1       1
/dev/da0p3      /mnt/disk3      ufs     rw      1       1
/dev/da0p4      /mnt/disk4      ufs     rw      1       1
/dev/da0p5      /mnt/disk5      ufs     rw      1       1
 
zu den Fragen über dump verweise ich auf den Rat der Experten. Im Zweifel ist ein Test im virtuellen System eben aussagekräftig. Laut man page:
Code:
     The file system to be dumped is specified by the argument filesystem as
     either its device-special file or its mount point (if that is in a
     standard entry in /etc/fstab).
So ein dump braucht keine sehr lange Zeit. Du musst nicht mit mehreren Tagen rechnen, bis du testen kannst.

Wenn dump nur auf einem Gerät bleibt, dann nimmt es die gemounteten übrigen Geräte ja nicht mit. Ich würde das aber sicherheitshalber zuvor probieren, denn ich habe schon erlebt, wie ich eine entfernte Platte soeben mit löschte, die ich irgendwo in meinem home gemountet und vergessen hatte, zuvor auszuwerfen. Deshalb bin ich da übermäßig vorsichtig.

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.

mit welcher Methode auch immer: im Ziel gibt es später ja die /ziel/etc/fstab als Kopie der /etc/fstab und diese /ziel/etc/fstab wird beim nächsten booten ja ausgewertet, es soll ja vom Ziel gebootet werden. Dann wird eben eine Information gelesen, die nicht passt. Du möchtest ja dann / vom Ziel booten, also /dev/da1s1 oder so was und nicht /dev/raid/r0...
Die übrigen Einträge wirst du wohl wieder mounten wollen, also genauso auch in der neuen, verbesserten fstab haben wollen. Du möchtest ja den Server wieder weiter betrieben und diesen Speicher verfügbar machen. Denke ich mal.

Meiner Ansicht nach wäre ZFS dort, also auf den Platten mit den Daten, noch viel sinnvoller.
 

Du hast es schon richtig verstanden, wenn alles auf der USB Disk ist, dann will ich natürlich ein lauffähiges system booten weil ich nicht weiß wie lange ich brauche um auf r0 ein funktionierendes ZFS zu bauen. Experten machen das wohl in 5 Minuten ich dagegen muss erst lernen mit ZFS umzugehen.

Vorzugsweise würde ich lieber rsync verwenden weil ich dann die USB so lange parallel mitlaufen lassen kann bis ich alles fertig habe. Am tag X würde ich dann die fstab vor dem reboot anpassen. Klappt alles, dann kann ich das r0 platt machen und ein ZFS drauf packen. Klappt es nicht, dann boote ich wieder von r0. Also eine Ausfallzeit von ca 15 Minuten. Da sist zu verschmerzen.

Die anderen platten bekommen kein ZFS, das sind reine Backup-Speicher die Daten sind da auf anderen Systemen redundant und meine Verwandschaft muss sicher sein, dass wenn sie eine Date löschen diese auch wirklich gelöscht ist und sich nicht noch in einem ZPool snapshot versteckt. Viel wichtiger wäre mir da eine vom Anwender gesteuerte Verschlüsselung des zugewiesenen smb Verzeichnisses. Aber das ist ein anderes Thema.


Der Weg ist nun klar und ich muss nun alles vorbereiten :)

Danke allen
 
Zurück
Oben