Backupkonzept
Inhaltsverzeichnis
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.
 |
Dieses HOWTO zu Linux oder der Abschnitt davon braucht eine Überarbeitung. Weitere Informationen findest Du hier. Deine Hilfe ist gefragt, das HOWTO zu verbessern. Danach entsorge bitte diese Signierung. |
die Option -l die hier verwendet wurde ist mittlerweile in aktuellen Versionen nicht mehr erhalten, was zur Entstehung dieses Howtos noch zu einer unbedeutenten Warnung geführt hat, erzeugt jetzt einen Fehler. Abschnitt muss überarbeitet und neu ausgetestet werden. Robi 11:28, 20. Mär. 2009 (UTC)
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.
| Hinweis: Dieser Artikelabschnitt handelt explizit von der Version GRUB Legacy. Für GRUB 2 sind komplett andere Konfigurationen notwendig, siehe dort |
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
| Hinweis: Dieser Artikelabschnitt handelt explizit von der Version GRUB Legacy. Für GRUB 2 sind komplett andere Konfigurationen notwendig, siehe dort |
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)
