[linux-l] Linux-Installation klonen

[Jan-Benedict Glaw]

On Sat, 2006-07-22 21:39:03 +0200, Frank <eggsperde at gmx.net> wrote:
> 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?

Okay... Da sind ja schon viele Ideen zusammengekommen. Persönlich
vermeide ich `cp' zum Clonen, aber jedem das Seine.

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 ;)

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.

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 at 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.

Der Tenor ist also: Alles so einfach und routiniert wie möglich
gestalten.  Das wird sich spätestens dann auszahlen, wenn man das mal
im Tiefschlaf morgends um 4 Uhr machen muß...

MfG, JBG

-- 
       Jan-Benedict Glaw       jbglaw at lug-owl.de                +49-172-7608481
 Signature of:                     ...und wenn Du denkst, es geht nicht mehr,
 the second  :                            kommt irgendwo ein Lichtlein her.
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20060729/48220217/attachment.sig>