<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-15"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hallo Jan-Benedict,<br>
<blockquote cite="mid20060729154808.GM1665@lug-owl.de" type="cite">
  <pre wrap="">On Sat, 2006-07-22 21:39:03 +0200, Frank <a class="moz-txt-link-rfc2396E" href="mailto:eggsperde@gmx.net"><eggsperde@gmx.net></a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">ich würde gerne das Dateisystem meiner Linux-Distribution ändern, weiß 
aber noch nicht so genau wie (von ext3 nach XFS :-) ). Direkt 
konvertieren geht leider nicht, und mit dd bzw. partitionimage kommt man 
wohl auch nicht weiter. Also müsste man es mit cp kopieren - aber kriege 
ich damit alle "Spezialdateien" kopiert (mit Kanotix, oder so)? Und 
bleiben die Informationen auch noch erhalten, wenn ich dann alles in 
eine tar.gz-Datei packe? Es ist ein Debian, ich könnte evtl. auch nur 
eine Liste der installierten Pakete erstellen und dann das System 
komplett neu aufsetzen - haltet ihr das für eine bessere Idee?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Okay... Da sind ja schon viele Ideen zusammengekommen. Persönlich
vermeide ich `cp' zum Clonen, aber jedem das Seine.
  </pre>
</blockquote>
Heißt das, dass ein "cp" nicht funktionieren würde (weil?), oder hast
du schlechte Erfahrungen gemacht?<br>
<blockquote cite="mid20060729154808.GM1665@lug-owl.de" type="cite">
  <pre wrap="">
Grundsätzlich empfehle ich immer, strikt partitionsweise vorzugehen.
Also erstmal die neue Platte partitionieren, dann mit mkfs bzw. mkswap
die Partitionen mit Dateisystemen initialisieren. Wenn es sich im eine
bereits formatierte/partitionierte Platte handelt, sollte jede
neuerstellte Partition zudem einmal mit "dd if=/dev/zero
of=/dev/hdXn" blank gemacht werden. (Beispiel: Platte hatte mal eine
Partition mit msdos/vfat; Partition gelöscht, neu angelegt (da hat die
erste Partition natürlich wie die alte erste Partition dieselbe
Start-Adresse.) Wird dann ein mkfs -t ext3 gemacht, bleibt leider
genug vom msdos/vfat übrig, daß der Kernel es als solches erkennen und
mounten kann 8-O)

Danach die neuerstellten Partitionen mounten (z.B. alle unterhalb von
/mnt als /mnt/hda1, /mnt/hda2, ..., oder sonstwie nach Belieben.)

Nun zum Kopieren der Daten. rsync und tar haben sich bei mir stets
tapfer geschlagen. So in etwa sollte das laufen:

# ( cd /usr && tar cpfl - --numeric-owner .;) | ( cd /mnt/hda1 && tar xpf - --numeric-owner ;)
  </pre>
</blockquote>
Das Problem an dieser Variante ist, dass ich nur ein Backup von meiner
Debianpartition ziehen will, ein neues Dateisystem draufmachen und dann
die Kopie wieder zurückspielen möchte. Könnte ich also einfach den
Befehl an der "pipe" trennen und dann nochmal ausführen? Aber dann muss
ich irgendwo noch einen Dateinamen angeben... <br>
<blockquote cite="mid20060729154808.GM1665@lug-owl.de" type="cite">
  <pre wrap="">
Was machen wir da? Wir sorgen dafür, daß einmal ein tar im
Quell-Verzeichnis (hier: /usr) ausgeführt wird. Alle Angaben sollen
stets numerisch (und nicht nach Namen) gemacht werden, dann wird man
auch keine Schwierigkeiten bekommen, wenn man das von einem
Rettungssystem aus macht. Gleichzeitig wird ins Zielverzeichnis
gesprungen und dort das tar-Archiv, das ausschließlich über die pipe
eingefüttert wird, ausgepackt.
  </pre>
</blockquote>
Sehe ich das richtig, dass da nur das "usr"-Verzeichnis kopiert wird?
Heißt das, dass ich das für jedes Verzeichnis wiederholen muss?<br>
<blockquote cite="mid20060729154808.GM1665@lug-owl.de" type="cite">
  <pre wrap="">
Goodies sind das -l, um nur das aktuelle Dateisystem zu lesen.
Insofern muß dieser Befehl einmal für jedes Quell-Dateisystem
ausgeführt werden. Dafür läuft man aber keine Gefahr, in einem Moment
der Umnachtung /proc oder /sys mitkopieren zu wollen. Die beiden "&&"
sorgen dafür, daß das tarball Aus- oder Einpacken nur dann erfolgt,
wenn der Verzeichnis-Wechsel auch geklappt hat. (Dem Leser sei das
Gedankenspiel überlassen, was passiert, wenn man ";" stattdessen
gemacht hat und das Ein- oder Auspacken erfolgt, ohne daß zuvor der
Wechsel ins passende Ziel- oder Quellverzeichnis stattgefunden hat.)

Wenn man das so macht, kann man das fast unverändert auch nutzen, um
die Daten via ssh über ein IP-Netz zu verschiffen:

# (cd /usr && tar cpfl - --numeric-owner --exclude=lost+found .;) | ssh root@zielkiste "cd /mnt/hda1 && tar xpf - --numeric-owner"



Mit rsync kann man im Prinzip dasselbe machen. Da sähe sowas dann
quasi so aus:

# cd /usr && rsync -a --delete --one-file-system --exclude lost+found/ . /mnt/hda1/

...oder in der Netzwerk-Version:

# cd /usr && rsync -e "ssh -l root" -a --delete --one-file-system --exclude lost+found/ . zielkiste:/mnt/hda1/


Das Ausschließen von lost+found ist durchaus wichtig: Es wurde bei der
Erstellung des Dateisystems spezifisch behandelt und das macht bei
traditionellen Dateisystemen (ffs, ext2/ext3, ...) einen Unterschied.
Man "bläht" es künstlich auf, indem man tausende Dateien anlegt und
löscht. Bei konventionellen Dateisystemen wird der "Platz", den ein
Datei-Eintrag in einem Verzeichnis belegt, nie wieder freigegeben.
(Daher ist es auch so "groß":
        d2:/boot# ls -ld lost+found/ .
        drwxr-xr-x 3 root root  2048 2006-07-29 17:38 .
        drwx------ 2 root root 12288 2002-10-31 07:41 lost+found/
)
Dieser Platz wird gebraucht, wenn im Crash- und fsck-Fall Dateien,
deren Name nicht mehr bekannt ist (also herrenlose inodes) wieder zu
einem Namen kommen sollen. Wäre die Platte voll, könnte kein Platz
mehr für diese Namen organisiert werden und einzig das endgültige
Löschen bliebe noch übrig. So ist Platz vorhanden und Namen können
vergeben werden.


Nach dem Kopieren der Daten auf eine neue Platte ist dann ggf. das
Neuinstallieren des bootloaders nötig, wenn die alte Platte entfernt
wird. Das ist natürlich immer vom bootloader und der
Hardware-Konstellation abhängig, aber grundsätzlich scheints mir am
einfachsten, daß aus einem Rettungs-System heraus mit `chroot' zu
machen:

knoppix:~# mkdir /mnt/neues_kopiertes_system
knoppix:~# mount /dev/hdaXy /mnt/neues_kopiertes_system
knoppix:~# mount /dev/hdayX /mnt/neues_kopiertes_system/boot
knoppix:~# chroot /neues_kopiertes_system
knoppix:/# lilo
knoppix:/# exit
knoppix:~#

Auf diesem Wege entgeht man allen Fehlerquellen, die entstehen, wenn
die "geklonte" Platte zuvor über ein Rettungs-System erstellt wurde
und dort nicht dort (primary master, ...) angesteckt war, wo sie im
echten Zielsystem stecken wird.
  </pre>
</blockquote>
Deine Variante funktioniert also in jedem Fall, während "cp" nicht
immer geht. Bin mal gespannt, was die Vertreter von "cp" dazu sagen...
Bin jetzt etwas verunsichert, und SEHR froh, dass noch alles so ist wie
es war.<br>
<br>
Gruß, <br>
Frank<br>
<br>
<br>
<br>
<br>
</body>
</html>