Backupkonzept: Unterschied zwischen den Versionen

Aus Linupedia.org
Wechseln zu: Navigation, Suche
(Problem Filesystemwechsel)
Zeile 385: Zeile 385:
 
INITRD_MODULES="serverworks sym53c8xx processor thermal fan jbd ext3"
 
INITRD_MODULES="serverworks sym53c8xx processor thermal fan jbd ext3"
  
 +
LINUX:/etc # mkinitrd -d /dev/sda2
 
LINUX:/etc # grub-install /dev/sda
 
LINUX:/etc # grub-install /dev/sda
 
LINUX:/etc # init 6
 
LINUX:/etc # init 6
 
</pre>
 
</pre>
 +
'''Achtung:''' es ist möglich, das bei einer alten Version 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.
 
Bei diesem Reboot sollte das ursprüngliche Linux jetzt wieder richtig auf den Partitionen verteilt starten.
 +
 +
  
 
Wir überprüfen das.
 
Wir überprüfen das.

Version vom 5. September 2006, 10:33 Uhr

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 der 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

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 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 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. Damit kann später schnell festgestellt werden, was in unseren Archiven alles enthalten ist.
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 folgendes:

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 meist 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
  • benötigte Programme sollten auf jeder LiveCD oder RescueCD befinden.
  • diese CD/DVD sollten wir dennoch vorher auf diesem Rechner nach diesen Kriterien ausprobieren.


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

Wir erkenne 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 noch unsere Backuppartition die hängen wir weg und mounten statt dessen dort das neue Root-Filesystem /dev/sda2 hin. In diese legen wir die Einhängepunkte für die anderen Dateisysteme als Verzeichnisse neu an, und mounten 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 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 und 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 wir es auf einem Rootserver vorfinden würden. Unser bestehendes LINUX gefällt uns nicht mehr und wir möchten es gegen das Backup austauschen, gleichzeitig möchten wir / /usr /boot auf ext3 umstellen. 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 reboots 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 müssen solche Dateine / Verzeichnisse vorläufig umbenannt werden. Wir nutzen die Möglichkeit unser komplettes Backup neben die Homeverzeichnisse auf /home auszupacken.

Wir binden unser Backup unter /mnt ein und suchen uns die Archive.
Danach packen wir die Archive nach /home aus, wobei wir mit root.tgz beginnen, dabei achten wir darauf das wir uns im späterem Rootverzeichnis befinden also /home.

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
.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 nicht laden kann und deshalb nicht sauber booten wird. 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 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.

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 neue Filesysteme darin an, aber wir ändern jetzt auf ext3 Filesysteme.
Danach mounten wir wieder unseren neuen Dateibaum ( Ausnahme hier im Beispiel das Homeverzeichnis, das ist im Moment ja unser 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 wir ja vor dem letzen Reboot schon aus dem Archiv entpackt haben. 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 Filesysteme 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 Änderungen an den Partitionen vorgenommen haben, ist die im Backup enthaltene schon richtig.

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 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 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. Diese müssen wir also neu konfigurieren und anlegen. Dazu müssen wir in der Datei /etc/sysconfig/kernel bei INITRD_MODULES= diese hinzufügen und 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 alten Version 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)