Hallo, Am Thu, 01 Dec 2005, Christian Boltz schrieb:
6.5. Wie kann ich einen kompletten Verzeichnisbaum auf eine andere Partition kopieren? http://suse-linux-faq.koehntopp.de/q/q-filesystems-kopieren.html
Jup. LEUTE, BITTE LEST DIE FAQ!!! Wir haben da zwar noch ne kleine interne Diskussion (zu den Gruenden, s.u.), aber ich war in letzter Zeit nicht fit genug, da was zu zu schreiben. Ich bemuehe mich das zu ergaenzen, insbesondere zu: ==== Zitat aus der FAQ q-filesystems-kopieren.html ==== Die in den oben genannten Befehlen verwendeten Optionen weichen etwas von den in der SDB genannten ab. Gründe hierfür: * --numeric-owner ist beim lokalen Kopieren überflüssig und kann bei Kopieren über SSH u. U. sogar unerwünscht sein, falls die User-IDs abweichen * -S (--sparse) hat in Einzelfällen (laut David Haller) schon zu kaputten Dateien geführt. ==== Apropos: ich werde mich auch bemuehen, das mit der SDB zu synchronisieren (zu lassen) (d.h. mit diesen beiden Artikeln: http://portal.suse.com/sdb/de/1997/09/maddin_kopieren.html http://portal.suse.com/sdb/de/1999/04/neue_hd.html ). Konkret zu "-S": mir hat's da mal mit '-S' ne Datei total verzwirbelt ich weiss aber leider nicht mehr ob das ne spezielle (device, fifo, socket) oder ne sparse-Datei war oder ne normale... Naja, ich habe sowieso praktisch keine "sparse" Dateien auf meinen Platten... Speziell bei Interesse werde ich das aber mal versuchen nachzustellen. Das ist aber eben recht aufwaendig. Das mit dem "verzwirbeln" koennte allerdings auch ein Bug in meinem uralt tar sein, der inzwischen behoben wurde, das wuerde ich dann unter der auch installierten SuSE 9.1 testen. Man kann '-S' aber wohl durchaus verwenden, sollte dann aber sicherheitshalber wohl Quell- und Zieldateien vergleichen. Hilfe beim austesten waere nett ;) Achso, mein "Urteil" erlaube ich mir - obwohl ich nur ext2/3 sowie reiserfs verwende(t habe), bei XFS/JFS/... koennen ggfs. andere Tools noch relevant sein (xfsdump z.B.). Bzgl. der Standardtools, speziell 'cp' und die diversen Dateimanager wie konqueror, mc usw. gilt meine Erfahrung aber. - weil ich mein nach wie vor laufendes System seit Sommer '99 (also seit ~6 1/2 Jahren) auf inzwischen die IIRC (mind.) 6te Festplatte umgezogen habe, und dabei sogar noch oefter die /-Partition gewechselt habe. Von anderen Partitionen (u.a. /var, /usr) ganz zu schweigen... Und inzwischen ist das System auch problemlos auf zwei 160 GB Festplatten verteilt, allerdings eben schon laenger mit 2.4.2[45]er Kernelversionen[1] statt dem urspruenglichen 2.2.10. Mein BIOS ist uebrigens "Release: 11/17/99"... (und das System hatte ich noch auf der alten HW installiert, MoBo, CPU, RAM habe ich IIRC im Sommer '00 gekauft)...
Am Donnerstag, 1. Dezember 2005 19:16 schrieb Holger Hellmuth:
Wolfgang Gruhn wrote:
Erfahrungen gemacht, dagegen einige negative mit dem Kopieren innerhalb von Linux-Systemen, insbesondere mit "tar", weil die Daten dabei verändert werden.
Ich stimme der Vermutung von Andre zu, dass die Dateien beim Umkopieren gerade in Gebrauch waren - das ist aber nicht tar anzulasten.
Wenn man z. B. /var/ oder gar / umkopieren will, empfiehlt sich das Booten eines Rettungssystems oder eine Knoppix.
ACK. Es geht zwar auch "so", in dem man in den Single-User bootet und '/' nur ro mounten laesst (und alles andere erst gar nicht) und dazu dann nur die Zielpartition fuer's neue '/' dazu mounted... Bei '/var' gilt das gleiche sogar noch verschaerft (wg. /v/l/m z.B.). Das sollte man aber nur machen, wenn man weiss was man tut. Und wenn man ein getestetes(!!!) Backup hat. Kurz: man sollte es vom Rettungs- oder einem Live-System wie Knoppix aus machen. Und in der Ramdisk dieser System kann man ja auch voellig ungeniert in / Mountpunkte, z.B. /OLD und /NEW erstellen ;) 'sync; sync' nach dem kopieren und 'umount' hinterher nicht vergessen... (Hm, das 'sync; sync' sollte auch in die FAQ ;)
dd ist da (auch wenn langsam) besser, allerdings sollten die Partitionsgrössen übereinstimmen (wegen Platz und wegen der Blockgröße, wenn das Dateisystem mit veränderlicher Blockgröße arbeitet).
dd arbeitet eben komplett anders - es kopiert das komplette Dateisystem und nicht einzelne Dateien.
Von dd kann ich fuer o.g. Zweck auch nur abraten. Einfach wg. der voellig ungeeigneten Funktionsweise. Stichwort "know thy tools" ;)
Ob tar und cp Sonderfiles wie Pipes richtig kopieren, ist auch ne Frage (zumindest vor ein paar Jahren konnten sie es noch nicht, inzwischen hat sich da aber was getan).
Ich hatte jedenfalls noch keine Probleme damit.
Dito. s.o. tar ist IMO das Tool der Wahl. BTW: $ tar --version tar (GNU tar) 1.12 $ fmt='%{name}-%{version} %{distribution} %{installtime:date}\n' $ rpm -q --queryformat "$fmt" -f `which tar` base-99.8.7 SuSE Linux 6.2 (i386) Sat 04 Dec 1999 06:58:05 PM CET $ unset fmt (Ja, das "base"-RPM hab ich nochmal nachinstalliert, ich hab damals noch _SEHR_ viel gebastelt ;) Jedenfalls: mit diesem "uralt" tar habe ich bisher alles "umgezogen". Hm. Ne >2G Datei aber IIRC noch nicht, ich hab bisher nur eine (ein Image meiner /home-Partition...) Sollte ich mal testen ;). Aber keine Sorge: auf allen Linux-Distris, wo es nicht sowieso nur Probleme mit grossen Dateien gibt, wo also z.B. 'ls' usw. schon die korrekten Dateigroessen angeben, dort sollte das jew. tar mit diesen Dateien auch korrekt umgehen. Das zu testen schadet allerdings nicht. Aber tar ist ja per default "nicht-destruktiv" und die u.a. in der FAQ genannte Vorgehensweise empfiehlt ja auch, die Quellen erst zu loeschen, wenn man die Ziele ueberprueft hat.
Eben. Oder man kopiert von einem Rettungssystem aus (ist beim Umkopieren des kompletten Systems sowieso sinnvoll), da sind solche Kandidaten erst gar nicht gemountet.
ACK.
rsync ist garnicht mal so schlecht, denn es kann mit hard links und devices umgehen, und vermutlich auch mit Rekursion.
Die Frage ist, ob es auch sowas wie --atime-preserve (siehe tar) kann.
Kann das mal jemand ausprobieren, ob rsync die atimes veraendert? Die man- und infopage von rsync schreiben nix zu 'atime'... /foo/bar/baz $ TZ=UTC touch -amc -d 19700101 EINE_INSEL /foo/bar/baz $ TZ=UTC ls -l --full-time --time=atime EINE_INSEL [Hier jetzt mir rsync die Datei /foo/bar/baz/EINE_INSEL mit rsync woanders hin kopieren -- da ich rsync nicht verwende ... ] /woanders/blubb $ TZ=UTC ls -l --full-time --time=atime EINE_INSEL
Ansonsten wird es im Newsspool lebhaft zugehen... (@David: plauderst Du dazu ein wenig aus dem Nähkästchen? ;-)
Man nehme einen leafnode-newsspool in /var/spool/news, mit einigen Gruppen, vorzugsweise mit vieel Traffic (dana z.B.), in die man mal reingelesen hat, und die man mit einer langen Haltezeit ("expire" / "groupexpire" hoch) versehen hat, so dass man von diesen Gruppen noch ein paar (1 reicht) Nachrichten uebrig hat, z.B. von vor einem halben Jahr... Dass man die Gruppe mal hatte hat man natuerlich schon laengst vergessen, denn aktiv wird die Gruppe natuerlich schon lange nicht mehr gelesen... So. Und dann kopiert man den newsspool mal eben um... Ohne o.g. bzgl. '--atime-preserve' zu beachten, z.B. mittels 'mc' oder 'cp -a'... Und beim naechsten holen von Gruppen wundert man sich, warum das so lange dauert... Und bis man's kapiert hat man schonmal ne Einwahl und einige MB Traffic vergeudet... Weil alle Gruppen, von denen noch was im newsspools war, auf einmal wegen der frisch gesetzten atime durchs kopieren wieder auf "Gruppe wird gelesen" (aka "active") sind... Und auch bei Gruppen, die man aktiv liest kommen (IIRC) u.U. auf einmal wieder viele schon gelesene Nachrichten neu... Generell gilt IMO beim "Umziehen", dass man _alle_ Zeitstempel unangetastet lassen sollte. Denn man will die Dateien "logisch" ja nicht angefassen (wie z.B. mit nem 'less' oder per newsreader), sondern will sie nur moeglichst ohne jede Nebenwirkungen, "voellig unbemerkt" in eine andere Partition bewegen. Oder? Beim Backup _kann_ eine geaenderte atime allerdings gewuenscht sein (als Auswahlkriterium fuer den naechsten Backup-Lauf)... Es sollte also auf jeden Fall per Option steuerbar sein.
Wenn der Bootblock der Partition mitkopiert werden soll, kommt auch nur dd in Frage, oder man macht es hinterher per Hand
Bootbloecke per dd kopieren zu wollen ist (mit Verlaub) eine extrem daemliche Idee. Ja, der Wunsch und die Umsetzung scheinen nahe zu liegen. Aber es ist eigentlich immer Unfug (mal mehr, mal etwas weniger grober)... (Details/Argumentation auf Nachfrage) Jeder Bootmanager/-loader der diese Bezeichnung verdient (also der von DOS/Windows[2] nicht) laesst sich auch woanders als nur im MBR installieren. \begin{WavyLines} Ich habe IIRC (kann sein, dass ich noch welche vergessen habe): - Grub im MBR (also /dev/hda) (mein altes LILO scheint die neuen >127 GB Platten nicht zu moegen), das Grub ist neuer. Eigentlich gehoert da ein LILO hin, bzw. war dort bis der dann die neuen 160 GB Platten (die erste als hdc, die zweite als hdb eingebaut) nicht mehr booten wollte - Grub in /dev/hdc (Config von der SuSE 9.1) - Grub in /dev/hdcX ('/' der 9.1) - Grub in /dev/hdb (Config von habbich vergessen) - ... (noch diverse LILOs/GRUBs mehr an diversen freien Stellen ;) Oder so aehnlich ;) Die drei erstgenannten koennen sich alle gegenseitig via 'chainloader' laden ;) Ich kann also (endlos) durch die verschiedenen "GRUBs" huepfen... BIOS -> GRUB(hda) -> GRUB(hdb) -> GRUB(hdc) -> GRUB(hda) -> GRUB(hdc) -> GRUB(hdb) -> GRUB(hda) -> ... bis einem langweilig wird... ... oder bis die Kiste verreckt... *tuedelluet* Aeh, die GRUBs haben natuerlich alle auch andere Eintraege als die jew. anderen GRUBs... Und nicht jede Variante ist von jedem GRUB aus zu erreichen... Bei der Inst. der 9.1 habe ich Yast den Grub nur in deren /-Partition schreiben lassen, hab mir die Orte/Parameter dort abgeschaut und in den Haupt-Grub kopiert (mit Anpassungen)... Oder ist das der GRUB in hdb? oder hdc? Jedenfalls war der Ziel-BR leer ;) Ja, alles "leicht" chaotisch, historisch bedingt, aber egal. Et löppt. Ich blick durch (mit nachschauen (ggfs. per 'dd if=/dev/hdXY | hexdump' *hehe*)... Und ggfs. editiere ich eben irgendne Config... Oder starte Grub auf dessen Kommandozeile beim booten passend... *g* Meine zweite Bootconfig mit Linux war (IIRC): a) Vamos + DOS + LOADLIN und parallel dazu: b) Vamos + LILO in /dev/hdb4(!) und '/' in /dev/hdb6... (hdb5 war swap). Ja, ich hatte in den ersten Sektoren der erweiterten Partition hdb5 (Typ 0x05) eben den Platz fuer LILO und Vamos konnte den LILO dort starten. YAST konnte mir dieses Setup allerdings nicht einrichten. ...oder war die Kombi-Loesung mit Loadlin die mit Debilian 1.3 ein Jahr frueher??? \end{WavyLines} *hihi* *pfeif* *floet* \begin{mode}[DURCHSAGE] *DING DOINNG DONNNGGGGG* ACHTUNG! WIR BITTEN UM IHRE AUFMERKSAMKEIT! Dies ist eine Warnung zur Wahrung Ihrer geistigen Gesundheit! OBIGES (\begin{WavyLines} bis \end{WavyLines}) IST NICHT UND IN KEINSTER WEISE ZUR NACHAHMUNG EMPFOHLEN!!! ES GEFAEHRDET IHRE GEISTIGE GESUNDHEIT! Vielen Dank fuer Ihre Aufmerksamkeit. *DING DOINNG DONNNGGGGG* \end{mode} *ueberrascht und gaaanz unschuldig guck* Bei Interesse kann ich auf Details eingehen, aber da bitte ich darum die LILO-Doku (user.{txt,dvi} und tech.{txt,dvi}) und Grub Doku (info grub) zu lesen... Vorweg: ja, es gibt Sonderfaelle wo man _TEILE_ von Bootcode auslesen/kopieren sollte. Man sollte aber _GENAU_ wissen was man wie und wann wohin kopiert...
Ich tendiere zu letzterem - ein Aufruf von grub-install ist nicht schwer und _deutlich_ angenehmer als ein Vertipper beim dd-Aufruf *g*
ACK. Und ein 'lilo -v' ist auch einfach ;) Die /etc/fstab, die /etc/lilo.conf bzw. die /boot/grub/menu.lst und ggfs. /boot/grub/device.map muss man ja sowieso anpassen. -dnh, die passende sig rausgreppend [1] 2.4.0-test4 seit Aug 3 2000, 2.4.16 seit Dec 14 2001, 2.4.24 seit Jan 28 2004 und 2.4.25 seit Mar 2 2004. IIRC war der Umstieg .16 auf .24 wegen der ersten 160GBer Festplatte. Davor gab's _einige_ 2.2.12 und .14 Versionen (ausgeloest durch den MoBo/CPU-Tausch)... [2] wie's da mit dem von NT/2k/XP aussieht weiss ich nicht, AFAIR ist der zwar wesentlich weitgehender konfigurierbar aber nach wie vor nur in den MBR installierbar. -- Naja, zumindest war Maxtor "weitsichtig": mit einer 48bit-Adressierung kann man 134217728 GB (128 Petabyte) ansprechen, das sollte eigentlich fuer ein paar Jaehrchen reichen, oder? ;)) [David Haller in suse-linux]