1:1-Kopie von Dateisystemen

T

töfte

Member
Hallo !
Bei mir steht diese Woche ein Hardwareupgrade an und im Zuge dessen möchte ich auch die im externen Gehäuse steckende 200GB-Platte als Systemplatte einbauen.
Die momentane Systemplatte ist 13GB groß.
Nun würde mich folgendes interessieren: ich würde gerne mit dem Inhalt einiger Dateisysteme auf die neue Platte umziehen, und bin mir nicht sicher ob dd da ein gutes Unterfangen ist, weil die neuen Dateisysteme ja wesentlich größer sein werden. Kann mir da jemand auf die Sprünge helfen ?
 
Also ich hab' letztens einiges an Daten mit tar umgezogen. Funktionierte prima.

Das geht z.B. indem Du die zu exportierende Platte auf dem Zielsystem per NFS mountest. Dann führst Du einfach folgenden Befehl aus:

Code: 
cd /mnt
tar cf - . | (cd /pfad/zum/ziel && tar xf -)

Gegebenenfalls kann noch der Parameter -p von Interesse sein, näheres in der man-Page.
 
Erstell ein Image (Ich weiß leider nicht genau wie das funktioniert... :redface:), dann kannst du
dd if=/dev/FestplatteDieDuSichernMöchtest of=/PfadZuMeinemImage
Zum Vergrößern anklicken....

Aber ließ dir zuvor nochmal besser das Manual von dd durch. ;)
 
N'Abend!

dd wird wohl nicht so hilfreich sein, da töfte ja seine Dateisysteme in der Größe verändern will.
Ich würde auch tar oder cpio empfehlen, damit geht's sicherlich am besten.

HTH
 
Hmm, hab mir gerad' die Manpage von tar durchgelesen, da gibt es keine Probleme wenn ich über NFS kopieren möchte, oder ?

Cpio les' ich mir auch gleich nochmal durch. Das mit dem Daten kopieren ist immerhin eine kritische Sache..
 
cpdup ist die erste Wahl für so etwas. Wer sich keinen zusätzlichen Port installieren will (der belegt immerhin 22 KB), kann auch mit dump/restore arbeiten.

dd ist aufgrund der unterschiedlichen Dateisystemgrößen unbrauchbar. tar und cpio haben AFAIK bei "fiesen" Dateien (z.B. Sparse Files) Probleme, auf die beiden würde ich mich daher nicht unbedingt verlassen. Falls es doch tar sein muß, ist -p nicht nur von Interesse, sondern absolut notwendig.

Im Übrigen ist das fast schon eine FAQ, daher dürfte sich über die Boardsuche bereits einiges zu diesem Thema finden lassen.
 
Der Vollständigkeit halber sei noch archivers/star angemerkt - ist wahrscheinlich etwas umfangreicher und komplizierter als cpdup, handled aber auch ACLs soweit ich weiß.
 
In der Sammlung darf natürlich rsync nicht fehlen. Kann special Files (sparse, devices usw.) 1:1 kopieren und das nicht nur lokal sondern sogar übers Netzwerk ;)
 
ich denke dass nach einem fdisk/disklabel/mount-geraffel
Code: 
% mount DEVICE1 /NEUEPLATTE
% mount DEVICE2 /NEUEPLATTE/usr
% mount DEVICE3 /NEUEPLATTE/home
% ...
% ( cd /ALTEPLATTE ; tar cvf - bsd boot usr tmp var home ... ) | ( cd /NEUEPLATTE ; tar xv )
die beste loesung ist.
denk dran dass du auch kein verzeichnis bei dem ersten tar alle verzeichnisse und dateien im root-directory mit auffuehrst. OHNE das mountverzeichnis fuer die neue platte versteht sich.

was dann u.u. noch fehlt ist allerdings der bootloader im mbr. keine ahnung wie man den unter *BSD wieder aufzieht.
 
dettus schrieb:
Code: 
% ( cd /ALTEPLATTE ; tar cvf - bsd boot usr tmp var home ... ) | ( cd /NEUEPLATTE ; tar xv )
Zum Vergrößern anklicken....

Ich glaube im ersten tar Aufruf sollte kein -v drin sein. Der verbose Output landet auch auf stdout und damit in der Pipe, was den zweiten tar Prozess verwirren könnte (hab's aber noch nicht selbst getestet).

Im zweiten Aufruf fehlt der Parameter "-f -", ohne den wird vom ersten Tape Device gelesen. Auch hier hab' ich das tatsächliche Verhalten nicht getestet, lasse mich also durchaus eines besseren belehren.
 
keine ahnung was v genau macht...
irgendwie klappt das bei mir nie wenn man es weglaesst.
mit hatte ich noch nie probleme... also wars mir bisher egal ;)

tar xv liest auf jeden fall vom standard input!
 
dettus schrieb:
ich denke dass nach einem fdisk/disklabel/mount-geraffel
Code: 
% mount DEVICE1 /NEUEPLATTE
% mount DEVICE2 /NEUEPLATTE/usr
% mount DEVICE3 /NEUEPLATTE/home
% ...
% ( cd /ALTEPLATTE ; tar cvf - bsd boot usr tmp var home ... ) | ( cd /NEUEPLATTE ; tar xv )
die beste loesung ist.
Zum Vergrößern anklicken....
Einspruch! cpio bzw dump kopieren auch ACLs und Flags mit, die tar gerne vergisst.

Der Boot Loader wird mit sysinstall beim formatieren der neuen Platte mit angelegt, alternativ fragt man höflich bei boot0cfg(8) nach.
 
tar ist in der Tat ungeeignet zum klonen. Hier die rsync-Syntax:

Code: 
# rsync -aSv quelle/ ziel/

Kopiert 1:1 Special Files, Links, Sparse Files, Berechtigungen, TimeStamps usw. usf. Habe schon mehrere Systeme damit auf neue, größere Platten umziehen lassen. Bootloader muß man dann natürlich auch noch schreiben...
 
FreeBSD auf größere Festplatte umziehen (schnell & dreckig)

Hallo,

ich hatte dort mal beschrieben,
wie ich einen schnellen und dreckigen Umzug
von FreeBSD auf einen neue und größere Festplatte gemacht habe.

Achtung:
cheasy hat darauf hingewiesen,
das gtar bisher die FreeBSD Filesystem-Flags
nicht mitkopierte (die chflags zum Beispiel).

Da ich aber sowieso die FreeBSD world und kernel
recht häufig neubaue, habe ich da, an der Stelle wo ich weiß
das da ein chflag sein sollte, ein chflag gefunden
als ich das nach der Anmerkung von cheasy
auf meinem System kontrollierte.

Ist aber auch bloß ein FreeBSD System,
das ich als Destkop System verwende.
Wer da einen dicken Server verwaltet, muss
da wohl doch etwas mehr Vorsicht walten lassen.


Gruß, Fusselbär
 
Na dann kann ich ja fast für jedes Dateisystem eine andere Kopiermöglichkeit ausprobieren !
Morgen geht's los, danke schon mal im Voraus !
 
meine standard rsync sieht so aus:
rsync -auE
das u ist deshalb drin, weil ich das auch lokal zum Sichern der Daten über einen Cron Job nutze.
Über Netz kann vielleicht Komprimierung eingeschaltet werden.
-s, wie hier erwähnt, nutzte ich nie, weiß auch nicht, was sparse files sind. Vielleicht habe ich die nicht.

rsync hat den Nachteil, nicht über Partitionsgrenzen zu wirken und den Vorteil, schnell und einfach und umfassend zu sein und auch Verzeichnisse oder Dateien auslassen zu können, was ich sehr angenehm finde, wenn ich die Mountpoints für Netzwerkfreigaben nicht berücksichtigen will.
Ich verstehe nicht, weshalb es nicht häufiger benutzt wird.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben