FreeBSD auf andere Platte kopieren

rMarkus

rMarkus

Chuck The Plant
Hallo,

ich moechte ein lauffähiges FreeBSD im Betrieb auf eine andere Platte kopieren.

Was ist zu beachten?
 
geht theoretisch einfach mit dd, die andere platte sollte dann halt genauso gross oder grösser sein
 
Danke für die Antworten, aber die Platten sind gerade das Problem:

die Quellplatte ist eine 4 GB UW-SCSI an einem Symbios 53c875 und die Zielplatte eine 18 GB U160-SCSI an einem Adaptec U2W.
Alleine das initiale BIOS-Mapping der kleinen Platte vertraegt der Adaptec nicht, so dass er nicht davon booten will. (Das alte Problem mit Adaptec, dass alle anderen das Adaptec-CHS-Mapping verstehen umgekehrt aber nicht).

Die Zielplatte ist partitioniert, "gesliced" und formatiert. Kann ich einfach mit "cp" oder "tar" das System dort hin kopieren?
 
sollte mit cp gehen, wenns nicht tut, dann war dr tipp nciht von mir :D aber sollte wirklich gehn
 
Hi,

das sollte doch mit Dump/Restore 1a klappen?! Ich hab' so vor etlicher Zeit von SCSI auf IDE "migriert" und vor kurzem von ner sterbenden IBM auf eine Maxtor.

Wenn du das System "live" Übertragen willst, solltest du auf jeden Fall beim Dump die Option "-L" mitgeben (klappt aber IMHO erst ab UFS2?).

Ich mach' das immer so: Neue Platte reinhängen, Partitionieren, die Slices anlegen, dann auf der Zielplatte auf die erste Slice cd'en und dann (jetzt aus'm Kopf; lies' im Zweifel die Manpages von Dump und Restore):

dump -0Lf - /dev/<quellslice> | restore -rf -

Das halt einfach für alle Slices wiederholen.

Am Ende musst du die neue Platte nur noch bootbar machen. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html

HTH
_ralf_
 
So wie ich ffs verstanden habe könnte so eine Aktion gewaltig auf die Performance gehen.
Da ffs ja versucht die Daten möglichst Optimal auf der Platte zu verteilen, was natürlich nicht mehr stimmig ist, wenn die Zielplatte einen anderen Typ hat.
 
dump -0Lf - /dev/<quellslice> | restore -rf -

läuft gerade auf dem Live-System.

Eigentlich ist es nicht nötig, dass das System währendessen läuft, aber ich probiere das mal aus.
Mit den Befehlen kann man sogar dann die ganze Platte quer über's Netz mit SSH kopieren und entfernt sogar wieder auspacken.

FreeBSD gefällt mir immer besser.

PS: Ich habe einen Adaptec 2940U2W und einen Adaptec 2940U2B.
Der U2B kann nicht booten, obwohl viel dafür spricht, dass er das eigentlich können müsste (z.B. der Flash-Chip). Normalerweise dürfte der identisch mit dem U2W sein, ausser dass er keine SE-Bridge hat.
 
Maledictus schrieb:
So wie ich ffs verstanden habe könnte so eine Aktion gewaltig auf die Performance gehen.
Da ffs ja versucht die Daten möglichst Optimal auf der Platte zu verteilen, was natürlich nicht mehr stimmig ist, wenn die Zielplatte einen anderen Typ hat.
Zum Vergrößern anklicken....

Soweit ich das sehe, läuft der lesende DUMP-Befehl direkt auf dem Device und liest die Plattenrohdaten, während der RESTORE-Befehl zum Schreiben der Daten auf der normalen User-Ebene läuft, also das Betriebssystem die Dateien (!) normal über FFS/UFS2 usw. wie bei einem cp oder tar schreibt.

Die Daten sollten somit optimal auf der Zielplatte verteilt sein.
 
Vielleicht hat mal jemand Lust, angehängtes Skript zu testen. Es verwendet sysutils/cpdup. Ich habe das mal vor einiger Zeit geschrieben, für den Fall der Fälle, habe aber bis jetzt noch keine Zeit gehabt, es zu testen (also Vorsicht!).

Vorgehensweise: Auf der neuen Platte die gleichen Partitionen wie auf der bisherigen anlegen. Also wenn Partition e bisher /usr war, dann wird Partition e auf der neuen Platte ebenfalls /usr bekommen. Die Größe der neuen Partitionen muß aber nicht mit der der alten Partition übereinstimmen. Anschließend aus dem laufenden System das Skript aufrufen, ggf. natürlich die Voreinstellungen anpassen.
 

Anhänge

  • MirrorDisk.zip
    652 Bytes · Aufrufe: 332
Hallo,

die Platte ist soweit kopiert.

Das System hat nun folgenden Zustand:
/dev/da0s1a gemountet auf / --> Original
/dev/da1s1d gemountet auf /mnt --> Kopie

Nun muss ich den Bootloader neu schreiben lassen, damit er den Stage 1 Bootloader auf der Kopie findet.
Dazu habe ich zwei Varianten Probiert:

fdisk -B -b /mnt/boot/boot0 /dev/da1s1d
--> Problem: Nach dem Booten ist /mnt --> /

chroot /mnt
fdisk -B -b /boot/boot0 /dev/da1s1d
--> Problem: das /dev Filessystem gibt's natuerlich nicht auf /mnt, da das lebende System nun unter dem Root ist.

Was kann ich tun?

PS: Das Skript habe ich mir mal angesehen, aber es löst mein Problem auch nicht.
 
Ich wollte eignentlich den Standardbootmanager verwenden.

Nun habe ich die einfache Endkonfiguration hergestellt:

Adaptec U2W mit einer Platte, die eine Partition und 2 Slices hat.
1. Slice ist Swap
2. Slice ist die Bootpartition mit FreeBSD 5.3

Wie bekomme ich das Ding nun bootbar?
 
Müßte jetzt eigentlich funktionieren, indem du sysinstall von der Installations-CD startest, ins FDISK gehst, ohne Änderungen W drückst und dann anschließend die Frage nach dem Boot-Manager beantwortest. So habe ich das jedenfalls mal gemacht, als ich versehentlich den MBR leergeräumt hatte.
 
Hoi,
weil öfter danach gefragt wurde un alle auf den alten Thread Bezug nahmen dacht ich des wäre bärig sicherlich sinnvoll bzw. oifacher das hier zu ergänzen oifach :)
Gruß Bär
 
Huch,

die gute alte Zeit mit SCSI.

"recoverdisk" hilft,
  • bei nicht gemounteten Platten
  • aber hauptsächlich, wenn die Quell-Platte Defekte vorweist und sie trotzdem gelesen werden soll

"dump/recover" hilft,
  • wenn sich Quell- und Zielplatte unterscheiden
  • wenn Quell-Platte gemountet ist und im Betrieb ist (Schalter -L)
 
rMarkus: Du hast wohl vergessen wie ärgerlich schlecht terminierte Busse waren und was passiert, wenn man sich mal bei den Jumpern vertut, weil ein verdammtes Device die ID Jumper negiert.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben