Backupkonzept

Backupkonzept mit tar

Der kleine Linuxuser braucht ein kleines Backupkonzept mit dem er regelmäßig seine Dateisystemsicherungen machen kann. Was er aber vor allem braucht, ist die Sicherheit mit Hilfe dieses Backups sein System jeder Zeit auch wieder schnell herstellen zu können.

Im folgenden hier einige dokumentierte Beispiele, die bei der Erstellung eines kleinen Backupkonzeptes mit Bordmitteln von Linux behilflich sein sollen.

Komplettsicherung 

Sicherung eines Linuxrechners mittels des tar-Befehles

Komplettes Restore 

wiederherstellen des Systems nach Austausch einer baugleichen Festplatte

Austausch eines laufenden LINUX 

restore auf einem remote Rechner durch die Backupdaten mit gleichzeitigem teilweise Umbau des Systems.

Hinweis:

• Es wird der komplette Ablauf und die vollständigen Befehle mit allen Optionen aufgezeigt
• Befehlsausgaben sind auf die relevanten Informationen gekürzt.
• Die einzelnen Befehle sollten mit Hilfe dieser Dokumentation auf andere Systeme recht einfach übertragen und angepasst werden können.
• Es wird auf mögliche Problembereiche hingewiesen.

Komplettsicherung

Die Ausgangssituation:

 
LINUX:~ # df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2              4883300   1131272   3752028  24% /
/dev/sda1               260020     55320    204700  22% /boot
/dev/sda3              4883300   2240880   2642420  46% /usr
/dev/sda6             24837316     49300  24788016   1% /home

LINUX:~ # fdisk -l /dev/sda
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         254      260080   83  Linux
/dev/sda2             255        5023     4883456   83  Linux
/dev/sda3            5024        9792     4883456   83  Linux
/dev/sda4            9793       35003    25816064    5  Extended
/dev/sda5            9793       10747      977904   82  Linux swap / Solaris
/dev/sda6           10748       35003    24838128   83  Linux

Das System ist also auf mehrere Partitionen der /dev/sda verteilt. Es existieren 4 Filesysteme / /usr /boot /home und eine Swappartition. Man sichert mit tar immer komplette Filesysteme von ihrem Mountpoint aus, in seperate Archive. Zuerst sammeln wir jedoch einige Zusatzinformationen vom System ein, die zum Beheben von schweren Fehlern und zum Wiederherstellen des Systems sehr hilfreich sein können. Dazu sammeln wir folgende Dateien und Ausgaben von Befehlen ein, und kopieren diese in ein spezielles Verzeichnis /root/backup , das wir uns zum sammeln der Informationen vom Backup anlegen.

LINUX:/boot/grub # cp device.map menu.lst /root/backup/            #Grubkonfiguration
LINUX:/etc # cp /etc/fstab /root/backup                            #/etc/fstab
LINUX:/etc # fdisk -l > /root/backup/fdisk_l                       #die komplette Partitionierung
LINUX:/etc # dd if=/dev/sda of=/root/backup/sda_MBR bs=512 count=1 #den MBR von der Bootplatte
LINUX:/etc # sfdisk -d /dev/sda > /root/backup/sda_sfdisk_dump     #einen Partitionsdump mit sfdisk 
LINUX:/etc # mount > /root/backup/mount                            #die Ausgabe von mount
LINUX:/etc # df > /root/backup/df                                  #die Ausgabe von df

Diese Informationen können uns später helfen, die orginal Partitionierung, die Filesysteme und Mountpunkte schnell und zielsicher wieder herzustellen.
Je nach Rechner können hier noch mehrere Daten wichtig sein, zB Rechnernamen, Datum, Kernel, initrd, Kernelkonfiguration, Partitionierung weiterer Platten, Filesystemparameter usw. aber man sollte sich wirklich auf das beschränken, was man wirklich zum booten und zur Wiederherstellung der Filesysteme benötigen könnten.

Als nächstes kommt die eigentliche Sicherung. Als Sicherungsmedium dient hier im Beispiel eine 2 Platte die schon nach /mnt temporär gemountet wurde. Gesichert wird mittels tar, die Komprimierung mit gzip schalten wir ein. Eine Logdatei der Namen der gesicherten Dateien wird je Archiv ebenfalls in /root/backup angelegt. Als Namen für diese Listen wählen wir "list.MOUNTPOINT". Damit kann später durch auslesen dieser Dateien schnell festgestellt werden, was in unseren Archiven alles enthalten ist, ohne gleich alle großen Archive auslesen zu müssen
Es werden 4 Filesysteme / /usr /boot /home in jeweils ein eigenes Archiv gesichert. Anschließend wird ein Archiv von /root/backup ebenfalls als seperates Archiv erstellt und in eine eigene Datei die md5sum der 5 Archive geschrieben, das könnte man als Vergleich heranziehen, wenn die Archive zB über das Netz kopiert oder verschoben wurden, oder auf DVD gebrannt wurden.

LINUX:/ # tar -czvl  -f /mnt/root.tgz / >/root/backup/list.root
LINUX:/ # tar -czvl  -f /mnt/boot.tgz /boot >/root/backup/list.boot
LINUX:/ # tar -czvl  -f /mnt/home.tgz /home >/root/backup/list.home
LINUX:/ # tar -czvl  -f /mnt/usr.tgz /usr >/root/backup/list.usr
LINUX:/ # tar -czl  -f /mnt/backup.tgz /root/backup
LINUX:/ # md5sum /mnt/*tgz > /mnt/md5sum.log

Während der Sicherung werden einige Warnungen erscheinen, hier einige Beispiele, was ignoriert werden kann:

tar: Semantics of -l option will change in the future releases.
tar: Please use --one-file-system option instead.
tar: /var/spool/postfix/private/proxymap: socket ignored
tar: /usr/: file is on a different filesystem; not dumped
tar: Removing leading `/' from member names
tar: Removing leading `/' from hard link targets 

Die komplette Sicherung umfasst jetzt folgende Dateien:

LINUX:/ # ls -l /mnt/*
-rw-r--r-- 1 root root   4881455 Aug 26 04:27 /mnt/backup.tgz
-rw-r--r-- 1 root root  17058527 Aug 26 04:12 /mnt/boot.tgz
-rw-r--r-- 1 root root   2561794 Aug 26 04:12 /mnt/home.tgz
-rw-r--r-- 1 root root       216 Aug 26 04:34 /mnt/md5sum.log
-rw-r--r-- 1 root root 514285322 Aug 26 03:56 /mnt/root.tgz
-rw-r--r-- 1 root root 843629265 Aug 26 04:24 /mnt/usr.tgz

Damit ist die komplette Sicherung abgeschlossen, die 2 Platte kann jetzt umountet werden, oder die Sicherungsarchive auf einen anderen Rechner oder auf DVD verbannt werden.

Komplettes Restore

Wiederherstellen des Systems aus dem Backup nach Plattentausch

Während man das Backup sehr gut automatisieren kann, bleibt das Restore oftmals Handarbeit. Zu einem Backupkonzept gehört also eine genaue und getestete Beschreibung der Vorgehensweise des Restore.
Wir gehen in diesem Beispiel davon aus, das man die Möglichkeit hat, ein anders Linux von CD/DVD/Floppy zu booten.

An dieses Linux stellen wir folgende Anspüche

• es soll einigermaßen aktuelles LINUX sein
• es muss unsere Festplattenkontroller und Festplatten + CD/DVD automatisch erkennen.
• Sollte die 2 Platte über USB angeschlossen sein, dann natürlich auch diese
• eventuell noch die Unterstützung der Netzwerkkarte
• die wenigen zum Restore benötigte Programme befinden sich auf jeder LiveCD oder RescueCD.
• eine CD/DVD sollte man dennoch vor einem wirklichem Recoverfall auf diesem Rechner nach diesen Kriterien getesten.(und immer am Lagerort der Backupmedien zu finden sein)

Hier im Beispiel wurde von der SUSE 10.1 das Rescue-System gestartet.

Auf solchen von CD/DVD gebooteten Systemen hat man eventuell das Problem, dass fast alle Filesysteme readonly gemountet sind. Es gibt aber in mindestens einem Verzeichnis, meistens unter /tmp, die Möglichkeit ein paar kleine Dateien anzulegen. Obwohl wir in diesem Beispiel auf der 2 Platte die Möglichkeit hätten schreibend zuzugreifen, wollen wir darauf verzichten, das gibt auch denen die Chance das Beispiel nachzustellen, die als Backupmedium eine CD/DVD benutzen.

Als erstes mounten wir unser Backupmedium nach /mnt und da wir uns nicht erinnern wie unsere Partitionierung und unsere Filesysteme aussahen, suchen wir nach den Informationen aus denen wir das erkennen können. Wir lassen uns als erstes die Dateinamen aus backup.tgz ausgeben und schreiben diese in eine Datei /tmp/list

Rescue:/ # mount /dev/sdb1 /mnt
Rescue:/ # tar -tzf /mnt/backup.tgz > /tmp/list
Rescue:/ # cat /tmp/list
root/backup/
root/backup/df
root/backup/menu.lst
root/backup/list.usr
root/backup/fstab
root/backup/mount
root/backup/sda_MBR
root/backup/device.map
root/backup/fdisk_l
root/backup/list.boot
root/backup/list.home
root/backup/list.root
root/backup/sda_sfdisk_dump

Wir benötigen die beiden Dateien fstab und sda_sfdisk_dump. Mit Hilfe von sda_sfdisk_dump läßt sich mit einem einzigem sfdisk Befehl die orginal Partitionierung der Platte wiederherstellen. Aus fstab erkennt man die Mountpunkte und die Filesystemtypen. Wir löschen entweder aus /tmp/list alle anderen Zeilen heraus oder legen diese Datei mit nur diesen beiden Zeilen neu an. Mit dieser Datei können wir dann mit tar diese beiden Dateien aus dem Archiv gezielt nach /tmp entpacken.

Rescue:/ # tar -tzf backup.tgz | grep -e sfdisk -e fstab > /tmp/list
Rescue:/ # cat /tmp/list
root/backup/fstab
root/backup/sda_sfdisk_dump
Rescue:/ # cd /tmp
Rescue:/tmp # tar -xzT /tmp/list -f /mnt/backup.tgz
Rescue:/tmp # find .
./root
./root/backup
./root/backup/sda_sfdisk_dump
./root/backup/fstab
./list

Jetzt kann die Partitionierung von /dev/sda wieder orginal hergestellt werden und die fstab ausgelesen werden

Rescue:/tmp # sfdisk /dev/sda1 < /tmp/root/backup/sda_sfdisk_dump
Rescue:/tmp # cat /tmp/root/backup/fstab
/dev/sda2            /                  reiserfs     defaults              1 1
/dev/sda5            swap               swap         pri=42                0 0
/dev/sda1            /boot              reiserfs     defaults              1 2
/dev/sda3            /usr               reiserfs     defaults              1 2
/dev/sda6            /home              reiserfs     defaults              1 2

Aus der fstab erkennen wir 4 reiserfs auf Partitionen 1/2/3/6 und ein swap auf Partition 5, das legen wir genauso wieder an

Rescue:/tmp # mkfs.reiserfs /dev/sda1
Rescue:/tmp # mkfs.reiserfs /dev/sda2
Rescue:/tmp # mkfs.reiserfs /dev/sda3
Rescue:/tmp # mkfs.reiserfs /dev/sda6
Rescue:/tmp # mkswap /dev/sda5

Jetzt kann man die neuen Filesysteme so einhängen wie sie benötigen werden. Auf /mnt hängt im Moment noch unsere Backuppartition, die hängen wir erstmal weg und mounten statt dessen dort das neue Root-Filesystem /dev/sda2 hin. In dieses legen wir die Einhängepunkte für die anderen Dateisysteme als Verzeichnisse neu an, und mounten anschließend die anderen Filesysteme dort hin. Als Vorlage dient uns die fstab mit dem Unterschied das / als /mnt eingehängt ist. Unser Backupmedium hängen wir dann unter /mnt/mnt wieder mit ein.

Rescue:/tmp # umount /mnt
Rescue:/tmp # mount /dev/sda2 /mnt
Rescue:/tmp # mkdir /mnt/boot /mnt/usr /mnt/home /mnt/mnt
Rescue:/tmp # mount /dev/sda1 /mnt/boot
Rescue:/tmp # mount /dev/sda3 /mnt/usr
Rescue:/tmp # mount /dev/sda6 /mnt/home
Rescue:/tmp # mount /dev/sdb1 /mnt/mnt
Rescue:/tmp # mount
/dev/sda2 on /mnt type reiserfs (rw)
/dev/sda1 on /mnt/boot type reiserfs (rw)
/dev/sda3 on /mnt/usr type reiserfs (rw)
/dev/sda6 on /mnt/home type reiserfs (rw)
/dev/sdb1 on /mnt/mnt type ext2 (rw)

Damit sind die Vorbereitungen für das eigentliche Recover abgeschlossen und man kann die Archive auspacken. Da wir die Verzeichnisnamen relativ zum Rootverzeichnis mit gesichert haben, gehen wir nach /mnt das ja unser Rootfilesystem werden soll.
Komplettsicherungen werden immer in leere Filesysteme ausgepackt, das ist sichergestellt, da wir die Filesysteme neu angelegt haben.

Rescue:/tmp # cd /mnt
Rescue:/mnt # ls -l /mnt/mnt/
-rw-r--r-- 1 root root    4881455 Aug 26 02:27 backup.tgz
-rw-r--r-- 1 root root   17058527 Aug 26 02:12 boot.tgz
-rw-r--r-- 1 root root    2561794 Aug 26 02:12 home.tgz
-rw-r--r-- 1 root root        216 Aug 26 02:34 md5sum.log
-rw-r--r-- 1 root root  514285322 Aug 26 01:56 root.tgz
-rw-r--r-- 1 root root  843629265 Aug 26 02:24 usr.tgz
Rescue:/mnt # tar -xzf /mnt/mnt/root.tgz
Rescue:/mnt # tar -xzf /mnt/mnt/boot.tgz
Rescue:/mnt # tar -xzf /mnt/mnt/usr.tgz
Rescue:/mnt # tar -xzf /mnt/mnt/home.tgz

Das komplette Linux wurde damit wieder in die richtigen Partitionen zurückgesichert. Was jetzt noch gemacht werden muss ist:

• das eingespielte Linux sollte kurz einmal überprüft werden
• der Bootloader muss wieder auf die Bootplatte /dev/sda installiert werden.

Dazu richtet man am besten eine chrootumgebung ein.
Man bindet die Systemefilesysteme /proc /sys /udev in das neues Linuxsystem innerhalb von /mnt ein und setzt den chroot Befehl ab.
Dort kann jetzt das System auf allgemeine Funktion getestet werden (wenn einige Befehle funktionieren / /home /boot und /usr mit Dateien gefüllt sind, sollte es soweit ok sein) und natürlich installieren des Bootloaders auf die neuen Platte. Wenn das alles soweit in Ordnung ist, dann das System mit halt beenden. Wenn alles funktioniert hat, sollte das System jetzt wieder sauber von Platte booten und genau so funktionieren, wie zum Zeitunkt der Sicherung.

Rescue:/ # mount --bind /proc /mnt/proc
Rescue:/ # mount --bind /sys /mnt/sys
Rescue:/ # mount --bind /dev /mnt/dev
Rescue:/ # chroot /mnt
Rescue:/ # grub-install /dev/sda
Rescue:/ # halt

Austausch eines laufenden LINUX

In dem nun folgenden Beispiel für Fortgeschrittene, wollen wir etwas derber mit unserem System umgehen. Wir gehen davon aus, wir haben nicht die Möglichkeit ein 2. Linux mittels CD/DVD zu starten, also zB wie man es auf einem Rootserver vorfinden würden. Unser bestehendes LINUX gefällt uns nicht mehr, oder der letzte Update ging schief, egal jedemfalls möchten wir es gegen das Backup austauschen. Gleichzeitig möchten wir / /usr /boot auf ext3 umstellen, das wollten wir schon lange mal machen, jetzt haben wir die Gelegenheit dazu. Das wird einiges an Konfigurationsarbeit mehr darstellen, als das erste Beispiel, und soll vor allem aufzeigen, was in gewissen Situationen an einem System überprüft und konfiguriert werden muss, damit es wieder sauber bootet. Wir wollen mit 2 Mal reboot sicher zum Ziel kommen.

Die derzeitige Situation:

LINUX:~ # mount 
/dev/sda2 on / type reiserfs (rw)
/dev/sda1 on /boot type reiserfs (rw)
/dev/sda3 on /usr type reiserfs (rw)
/dev/sda6 on /home type reiserfs (rw)
LINUX:~ # df 
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2              4883300   1141720   3741580  24% /
/dev/sda1               260020     55324    204696  22% /boot
/dev/sda3              4883300   2240800   2642500  46% /usr
/dev/sda6             24837316     49488  24787828   1% /home

Wir erkennen, alle Filesysteme sind derzeit reiserfs und /home bietet im Moment noch genügend freien Platz, um das gesamte Linuxsystem System aufzunehmen. Das wollen wir gleich ausnutzen. /home ist im Moment gemountet, es befinden sich keine Verzeichnisse oder Files darin die mit ihrem Namen, mit den Verzeichnisnamen des Rootfilesystems in Konflikt stehen. (Das ist auch der Grund warum sich /usr dafür weniger eignet.)
Bei Namenskonflikten mit Userverzeichnissen müssen solche Dateine/Verzeichnisse vorläufig umbenannt werden. Wir nutzen den Platz und die Möglichkeit unser komplettes Backup neben die Homeverzeichnisse auf /home auszupacken.

Wir binden unser Backup wieder unter /mnt ein und suchen uns die Archive.
Danach packen wir die Archive nach /home aus, wobei wir mit root.tgz , also unserem Rootverzeichnis beginnen, dabei achten wir darauf, das wir uns zum Auspacken im Verzeichnis /home befinden, denn die Daten werden relativ zum aktuellem Verzeichnis ausgepackt.

LINUX:~ # mount /dev/sdb1 /mnt
LINUX:~ # ls /mnt/*tgz
/mnt/backup.tgz  /mnt/boot.tgz  /mnt/home.tgz  /mnt/root.tgz  /mnt/usr.tgz
LINUX:~ # cd /home
LINUX:/home # ls
lost+found  puppe  robi

LINUX:/home # tar -xzf /mnt/root.tgz
LINUX:/home # tar -xzf /mnt/boot.tgz
LINUX:/home # tar -xzf /mnt/usr.tgz
LINUX:/home # tar -xzf /mnt/home.tgz

LINUX:/home # ls
.gnupg    bin   dev   lib         mnt   puppe  sbin    subdomain  usr
.qt       boot  etc   lost+found  opt   robi   sicher  sys        var
.viminfo  data  home  media       proc  root   srv     tmp

Als nächstes wollen wir jetzt das neu eingespielte Linuxsystem auf der /home booten. Damit werden die anderen Partitionen frei. Als Bootsystem werden wir vorerst jedoch noch das alte, sich noch im Verzeichnis /boot befindliche, benutzen.

Achtung: Das geht nur wenn sich der Kernel und die initrd mit dem System das wir jetzt als Rootfilesystem aus dem Backup gewonnen haben, vertragen. Wenn sich der Kernel nicht mit dem Rootfilesystem verträgt, liegt das daran, dass die Module die zum Kernel passen würden, nicht im Filesystem enthalten sind, und der Kernel sie deshalb auch nicht laden kann. Der Rechner wird zwar booten, aber nicht alles sauber starten können. Um sicher zu gehen, müssten wir die Kernelversion im derzeitigen Verzeichnis /boot mit den Verzeichnissen in derzeitig /home/lib/modules vergleichen. Sollte Unverträglichkeit vorliegen, muss hier der Kernel und die initrd aus /home/boot nach /boot kopiert werden und im /boot/grub/menu.lst der kernel und die initrd als Bootparameter eingetragen werden. Sollte das jetzige / und das jetzige /home unterschiedliche Filesystemtypen sein, müssten dazu einige Überlegungen und Konfigurationen mehr gemacht werden, (siehe hierzu auch weiter unten in diesem Beispiel), aber das ist ja bei uns nicht der Fall.

Wir gehen jedoch hier im diesem Beispiel davon aus, das die Filesysteme gleich sind und dass das alte System auf der Platte die selbe Kernelversion hatte wie das gespeicherte System im Backup.

Um das booten des neuen Systems von der alten Bootkonfiguration auszuführen, müssen kleine Änderungen an der derzeitigen Datei /boot/grub/menu.lst und an der derzeitigen /home/etc/fstab vorgenommen werden. Die meisten Zeilen in der fstab können wir auskommentieren, da ja im Moment alles auf einer einzigen Partition liegt.

LINUX:/home # cat /home/etc/fstab  #(vor der Aenderung)
/dev/sda2            /                  reiserfs     defaults              1 1
/dev/sda5            swap               swap         pri=42                0 0
/dev/sda1            /boot              reiserfs     defaults              1 2
/dev/sda3            /usr               reiserfs     defaults              1 2
/dev/sda6            /home              reiserfs     defaults              1 2

LINUX:/home # cat /home/etc/fstab   #(nach der Aenderung)
/dev/sda6            /                  reiserfs     defaults              1 1
#/dev/sda5           swap               swap         pri=42                0 0
#/dev/sda1           /boot              reiserfs     defaults              1 2
#/dev/sda3           /usr               reiserfs     defaults              1 2
#/dev/sda6           /home              reiserfs     defaults              1 2

In der menu.lst ändern wir nur den Eintrag für das Rootdevice

LINUX:/home # cat /boot/grub/menu.lst    #(vor der Aenderung)
    root (hd0,0)
    kernel (hd0,0)/vmlinuz root=/dev/sda2 vga=0x314 acpi=off resume=/dev/sda5 sp
lash=silent  showopts
    initrd (hd0,0)/initrd

LINUX:/home # cat /boot/grub/menu.lst    #(nach der Aenderung)
    root (hd0,0)
    kernel (hd0,0)/vmlinuz root=/dev/sda6 vga=0x314 acpi=off resume=/dev/sda5 sp
lash=silent  showopts
    initrd (hd0,0)/initrd

LINUX:/home # init 6

Das System sollte jetzt einen Reboot ausführen und als einzige Datenpartition die /dev/sda6 einbinden

LINUX:~ # mount
/dev/sda6 on / type reiserfs (rw)

LINUX:~ # df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda6             24837316   3404956  21432360  14% /

Jetzt haben wir das komplette System, das wir im Backup gesichert hatten, zu einem fast vollständig lauffähigen System auf einer einzigen Partition gemacht.
Die einzige Einschränkung, dieses System hat keine eigene funktionieren Bootkonfiguration, wir haben ja mittels der geänderten alten Konfiguration auf /dev/sda1 gebootet. Wir wollen dieses System jetzt aber nur als Hilfssystem benutzen und wollen weiter an unserem entgültigen System herumbauen.

Die anderen Partitionen sind frei geworden, wir legen jetzt darauf die neue Filesysteme an, aber wir ändern jetzt auf ext3 Filesysteme.
Danach mounten wir wieder unseren neuen Dateibaum ( Ausnahme hier im Beispiel das Homeverzeichnis, die alten Userverzeichnisse sind im Moment ja noch auf dem derzeigigen Rootverzeichnis. Wir müssen das deshalb jetzt anders behandeln) Die anderen Verzeichnisse werden wie in vorherigen Beispiel wieder mit den Daten gefüllt.

LINUX:~ # mkfs.ext3 -j /dev/sda1
LINUX:~ # mkfs.ext3 -j /dev/sda2
LINUX:~ # mkfs.ext3 -j /dev/sda3
LINUX:~ # mount /dev/sda2 /mnt
LINUX:~ # mkdir /mnt/boot /mnt/usr /mnt/home /mnt/mnt 
LINUX:~ # mount /dev/sda1 /mnt/boot
LINUX:~ # mount /dev/sda3 /mnt/usr
LINUX:~ # mount /dev/sdb1 /mnt/mnt
LINUX:~ # ls /mnt/mnt/*tgz
/mnt/mnt/backup.tgz  /mnt/mnt/home.tgz  /mnt/mnt/usr.tgz
/mnt/mnt/boot.tgz    /mnt/mnt/root.tgz

LINUX:/mnt # tar -xzf /mnt/mnt/root.tgz
LINUX:/mnt # tar -xzf /mnt/mnt/boot.tgz
LINUX:/mnt # tar -xzf /mnt/mnt/usr.tgz

Unser jetziges Rootverzeichnis enthält noch die Homeverzeichnisse des alten Systems, diese löschen wir und kopieren an deren Stelle die jetzigen Homeverzeichnisse, die haben wir ja vor dem letzen Reboot schon aus dem Backuparchiv entpackt. In diesem Beispiel benutzen wir cpio dafür.

LINUX:/mnt # cd /
LINUX:/ # rm -rf robi puppe
LINUX:/ # cd /home
LINUX:/home # ls
lost+found  puppe  robi
LINUX:/home # find puppe robi | cpio -pdumC65536  /

Wie im vorherigen Beispiel legen wir auch jetzt wieder eine chroot-Umgebung an, um das System zu testen und die notwendigen Änderungen vorzunehmen damit das System wieder sicher bootet.

LINUX:/home # mount --bind /proc /mnt/proc
LINUX:/home # mount --bind /sys /mnt/sys
LINUX:/home # mount --bind /dev /mnt/dev
LINUX:/home # chroot /mnt
LINUX:/ #

Wir überprüfen und ändern die fstab, wir müssen jetzt hier die Filesystemtypen und eventuell die Mount Optionen ändern.

LINUX:/etc # cat /etc/fstab
/dev/sda2            /                  reiserfs     defaults              1 1
/dev/sda5            swap               swap         pri=42                0 0
/dev/sda1            /boot              reiserfs     defaults              1 2
/dev/sda3            /usr               reiserfs     defaults              1 2
/dev/sda6            /home              reiserfs     defaults              1 2

LINUX:/etc # cat /etc/fstab
/dev/sda2            /                  ext3         defaults              1 1
/dev/sda5            swap               swap         pri=42                0 0
/dev/sda1            /boot              ext3         defaults              1 2
/dev/sda3            /usr               ext3         defaults              1 2
/dev/sda6            /home              reiserfs     defaults              1 2

Wir überprüfen die /boot/grub/menu.lst, da wir jedoch keine Veränderungen an den Partitionen oder der Zuordnung des Rootverzeichnisses vorgenommen haben, ist die im Backup enthaltene schon richtig, wir prüfen das aber dennoch.

LINUX:/etc # cat /boot/grub/menu.lst
title SUSE 10.1 
    root (hd0,0)
    kernel (hd0,0)/vmlinuz root=/dev/sda2 vga=0x314 acpi=off resume=/dev/sda5 sp
lash=silent  showopts
    initrd (hd0,0)/initrd

Problem Filesystemwechsel

Jetzt kommen wir zu neuen Problemen, die wir uns mit dem Ändern der Filesystemetypen eingehandelt haben. Wir haben das Dateisystem in dem sich die Dateien /boot/grub/* befinden gewechselt. Das müssen wir aber dem Bootloader mitteilen, sonst erwartet der Bootloader noch ein reiserfs dort. Wir müssen also einen neuen Bootloader auf die Bootplatte schreiben.
Wir haben aber auch den Type von unserem Rootfilesystem gewechselt, wenn der Kern jetzt nicht das Kernelmodul für das neue Filesystem hat, dann bleibt unser boot hängen. Welche Module im Kernel fest einkompiliert sind, könnten wir aus der /boot/config..... Datei herauslesen, dort im Abschnitt File systems steht CONFIG_EXT3_FS=m also ext3 ist hier nicht im Kernel enthalten sondern muss als Modul vor dem Einhängen des Rootfilesystems geladen werden.
Das Laden dieser Module während der frühen Bootphase obliegt der initrd. (initrd ist kleines Filesystem das vom Kernel in den Speicher geladen wird, um Module zu laden die nicht im Kernel selbst enthalten sind, noch bevor das Rootverzeichniss geladen wird) Das initrd müssen wir also neu konfigurieren und anlegen. Dazu müssen wir in der Datei /etc/sysconfig/kernel in der Zeile INITRD_MODULES= die Module eintragen die der Kernel zum Laden des Rootfilesystems braucht und anschließend eine neue initrd erstellen.

LINUX:/etc # cat /etc/sysconfig/kernel   #(vor der Aenderung)
INITRD_MODULES="serverworks sym53c8xx processor thermal fan jbd reiserfs"

LINUX:/etc # cat /etc/sysconfig/kernel   #(nach der Aenderung)
INITRD_MODULES="serverworks sym53c8xx processor thermal fan jbd ext3"

LINUX:/etc # mkinitrd -d /dev/sda2
LINUX:/etc # grub-install /dev/sda
LINUX:/etc # init 6

Achtung: es ist möglich, das bei einer älteren Versionen von mkinitrd die Option -d nicht bekannt ist. Sollte es hier zu einer solchen Fehlermeldung kommen, dann reicht auch mkinitrc ohne Optionen, dann holt er sich die Informationen aus der Bootkonfiguration. Dort sollte jetzt ja auch root=/dev/sda2 drinstehen.

Bei diesem Reboot sollte das ursprüngliche Linux jetzt wieder richtig auf den Partitionen verteilt starten.

Wir überprüfen das.

LINUX:~ # mount
/dev/sda2 on / type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
/dev/sda3 on /usr type ext3 (rw)
/dev/sda6 on /home type reiserfs (rw)

LINUX:~ # df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2              4806784   1337100   3225512  30% /
/dev/sda1               251871     26495    212372  12% /boot
/dev/sda3              4806784   2489796   2072816  55% /usr
/dev/sda6             24837316   3411092  21426224  14% /home

Jetzt müssen wir nur noch ein paar Leichen entfernen, auf unserem /home Verzeichnis befindet sich jetzt noch das komplette Linuxsystem das wir dort als Hilfssystem angelegt hatten. Dieses können wir jetzt löschen.

LINUX:~ # cd /home
LINUX:/home # ls -a
.       .qt       boot  etc   lost+found  opt    robi  sicher     success  usr
..      .viminfo  data  home  media       proc   root  srv        sys      var
.gnupg  bin       dev   lib   mnt         puppe  sbin  subdomain  tmp

LINUX:/home # rm -rf .qt boot etc opt sicher success usr .viminfo data home media 
LINUX:/home # rm -rf proc root srv sys var .gnupg bin dev lib mnt sbin subdomain tmp
LINUX:/home # ls -a
.  ..  lost+found  puppe  robi

Damit ist unser Recover und Umbau am System abgeschlossen.

viel Erfolg beim ausprobieren

Robi 12:09, 4. Sep 2006 (CEST)