Desaster Recovery mit Hilfe der richtigen Backup Strategie

Backup Folder - cc-by from McDo DesignUnter dem Begriff Desaster Recovery versteht man in der Informationstechnik die Notfallwiederherstellung nach einem Ausfall von Hardware, Software oder Infrastruktur. Der Artikel soll die Grundlagen vermitteln, um Desaster Recovery zu verstehen und bei der Auswahl geeigneter Sicherungs- oder Wiederherstellungsmaßnahmen helfen.

Kommt es als Folge eines Ausfalls von Hardware, Software oder Infrastruktur zu einem Datenverlust, so hängt die gesamte Wiederherstellung maßgeblich von der Vollständigkeit und Aktualität der zuvor erstellten Datensicherungen ab. Um diese möglichst effizient zu gewährleisten, kann eine Kombination aus verschieden regelmäßig auszuführenden Sicherungsarten [2] zum Tragen kommen.

Zwar gibt es einige auf dem Markt befindliche Komplettlösungen zur Notfallwiederherstellung, die alle ihre Vorzüge haben mögen und dennoch nie für alle Bedingungen gleichermaßen gut geeignet sein werden, genauso wenig wie es jenes sagenumwobene Fabelwesen, die eierlegende Wollmilchsau gibt [3]. Diese Speziallösungen sollen in diesem Artikel daher nicht besprochen werden.

Stattdessen soll hier versucht werden, einige Grundlagen zu vermitteln, die helfen sollen, die Funktionsweise eines PC insoweit zu verstehen, als es um den Startvorgang, das Einlesen, Speichern und Reorganisieren dort verwendeter Datenstrukturen sowie deren Wiederherstellung geht. Zu diesem Zweck soll sich hier auf die Verwendung von weit verbreiteten Standardprogrammen beschränkt werden.

Mit Hilfe dieser Grundlagen sollte die Wahl der jeweils erforderlichen Sicherungs- oder Wiederherstellungsmaßnahmen besser getroffen werden können. Auch die abschließende Beurteilung, ob und welches zu verwendende Sicherungsprogramm sinnvoll eingesetzt werden kann, basiert nicht zuletzt auf der Kenntnis dieser Grundlagen.

Grundlagen der Datensicherung

Unter einer Datensicherung [4], versteht man das teilweise oder vollständige Kopieren der auf einem Computer vorhandenen Daten auf ein anderes (häufig transportables) Speichermedium oder Computersystem. Das Gegenteil dieser Datensicherung heißt Datenwiederherstellung.

Zur Auswahl der passenden Backup-Strategie sind im Vorfeld ein paar Überlegungen anzustellen, wie z. B.

  • Was soll gesichert werden? (ein Betriebssystem, Nutzerdaten oder bestimmte Datenblöcke)
  • Wieso soll gesichert werden? (gesetzliche Auflagen, privates Interesse)
  • Wie viel soll gesichert werden? (Komplettbackup/differentielles Backup/inkrementelles Backup)
  • Wie oft und wie schnell soll gesichert werden? (im laufenden Betrieb inkl. damit verbundener Ausfallzeiten, täglich)
  • Wie und wie schnell soll der Zugriff auf die gesicherten Daten erfolgen? (einzelne Dateien oder Archivdatei, einzelne Blöcke oder Datenträger-Abbild/ Image)

Bei der Auswahl der richtigen Vorgehensweise zur Datensicherung oder Wiederherstellung gilt es unter anderem Folgendes zu beachten: Unterstützt das zu sichernde Dateisystem Dateirechte, so spielt der Erhalt dieser meist eine wichtige Rolle für die Funktionalität der zu sichernden Programme. Somit ist bei der Sicherung unbedingt darauf zu achten, dass die Dateirechte [5] erhalten bleiben.

So würden typische Linux-Dateirechte, wie zum Beispiel rwxrw-r-- verloren gehen, wenn man solche Dateien einfach auf andere Partitionen oder Festplatten kopiert, die mit einem Dateisystem wie z. B. FAT oder NTFS formatiert sind. Dieser Verlust ließe sich unter den genannten Voraussetzungen vermeiden, indem man die Dateien zuvor und unter Wahrung der Dateirechte in eine Archivdatei packt. Doch auch innerhalb gleicher Dateisysteme lauern Stolperfallen, die beachtet werden müssen.

So gilt es, die richtigen Parameter zur Wahrung der Dateirechte beim Programmaufruf zu übergeben oder ggf. im Dateimanager einzustellen (Bsp.: cp -a oder rsync -a). Auch sollte man darauf achten, versteckte Dateien, wie sie häufig unterhalb des Home-Verzeichnisses Verwendung finden, in die Sicherung einzuschließen. In Dateimanagern unter einer grafischen (Benutzer-)Oberfläche muss man diese meist erst einmal sichtbar machen, damit sie beim Kopieren ebenfalls übertragen werden.

Die physikalische Position von Dateien auf rotierenden Datenträgern spielt eine maßgebliche Rolle für die Geschwindigkeit des Betriebssystemzugriffs darauf. Daher empfiehlt es sich, die Systempartition und die ggf. vorhandene Swap-Partition möglichst an den Anfang der Festplatte – also nach außen – zu legen, da dort die Schreib-/Lesegeschwindigkeit einer Festplatte am höchsten ist. Sollten zwei Festplatten vorhanden sein, so empfiehlt es sich, Swap- und Systempartition auf verschiedenen Platten zu beheimaten. Selbstverständlich ist auch die Datentransferrate von CD-/DVD-Laufwerken außen am höchsten. Im Gegensatz zur Festplatte befindet sich der organisatorische Anfang der Daten jedoch innen.

Noch maßgeblicher ist die physikalische Position bestimmter Daten für einen funktionierenden Start des Betriebssystems. Deshalb kommt dem Speicherort des Bootloaders [6] und der Partitionstabelle [7], zuständig für die Organisation der Datenstrukturen, eine besondere Bedeutung zu.

Genauere Kenntnisse darüber sind für die Auswahl und Umsetzung der jeweils geeigneten Backup-, Restore- oder Reparatur-Strategie essentiell. Zum besseren Verständnis sollte man daher zunächst die chronologischen Vorgänge beim Booten eines BIOS-basierten Standard-PCs betrachten. Bei Verwendung von GPT [8]-partitionierten Festplatten oder beim Booten per (U)EFI [9] weichen die im Folgenden getroffenen Aussagen teilweise erheblich ab.

Startreihenfolge von x86-Architektur-PCs

Nach dem Einschalten des PC erfolgt zunächst der POST [10], dann initialisiert das BIOS [11] die Hardware. Danach springt es zu dem im BIOS deklarierten ersten verfügbaren Boot-Device und liest dessen ersten Sektor in den Arbeitsspeicher. Falls der Sektor an seinem Ende mit der richtigen Signatur (55AA) versehen ist, führt das BIOS ihn aus. Ansonsten wird eine Fehlermeldung ausgegeben. Bei gültiger Signatur wird als Nächstes der Bootloader-Code ausgeführt, der unter anderem die Partitionstabellen auswertet, falls diese vorhanden sind (siehe VBR [12]). Das ist auch der Grund, warum einem Standard-BIOS nichts von der Existenz der einzelnen Partitionen bekannt ist.

Der weitere Bootvorgang hängt maßgeblich vom ausgeführten Bootloader und der BIOS-Implementierung ab und kann daher recht unterschiedlich ausfallen, zumal es so etwas wie einen BIOS-Standard gar nicht gibt.

Bootloader

Ursprüngliche Bootloader suchen in der Partitionstabelle nach einer sichtbaren, aktiven primären Partition. Ist diese vorhanden, so wird nach dem Prinzip des Chainloading [13] deren Boot-Sektor geladen und ausgeführt. Erst dadurch wird dann das eigentliche Betriebssystem geladen.

Viele alternative Bootmanager halten sich nicht an diese Konvention und zeigen stattdessen ein Auswahlmenü oder Ähnliches an, um übersichtlich und flexibel das Booten auch von nicht als aktiv gekennzeichneten primären wie auch logischen Partitionen zu erlauben.

Es gibt BIOS-Implementationen, bei denen das Booten aller Betriebssysteme fehlschlägt, falls keine oder mehrere Partitionen mit dem „active flag“ gekennzeichnet sind. Dabei benötigt vor allem Windows eine Partition mit dieser Kennzeichnung, um davon booten zu können.

Besonders schlanke Bootloader finden vollständig Platz im MBR. Passt der Bootloader-Code dagegen nicht vollständig in die ersten 440 Byte des MBR, so wird meist in verschiedenen Stufen (Stages) gebootet. Diese verteilen sich über mehrere nacheinander zu ladende Dateien, die gelegentlich „Stage“ zuzüglich einer Nummer im Namen tragen. Besagte erste 440 Byte des MBR enthalten dann u. a. die erste Stufe. Der physikalische Speicherort der zweiten zu ladenden Stufe ist fest im Bootloader-Code des MBR als Verweis auf den als nächsten zu ladenden Sektor hinterlegt.

Das ist nötig, weil zu diesem frühen Zeitpunkt noch kein Dateisystem-Treiber zur Verfügung steht, um die Datei unter ihrem Pfad ansprechen zu können. Nach dem Laden der zweiten Stufe steht dann ein Dateisystemtreiber zur Verfügung, um weitere zu ladende Stufen oder Dateien per Pfadangabe, also unabhängig von ihrer physikalischen Position (Sektor-Nummer) auf dem Datenträger, ansprechen zu können.

Ein fehlender, verschobener oder defekter Bootloader im MBR eines zum Booten ausgewählten Laufwerkes führt dazu, dass nicht von der Festplatte gebootet werden kann, selbst wenn in einer seiner Partitionen ein intaktes Betriebssystem residiert. Gleiches gilt für die zweite zu ladende Stufe bei mehrstufigen Bootloadern.

Master Boot Record (MBR)

Der Master Boot Record [14] ist der erste Datenblock (Sektor 0, Größe: 512 Byte) eines in Partitionen aufgeteilten Speichermediums wie beispielsweise einer Festplatte oder eines USB-Sticks. Optional kann der MBR auch einen Bootloader enthalten.

Aufbau des MBR
Adresse Funktion/Inhalt Größe (Bytes)
0x0000 / 0 Boot-Loader (Programmcode) 440
0x01B8 / 440 Disk-Signatur (seit Windows 2000) 4
0x01BC / 444 Null (0x0000) 2
0x01BE / 446 Partitionstabelle (4 Partitionen á 16 Byte) 64
0x01FE / 510 MBR-Signatur (0xAA55) 2
Gesamt 512
 

Speichermedien, die nicht in Partitionen unterteilt sind, wie zum Beispiel Disketten oder CDs, enthalten keinen MBR. Hier wird der erste Datenblock als Bootsektor oder auch Boot Record [15], bei FAT-Dateisystemen auch als VBR [12], bezeichnet.

Der Linux-Befehl

1
if=/dev/zero of=<Festplatten-Device> bs=1 count=4 seek=440 conv=notrunc

überschreibt die Disk-Signatur mit Nullen, was für die Zuordnung von Laufwerksbuchstaben zu Partitionen unter Windows (seit Version 2000) von entscheidender Bedeutung ist.

DOS-Partitionstabelle (De-facto-Standard)

Nur der MBR beinhaltet die Partitionstabelle [7], welche die Aufteilung des Datenträgers beschreibt. Das Löschen der Partitionstabelle oder ein Defekt des MBR führen dazu, dass die Daten auf der Festplatte nicht mehr zugeordnet werden können. Es gibt drei Arten von Partitionen: primäre, erweiterte und logische Partitionen. Eine primäre Partition verweist auf einen Bereich der Festplatte, der Dateien enthalten kann.

Eine erweiterte Partition enthält im Gegensatz dazu keine Dateien, sondern dient quasi als Container für weitere logische Partitionen. Daher sollte sie sinnvollerweise so groß gewählt werden, dass sie den verbleibenden Speicherplatz maximal ausnutzt. Die Summe aller darin erzeugten logischen Partitionen sollten wiederum den gesamten Platz der erweiterten Partition verwenden.

Allerdings ist in der Partitionstabelle des MBR kein Platz übrig zum Verweis auf die logischen Partitionen. Aus diesem Grunde enthält eine vorhandene erweiterte Partition als relativen ersten Sektor den sogenannten Partitionssektor, der eine erweiterte Partitionstabelle enthält. Der Sektor ähnelt in seinem Aufbau dem des MBR, allerdings ohne dessen Bootloader-Code. Außerdem werden von den theoretisch möglichen vier nur die ersten zwei Einträge in der erweiterten Partitionstabelle genutzt.

Der erste Eintrag beschreibt die logische Partition. Dessen Startsektor wird immer relativ zur Position dieser erweiterten Partitionstabelle angegeben. Der zweite Eintrag kann eine Verkettung zu einer weiteren erweiterten Partitionstabelle enthalten und hat immer den Typ 5 [16]. Im Startsektor dieses Eintrags wird immer relativ zum Sektor der ersten erweiterten Partition verwiesen. Diese wiederum bietet Platz für ein weiteres logisches Laufwerk und so fort. So entsteht quasi eine Kette von erweiterten Partitionstabellen, die jeweils ein logisches Laufwerk beschreiben.

Erst durch diesen Trick wurde es möglich, mehr als vier Partitionen pro Festplatte zu verwenden. Der jeweils erste Sektor einer primären oder logischen Partition kann ebenfalls als Bootsektor bezeichnet und verwendet werden.

desasterRecovery_Partitionen.png

Verteilung von MBR, Partitionen und erweiterten Partitionstabellen auf dem Datenträger.
 

Der Nachteil von logischen Partition besteht demnach darin, dass deren verkettete Partitionstabellen quer über die Festplatte verstreut sind.

Diese erweiterten Partitionstabellen liegen jeweils im relativen ersten Sektor der entsprechenden logischen Partitionen. Das macht die Datensicherung aufwendiger und erhöht das Risiko von Datenverlust durch Anwenderfehler, da durch das Löschen einer logischen Partition auch alle folgenden nicht mehr sichtbar sind, selbst wenn deren Struktur noch vorhanden ist.

Kategorien der Backup-Programme

Zugriff auf Dateiebene

Programme, die auf Dateiebene arbeiten, wissen nichts über die physikalische Position oder Organisation der Daten auf der Festplatte, denn darum kümmert sich der Dateisystemtreiber des laufenden Betriebssystems. Deshalb muss dieser Treiber auch das zu sichernde Dateisystem unterstützen. Zu erkennen sind solche Programme daran, dass sich die Dateien im Zugriff befinden müssen, um diese sichern zu können. Betriebssystem-übergreifend gesprochen sind die Dateien also vom Anwender zu sehen, Linux-spezifisch ausgedrückt sind diese dabei eingehängt.

Image-Programme

Image-Programme arbeiten eine Ebene tiefer, greifen also direkt auf die Hardware zu, um deren Datenblöcke bzw. Sektoren eigenständig auszulesen. Damit diese Image-Sicherungsprogramme nicht mit den Dateisystemtreibern des Betriebssystems kollidieren, sind die zu sichernden Partitionen vorher auszuhängen. Deshalb kann nicht ohne Weiteres von einer Partition, auf der ein Betriebssystem läuft, ein konsistentes Image-Backup [17] gezogen werden, es sei denn es handelt sich um ein Dateisystem mit Snapshot-Unterstützung. Daher empfiehlt es sich, von einer anderen Partition oder von einem Live-System zu starten.

Größe, Struktur und Dateirechte der gesicherten Daten bleiben in der Image-Datei erhalten, deshalb kann diese auch problemlos auf Dateisystemen ohne Rechte-Unterstützung abgelegt werden, sofern deren maximale unterstützte Dateigröße nicht überschritten wird. Eine Wiederherstellung mit Standard-Tools ist nur auf einer mindestens gleich großen Zielpartition möglich. Ist sie größer, bleibt der überschüssige Platz solange ungenutzt, bis die Partition nachträglich vergrößert wird.

Es gibt aber auch freie Speziallösungen wie zum Beispiel Clonezilla [18] zum Klonen von Images auf kleinere Zielpartitionen, unter der Voraussetzung, dass die Anzahl der belegten Quell-Datenblöcke nicht die Anzahl der zur Verfügung stehenden Ziel-Datenblöcke übersteigt. Doch auch diese komfortablen Werkzeuge können zuweilen an exotischen Aufgaben scheitern, so wie es kürzlich beim Klonen einer meiner Testsysteme geschah. Auszug aus der Clonezilla-Log-Datei:

1
2
3
4
Unpacking grub-legacy (from .../grub-legacy_0.97-67_i386.deb) ...
[1;33mWarning! Found grub partition (/dev/sdb1) file system is ext4! The grub 1
from Debian Linux does not support file system ext4! Skip re-installing grub 1.
The restored OS might fail to boot.

Dann ist es nützlich, wenn man die Grundlagen zur manuellen Vorgehensweise beherrscht.

Grundlegende Betrachtungen vor der Datensicherung

Auf einige Dateien eines laufenden Betriebssystems kann unter bestimmten Bedingungen nicht einmal lesend zugegriffen werden. Andere wiederum werden erst zur Laufzeit erzeugt oder verändern sich im Betrieb, wie z. B. Gerätedateien [19] oder temporäre Dateien [20]. Daher ist es nicht ohne Weiteres möglich, alle Dateien eines laufenden Betriebssystems konsistent zu sichern. Es bedarf dazu bestimmter Voraussetzungen wie z. B. Snapshot-fähiger Dateisysteme. Diese versuchen, alle Schreibzugriffe des laufenden Systems für einen Moment zu unterbinden, um von diesem Zustand dann einen Schnappschuss [21] zu erstellen.

Auf Systemen ohne Snapshot-Unterstützung kann man, mit genauer Kenntnis der kritischen Dateien, diese von der Live-Sicherung exkludieren und somit den größten Teil der Dateien im laufenden Betrieb sichern – auch regelmäßig inkrementell.

Dabei handelt es sich jedoch nicht mehr um ein Komplettbackup oder eine Eins-zu-eins-Kopie des laufenden Systems, auch wenn sich daraus mit zusätzlichem Aufwand wieder ein lauffähiges System erstellen lässt. Eine initial erstellte Vollsicherung sollte aber im Zweifelsfall wenigstens einmal vorhanden sein.

RAID-Systeme [22] spiegeln permanent mindestens zwei Festplatten und erhöhen dadurch die Ausfallsicherheit gegen Festplattendefekte. Gegen Fehler wie z. B. versehentliches Löschen helfen sie jedoch nicht, weshalb der alte Leitspruch gilt: Ein RAID ist kein Backup und ersetzt es demnach auch nicht.

All diese Techniken dienen in erster Linie dazu, wartungsbedingte Ausfallzeiten – auch zur Erstellung von Backups – auf ein Minimum zu reduzieren.

Eine kurze Downtime spielt im privaten Umfeld aber eher eine untergeordnete Rolle, weshalb RAID- oder Snapshot-fähige Dateisysteme hier keine Voraussetzung sein sollen. Stattdessen sollen möglichst einfache und allgemeingültige Wege der Datensicherung aufzeigt werden.

Als Ausgangspunkt zur Erzeugung eines vollständigen Systembackups soll eine beliebige Linux-Live-CD dienen.

Als Voraussetzung sollten auf dieser folgende Pakete vorhanden sein: ntfs-3g, wenn NTFS formatierte Datenträger verwendet werden sollen, ddrsyncnetcat zum Klonen und Kopieren, sfdiskfdiskgdiskgparted zum Partitionieren, ein simpler Text-Editor für Konfigurationsdateien und eine installationsfähige Version des bevorzugten Bootloaders zur Wiederherstellung.

Natürlich muss die Live-CD zur verwendeten Hardware kompatibel, also darauf bootfähig sein. Sollen auch Programme unter einer grafischen Benutzer-Oberfläche, wie z. B. GNU-parted Verwendung finden, so muss darauf ebenfalls ein Windowmanager startfähig sein. Außerdem sollte man wissen, wie man auf dem Live-System die Root-Rechte erlangt.

Sollte keine Live-CD vorhanden sein, kann man die schlanke und flexible SystemRescueCD [23] verwenden, die alle genannten Anforderungen abdeckt.

Sichere in der Zeit, dann hast Du in der Not

Soll eine Datenwiederherstellung auf dem Ursprungsmedium sofort wieder bootfähig sein, so muss das bereits bei der Art der Datensicherung berücksichtigt werden, indem zumindest alle am Bootprozess beteiligten Sektoren mit absolutem Bezug mit gesichert werden.

Vom MBR abgesehen ist es jedoch gar nicht so einfach herauszufinden, wo sich diese befinden, um nur gezielt diese zu sichern. Um solche Details braucht man sich nicht kümmern, wenn man stattdessen ein Image-Backup der gesamten Festplatte erstellt.

Jedoch benötigt es sehr viel Zeit, solch eine Eins-zu-eins-Kopie der gesamten Festplatte zu erstellen. Zwar gibt es schneller sichernde Programme, die in der Lage sind, vom Dateisystem als unbelegt oder gelöscht gekennzeichnete Blöcke von der Sicherung auszusparen, woraus der Geschwindigkeitsvorteil resultiert. Das funktioniert jedoch nur bei vom Programm unterstützten Dateisystemen und somit nicht generell – ganz im Gegensatz zu dd. Dafür ist dd langsamer, da es alle Blöcke sequenziell liest.

Angenommen, man hat einen PC oder einen Laptop mit vorinstalliertem proprietären Betriebssystem, von dem man weder eine Installations-DVD noch eine selbst erstellte Wiederherstellungs-DVDs besitzt.

Eventuell kennt man sich noch nicht gut genug mit seinem System aus, um zu beurteilen, ob sich darauf versteckte Partitionen mit Wiederherstellungs-Images befinden, von denen im Bedarfsfall das System wiederhergestellt werden kann. Auch weiß man vielleicht nicht, ob auf der Festplatte zwischen den Partitionsgrenzen oder an bestimmten Sektorpositionen Daten abgelegt sind, die zum Funktionieren des Systems erforderlich sind.

Man möchte aber den aktuellen Zustand der Festplatte sichern, um diese im Bedarfsfall genau so wiederherstellen zu können. Dann sollten man ein Image-Backup des gesamten Datenträgers erstellen, um auf der sicheren Seite zu sein.

Hat man solch ein Backup erst einmal erstellt und gesichert, so kann man seiner Experimentierfreudigkeit ohne Reue freien Lauf lassen. Für den Fall, dass mal etwas nicht wie erwartet funktioniert, kann man durch ein Restore jederzeit wieder zum vorherigen Stand zurückkehren. So kann man gefahrlos z. B. freie Betriebssysteme installieren und testen, Dual- oder Mehrfach-Boot-Systeme nach persönlichen Vorlieben einrichten und weitere Erfahrungen sammeln.

Bekanntlich führen viele Wege zum Ziel, weshalb man sich den individuell passenden heraussuchen sollte. Auf einem aktuellen Linux-Live-System würde die erste Festplatte des PC typischerweise als sda erkannt werden, die zweite dann als sdb, ganz gleich ob diese intern verbaut oder extern per USB verbunden ist.

Die Laufwerksbezeichnungen muss man also an die jeweiligen Verhältnisse anpassen. In den Beispielen werden die Bezeichnungen sdx stets für den gesamten Datenträger stehen, sdxn für eine Partition des Datenträgers, wie z. B. sda1.
Das hat sich in der Praxis bewährt, da durch stupides Abtippen keine Aktionen ausgelöst werden, sofern keine Platte sdx vorhanden ist.

Einstieg in die Praxis

Zuerst startet man den PC mit der Live-CD, holt sich die Root-Rechte und erzeugt einen Einhängepunkt zum Einhängen der Backup-Festplatte. In den Beispielen wird/mnt/backup benutzt, was man ggf. vorher selbst mittels mkdir -p /mnt/backup erstellen muss.

Dann wird eine ausreichend große und mit dem Dateisystem seines Vertrauens formatierte Partition dort eingehängt:

1
mount /dev/sdxn /mnt/backup

Falls eine NTFS-formatierte Platte zur Sicherung verwendet werden soll, bindet man sie so ein:

1
ntfs-3g /dev/sdxn /mnt/backup

Die Festplatte, von der das Image-Backup gezogen wird, soll wie bereits erwähnt nicht eingehängt sein. Einen kurzen Überblick über die Laufwerksinformationen erhält man u. a. mit lsblk.

Sichern auf Block-Ebene

Image Backups mit dd (dump device)

Die Umkehrung jedes Backup-Befehls zur Wiederherstellung wird zur Vervollständigung jeweils zusätzlich aufgeführt, im Text jedoch nicht mehr detailliert behandelt.

1
2
dd if=/dev/sdx bs=4MB of=/mnt/backup/Devname-sdx.img
dd if=/mnt/backup/Devname-sdx.img of=/dev/sdx bs=4MB

Der erste Befehl erstellt ein Backup des gesamten Datenträgers in eine Image-Datei der exakt gleichen Größe. Vorher muss sichergestellt werden, dass auf dem Zielmedium ausreichend Platz vorhanden ist, da dd diesen nicht prüft.

In der resultierenden Image-Datei wird ungefähr der unbelegte Bereich des Datenträgers an Platz verschwendet. Möchte man diese Verschwendung vermeiden, so kann man die Image-Datei wie folgt komprimieren:

1
2
dd if=/dev/sdx bs=4MB | gzip --best > /mnt/backup/Devname-sdx.img.gz
gunzip –c /mnt/backup/Devname-sdx.img.gz | dd of=/dev/sdx bs=4MB

Tipp zur Kompressionssteigerung: Auch wenn die Platte aktuell vielleicht nur zu 30% belegt ist, so kann es sein, dass durch vielfältige Dateioperationen in der Vergangenheit diese einmal bis zu 100% belegt war. Auch wenn diese einst belegten Sektoren nun wieder freigegeben sind, so enthalten diese dennoch schlecht zu komprimierende Daten. Soll also die komprimierte Image-Datei besonders klein werden, egal welches Kompressionsverfahren verwendet wird, so ist vorher auf Dateiebene der gesamte freie Platz der zu sichernden Festplatte oder Partition mit Nullen zu füllen, indem diese in eine Datei geschrieben werden, die anschließend sofort wieder gelöscht werden muss. Ansonsten gäbe es unerwünschte Effekte wegen Speichermangels, besonders wenn man diesen Schritt als vorbereitende Maßnahme vor der Sicherung aus einem laufenden Linux-System heraus durchführt.

Wenn man es jedoch von der Live-CD aus erledigen möchten, so muss man nun jede der einzelnen Quell-Partitionen unter den zuvor erstellten Einhängepunkten einhängen, z. B. unter /mnt/sdxn und diese dann voll schreiben.

1
dd if=/dev/zero of=/mnt/sdxn/Null.txt; rm /mnt/sdxn/Null.txt

Die Partitionen sollten zur Sicherheit wieder ausgehängt werden und erst dann sollte man den vorigen dd-Befehl zur Sicherung mit Kompression ausführen.

Angenommen, man unterliegt aufgrund des Dateiformates seines Ziel-Laufwerkes einer Datei-Größenbeschränkung von 2 GB. Dann kann man die Image-Datei wie folgt aufsplitten:

1
2
dd if=/dev/sdx bs=4MB |gzip | split -b 2000m /mnt/backup/Devname-sdx.img.gz
gunzipdc /mnt/backup/Devname-sdx.img.gz | dd of=/dev/sdx bs=4MB

Übrigens: Die angegebene Blocksize (bs) von 4 MB deklariert die Speichermenge, die von den Blöcken des Datenträgers in einem Durchgang in den Cache eingelesen wird. Bei passend gewählten Werten, abhängig von der Hardware, kann man die Lese-/Schreibgeschwindigkeit steigern. Dieser Wert muss also nicht zwingend der Blockgröße des Datenträgers entsprechen, sondern sollte zur Performance-Steigerung angepasst werden. Definiert man keine Blocksize, wird als Standardgröße 512 Byte verwendet.

Die bs=block size – mit einem Wert von z. B. 32k, 512k, 1MB oder 4MB – hat aber nicht nur Einfluss auf die Geschwindigkeit, sondern auch darauf, wie viele Daten bei defekten Blöcken verworfen werden. Um möglichst viele Daten zu retten, ist die Blockgröße möglichst klein zu wählen, was jedoch die Lese-/Schreibgeschwindigkeit verringert. Wenn dd auf defekte Sektoren trifft, bricht es den Vorgang ab. Mit der Option conv=noerror werden die defekten Blöcke dagegen einfach übersprungen.

Die Zieldaten werden dadurch aber um so mehr gekürzt, je größer die Blockgröße für das Auslesen der defekten Blöcke gewählt wurde. Daher gilt es bei defekten Datenträgern, die Blocksize zu verringern, trotzdem wird das Ergebnis vom Ursprung abweichen.

Das Programm ddrescue [24] sorgt hier für Verbesserung des Resultates und ist daher das Werkzeug der Wahl, wenn es um die Datenrettung von defekten Datenträgern geht.

Durch geschicktes Parametrieren kann man sein Verhalten dahingehend steuern, dass es im ersten Durchlauf nur die intakten Sektoren ausliest und die Sektornummern mit Lesefehlern in eine Log-Datei schreibt, um sich diesen in einem späteren zweiten Durchlauf intensiver zu widmen.

Diese Strategie erhöht die Chance, bis zum Totalausfall des Laufwerkes möglichst viele Daten zu retten. Die Anzahl der wiederholten Leseversuche pro Sektor lässt sich entsprechend über Parameter steuern. Jede damit gerettete Information ergänzt so nachträglich die im ersten Durchlauf erzeugte Image-Datei.

Eine von vielen Möglichkeiten, dies zu erreichen, könnte so aussehen:

1
2
ddrescue -f -v -n /dev/sdx /mnt/backup/rescue.img /mnt/backup/rescue.log
ddrescue -d -f -r10 /dev/sdx /mnt/backup/rescue.img /mnt/backup/rescue.log

Das mit ddrescue gerettete Image kann man wieder mit dd, so wie im ersten Restore-Beispiel gezeigt, auf eine intakte, mindestens gleich große Festplatte wiederherstellen.

Sinnvoll ist auch die eindeutige Benennung der Image-Dateien, damit eine spätere Zuordnung zweifelsfrei erfolgen kann. Beispielsweise könnte durch Hardware-Veränderungen des Systems sdc zu sdb werden. Auch die UUID ist nicht unbedingt beständig oder eindeutig, da eine geklonte Partition dieselbe UUID wie deren Ursprung erhält. Das sorgt für interessante Effekte bei zwei Festplatten in einem System mit gleicher UUID, wenn diese mit nur einem UUID-Eintrag in der fstab nacheinander eingebunden werden. Empfehlenswert ist daher die Vergabe eindeutiger Namen für die Sicherungs-Images, z. B. anhand der Ausgabe von ls -l /dev/disk/by-id/ der jeweils geklonten Platte oder Partition.

Noch ein Tipp für alle ungeduldigen Zeitgenossen, die während lange andauernder dd-Operationen die Ungewissheit plagt, ob das Programm vielleicht abgestürzt sein mag oder wie weit es wohl fortgeschritten ist. Man kann dd den aktuellen Status entlocken, indem man es kurz anhält, allerdings ohne es gänzlich abzubrechen. Am besten auf einer anderen Konsole oder einem anderen X-Terminal so:

1
killall -USR1 dd

oder wiederkehrend alle (N) Sekunden:

1
watch -n N kill -USR1 `pidof dd`

Um den Status zu sehen, muss man zurück auf die vorherige Konsole wechseln. Zum Beenden der Ausgabe, muss man den watch-Befehl mit „Strg“ + „C“ abbrechen. Weitere nützliche Tipps zu dd lassen sich auf Wikipedia [25] nachlesen.

Natürlich kann man aus einem Image der gesamten Festplatte auch gezielt einzelne Bereiche extrahieren. So kann man beispielsweise nur den in den ersten 440 Byte enthaltenen Bootloader Wiederherstellen:

1
dd if=/mnt/backup/Devname-sdx.img of=/dev/sdx bs=440 count=1

oder aber den gesamten MBR wiederherstellen:

1
dd if=/mnt/backup/Devname-sdx.img of=/dev/sdx bs=512 count=1

Möchte man aus dem zuvor erstellen Image einzelne Dateien extrahieren, so braucht man das Image nur in einen existierenden Einhängepunkt, hier /mnt/Image-sdx, wie folgt einhängen:

1
mount -o loop /mnt/backup/Devname-sdx.img /mnt/Image-sdx

Danach kann man per copy, rsync oder einem Dateimanager einzelne Dateien kopieren oder auch ganze Verzeichnisbäume synchronisieren.

Wer statt eine Image-Datei zu erstellen lieber gleich den gesamten Datenträger auf einen anderen, mindestens gleich großen klonen möchte, könnte zum Beispiel so vorgehen:

1
dd if=/dev/sdx of=/dev/sdy

Schneller geht es mit

1
dd if=/dev/sdx of=/dev/sdy bs=4MB

Ist der Zieldatenträger größer, so ist der überschüssige Platz erst einmal nicht nutzbar. Um diesen Platz zu erschließen, muss man entweder die jeweils letzte Partition in ihrer Größe aufziehen oder stattdessen eine weitere dahinter anlegen, die den verbleibenden Platz ausnutzt. Per Kommandozeile könnte ein Befehl für ein ext-Dateisystem dann zum Beispiel so aussehen, dies ist aber im Bedarfsfall zu prüfen und anzupassen:

1
e2fsck -f -y /dev/sdyn; resize2fs -p -f /dev/sdyn

Sehr komfortabel und intuitiv für viele unterstützte Dateisysteme geht das Gleiche mit dem Programm GNU-parted unter einer grafischen Oberfläche.

Dasselbe gilt natürlich beim Klonen der Festplatte mit dd über ein sicheres internes Netzwerk, z. B. unter Verwendung von Netcat [26].

Dazu gilt es, zuerst den Zielrechner mit der Live-CD zu starten, Root-Rechte zu erlangen, die Netzwerkkarte einzurichten, die IP-Adresse zu notieren, die Zielplatte nicht einzuhängen und dort mit diesem Befehl beginnen, da hierdurch ein auf Port 1234 lauschender Server-Dienst gestartet wird, der sich nach einmaliger Ausführung beendet.

Auf dem Zielrechner (der die Daten empfängt):

1
nc -l -p 1234 | dd of=/dev/sdx bs=2MB

Auf dem Quellrechner (der die Daten versendet):

1
dd if=/dev/sdx bs=2MB | nc IP.of.Target 1234

IP.of.Target ist durch IP-Adresse des Zielrechners zu ersetzen. Der Port ist nahezu beliebig, muss aber auf beiden PCs gleich lauten.

Weniger ist manchmal mehr

Der Nachteil dieser alles umfassenden Sicherung wird aber stets die benötigte Zeit bleiben, worunter naturgemäß deren Aktualität leidet. Steht diese im Vordergrund, so wird man sich andere Sicherungsstrategien wünschen. Kleinere Einheiten lassen sich schließlich schneller sichern und begünstigen dadurch regelmäßigere Sicherungen.

Kennt man sein System gut genug, um zu wissen, ob und welche Teile man auf Block-Ebene sichern muss, so kann man diese entsprechend gezielt per Image sichern. Den Rest des Systems, erst recht die Nutzerdaten, kann man dann auf Dateiebene sichern, inkrementell oder differenziell, um Zeit zu sparen und um durch regelmäßige Backups die Sicherheit zu erhöhen. So ist man im Fehlerfall durch gezielte Wiederherstellung der betroffenen Programme oder Dateien schnell wieder einsatzbereit.

MBR sichern

Wie bereits erwähnt enthält der MBR das gesamte Partitionsschema, falls der Datenträger nur primäre Partitionen verwendet.

Der folgende Befehl führt das Backup durch:

1
dd if=/dev/sdx of=/mnt/backup/MBR_von_sdx.img bs=512 count=1

Ein Restore ist mit dem folgenden Befehl möglich:

1
dd if=/mnt/backup/MBR_von_sdx.img of=/dev/sdx bs=512 count=1

Ein Restore des Bootloaders kann mit diesem Befehl erledigt werden:

1
dd if=/mnt/backup/MBR_von_sdx.img of=/dev/sdx bs=440 count=1

Zum Überprüfen kleiner MBR-Images kann das Kommando hexdump oder für größere Images auch file Dateiname.img verwendet werden.

Achtung: Beim Restore des gesamten MBR wird auch die Partitionstabelle überschrieben. Dies kann zu Datenverlust führen, wenn nach der letzten Sicherung des Bootsektors die Partitionierung geändert wurde. Mit bs=440 bleibt die Partitionstabelle dagegen erhalten, weil dabei nur der Bootloader zurückgeschrieben wird (siehe auch Aufbau des MBR [14])!

Partitionsschema inkl. erweiterter Partitionstabellen sichern

Bei der Verwendung von mindestens einer logischen Partition, also z. B. ab sdx5 aufwärts, wird der Befehl sfdisk aus dem Paket util-linux empfohlen.

Der Parameter -d, auf eine Platte angewandt, zeigt die Partitionstabelle an:

1
sfdisk -d /dev/sdx

Diese kann man nun sichern:

1
sfdisk -d /dev/sdx > /mnt/backup/extPartTable_sdx.sf

Ein Restore kann man dann ebenfalls durchführen, die Platte muss aber dabei ausgehängt sein:

1
sfdisk /dev/sdx < /mnt/backup/extPartTable_sdx.sf

Beim Wiederherstellen sollte man gleich zuerst zumindest den Bootloader oder aber den gesamten MBR mithilfe von dd wiederherstellen, bevor man dann das gesicherte Partitionsschema inklusive aller erweiterten Partitionstabelle(n) wiederherstellt. Danach muss ein Neustart oder das Aushängen und wieder Einhängen dieses Geräts oder der Befehl partprobe erfolgen, damit die neue Tabelle dem Kernel aktiv bekannt gemacht wird.

Sollte jedoch die Partitionstabelle defekt und die Daten auf der Platte sehr wichtig und man sich selbst nicht vollständig sicher sein, dass man auch wirklich die aktuelle Partitionssicherung von dieser Platte vor sich hat, empfiehlt sich eher, die Reparatur einer defekten Partitionstabelle [27] zu versuchen, da sonst die Daten darauf inkonsistent werden. Dazu wird mit Testdisk [28] die Platte untersucht, um die gefundenen Partitionstabellen-Fragmente und/oder Filesystem-Markierungen wieder zu einer Partitionstabelle zusammenzusetzen. Für weitere Sonderfälle gibt es einen guten Artikel bei linupedia.org [29].

Hinweis: Aktuell ist eine Partitionstabelle, wenn es nach ihrer Erstellung keine Repartitionierung des zugrunde liegenden Datenträgers gegeben hat (selbst wenn das Jahre her ist und die Dateien darauf tausendfach verändert wurden).

GPT sichern

Falls der Datenträger anstelle einer DOS-Partitionstabelle mit herkömmlichem MBR bereits das neuere Partitionsschema GPT [8] verwendet, welches bis zu 128 primäre Partitionen ermöglicht, lässt sich ein Backup wie folgt erstellen:

1
dd if=/dev/sdx of=MBR_von_sdx.img bs=512 count=34

Folglich lautet der Befehl zum Restore:

1
dd if=MBR_von_sdx.img of=/dev/sdx bs=512 count=34

Mit diesem Befehl lässt sich das GPT-Schema löschen:

1
dd if=/dev/zero of=/dev/sdx bs=512 count=34

Einzelne Partitionen sichern

Die Vorgehensweise ist identisch wie zuvor beim Sichern der gesamten Datenträger, lediglich die Bezeichnungen sind entsprechend zu ändern (statt sda gibt man nun sda1bzw. die entsprechende Nummer n an).

1
dd if=/dev/sdxn bs=4MB of=/mnt/backup/PartName_sdxn.img

Versteckte Daten sichern

Gesichert wird zwischen dem MBR und dem Beginn der ersten Partition. Diese Bereiche werden gelegentlich von Recovery-Tools oder Bootloadern genutzt. Dazu gilt es auf dem jeweiligen Datenträger herauszufinden, in welchem Sektor die erste Partition beginnt und welche Sektorgröße dieser verwendet.

Das Beispiel zeigt typische 512 Byte/Sektor an:

1
2
3
4
5
6
sfdisk -d /dev/sda
Device Boot Start End #sectors Id System
/dev/sda1 63 81915434 81915372 83 Linux
/dev/sda2 81915435 163830869 81915435 83 Linux
/dev/sda3 * 163830870 245746304 81915435 83 Linux
/dev/sda4 245746305 976768064 731021760 83 Linux

Hier beginnt die erste Partition an Sektor 63. Es soll alles zwischen MBR und Sektor 63 gesichert werden:

1
2
3
4
5
dd if=/dev/sda of=/Pfad/src-hidden-data.img skip=1 bs=512 count=62
62+0 records in
62+0 records out
31744 bytes (32 kB) copied, 0,00106052 s, 29,9 MB/s
9 Sichern auf Dateiebene

Sichern auf Dateiebene

Dabei kann sogar der Zieldatenträger kleiner sein als seine Quelle, vorausgesetzt der belegte Platz reicht aus. Partitionen, in denen Programme enthalten sind, bei welchen die Sektorposition eine Rolle spielt, sind aber weiterhin per Image zu klonen, da es sonst zu Problemen kommt. Linux-Systeme sind von solchen Restriktionen eher nicht betroffen – vom Bootloader einmal abgesehen. Dieser kann jedoch entweder wie zuvor gezeigt per dd separat übertragen werden oder man installiert ihn nachträglich manuell.

Diese Vorgehensweise eignet sich auch sehr gut zum Umsortieren von Partitionsschemata, z. B. für den Fall, dass die auf dem Quelldatenträger weit hinten liegende System- und Swap-Partitionen auf dem Zieldatenträger weiter nach vorn verlagert werden sollen. Oder vielleicht will man beim Übertragen der Daten von der Quelle zum Ziel das Dateisystem konvertieren, vielleicht von Reiser zu ext4 oder von ext4 zu Btrfs.

Bei gewünschter Weiterverwendung muss man das Partitionsschema von der Quell- zur Zielplatte übertragen. Ansonsten kann man nach neuen Bedürfnissen und Platzverhältnissen die Partitionen manuell auf der Zielplatte anlegen, formatieren und benennen. Besonders komfortabel geht das alles in einem Durchgang mit GNU-parted.

Im folgenden Beispiel soll das o. g. Partitionsschema von sda als Quelle dienen. Dieses kann auf sdb übertragen werden oder aber es wird manuell dort mit dem Programm der Wahl erstellt. Die Partitionen im Ziel muss man dann ggf. mit dem neuen Dateisystem formatieren.

Sichern durch Kopieren

Nun muss man unterhalb von /mnt folgende Einhängepunkte erzeugen: sda1 bis sda4 und ebenso für sdb1 bis sdb4.

Dann muss man die Partitionen entsprechend zugeordnet einhängen:

1
mount /dev/sda1 /mnt/sda1

bis

1
mount /dev/sda4 /mnt/sda4

sowie die analogen Befehle für sdb.

Nun gilt es alle Inhalte von sda1 nach sdb1sda2 zu sdb2 etc. zu kopieren, egal ob auf der Konsole mit cp oder mit dem Dateimanager der Wahl. Dann sollte man jedoch daran denken, alle Dateien einzuschließen.

1
cp -a /mnt/sda1/* /mnt/sdb1

falls cp selbst -f („force“) stets interaktiv ist, hilft der Aufruf mit absolutem Pfad.

1
/bin/cp -a(u,f) /mnt/sda1/* /mnt/sdb1

ist für das Update bereits vorhandener Dateien.

Soll dagegen die Reihenfolge der Partitionsinhalte geändert werden, so werden statt einer eins-zu-eins-Kopie die Daten durch das Kopieren verlagert.

Beispiel: Das System liegt im Quell-Datenträger auf sda3, soll nun aber im Zieldatenträger physikalisch möglichst weit nach außen, also auf sdb1 geraten, um die Zugriffszeit zu verringern. Dann würde man analog dazu entsprechend umstellen und später noch die fstab und abhängig vom Bootloader, zum Beispiel die grub.confentsprechend anpassen.

Noch flexibler geht das alles jedoch mit Rsync.

Sichern mit Rsync

Das Synchronisierungsprogramm bietet Optionen, um Dateieigenschaften zu erhalten, arbeitet mit SSH zusammen und eignet sich ideal, um auch große Datenmengen schnell, auch übers Netzwerk (auch via Internet, dann aber besser Verschlüsselt mit -e), zu übertragen.

Besonders vorteilhaft ist Rsync, wenn auf der Zielseite schon eine ältere Kopie vorliegt, denn es überprüft, welche Unterschiede zwischen Quelle und Ziel existieren und überträgt nur die geänderten Teile der Daten. Rsync vergleicht die Daten zweier Speicherorte miteinander. Der grundsätzliche Aufruf lautet daher:

1
rsync [Optionen] Quelle Ziel

Hier ist die Wahl von Quelle und Ziel entscheidend. Zu beachten ist vorher, in welche Richtung man synchronisiert, um einen Datenverlust auszuschließen. Rsync bietet eine Hilfe zum Prüfen des Datentransfers: Zusammen mit der Option -n startet das Programm lediglich einen Testlauf und verrät, welche Operationen es durchführen möchte.

Es folgen ein paar simple Beispiele zu den vielfältigen Kombinationsmöglichkeiten, in Anlehnung an die obigen cp-Befehle.

Hinweis: Der Parameter -a beinhaltet die häufig erforderlichen Parameter -rlptgoD. Beide Variationen erfordern allerdings Root-Rechte.

1
rsync -a --progress --stats --del /mnt/sda1/ /mnt/sdb1/

Wichtig ist jeweils der abschließende Schrägstrich nach der Pfadangabe, im Gegensatz zum vorherigen cp-Befehl.

--progress zeigt den Fortschritt an, benötigt allerdings zusätzliche Zeit, --stats zeigt die Übertragungsstatistik erst am Ende, --del löscht noch während der Übertragung auf dem Ziel Dateien, die auf dem Quelldatenträger nicht vorhanden sind. Weitere Parameter mit den zugehörigen Erklärungen zu den hier verwendeten findet man in der Manpage.

Das ganze sollte man dann für alle Partitionen durchführen, entweder nacheinander oder gleichzeitig von verschiedenen Konsolen aus.

Wer sein System bereits vollständig geklont hat und es als Zweitsystem im gleichen Rechner verwendet, der musste einige Anpassungen der Pfade an fstab und zum Beispiel grub.conf vornehmen. Wenn man die Systeme auf die hier beschriebene Art nur aktualisieren möchte, so ist es sinnvoll die geänderten Dateien oder besser den gesamten Bootloader vom Synchronisieren durch Rsync auszuschließen:

1
rsync -a --del --exclude=/boot/ --exclude=/etc/fstab /mnt/sda1/ /mnt/sdb1/

Wer viel und regelmäßig zu exkludieren hat, schreibt die Pfade und Dateien besser in eine Textdatei untereinander. Dann kann man diese mit --exclude-from=Exclude_Datei als Option einbinden und muss sie nicht jedes Mal erneut eingeben.

Möchten man unter den oben genannten Vorbedingungen die gleichen Partitionen mittels Rsync übers Netzwerk auf die Festplatte eines anderen Rechners übertragen, so sähe der Rsync-Aufruf so aus. Auf dem Quellrechner:

1
rsync -a --progress --del /mnt/sda1/ root@IP.of.Target:/mnt/sdb1/

Auf dem Zielrechner:

1
rsync -a --progress --del root@IP.of.Source.PC:/mnt/sda1/ /mnt/sdb1/

Anschließend wird man aufgefordert, das Root-Passwort des jeweils anderen PC einzugeben (sofern die Authentifizierung nicht über SSH-Schlüssel läuft), bevor die Übertragung beginnt. Das gelingt natürlich nur, wenn dort bereits der ssh-Daemon läuft und wenn sich die beiden Rechner im gleichen Subnetz befinden.

Bei IP.of.Target muss man die IP-Adresse des Zielrechners einsetzen, bei IP.of.Source dagegen die IP des Quellrechners.

Nutzerdaten sichern

Möchte man lediglich regelmäßig alle seine Nutzerdaten auf eine separate Festplatte sichern und das aus einem installierten Linux heraus, also ohne eine Live-CD zu booten, so braucht man lediglich dafür Sorge zu tragen, dass kein Nutzer angemeldet ist. Dann wechselt man auf die Konsole als root, hängt die Sicherungsplatte ein, zum Beispiel wieder unter /mnt/backup und kopiert wiederum per cp oder dem Dateimanager, unter Einschluss aller versteckten Dateien, entweder das gesamte /home Verzeichnis oder nur einzelne ausgewählte Verzeichnisse auf das Sicherungsmedium.

Alternativ und etwas einfacher kann man natürlich Rsync benutzt. Man synchronisiert das /home-Verzeichnis zum Sicherungsmedium mittels des Befehls:

1
rsync -a --progress --del /home/ /mnt/backup/

Vielleicht auch ohne --delete Anweisung, für den Fall, dass die in der Quelle nicht mehr existenten Dateien noch in dem Backup bewahrt werden sollen, falls dafür noch genügend Platz zur Verfügung steht.

Bootloader nachträglich installieren/reparieren

Vielleicht hatte der eine oder andere schon einmal das Problem, dass der Bootloader beschädigt wurde und das System nun nicht mehr startfähig war. Die Gründe dafür können vielfältig sein.

  • Die Installation eines anderen OS oder einer zusätzlich installierten Distribution hat, womöglich ohne Rückfrage oder durch eigenen Irrtum, den bisherigen Bootloader überschrieben.
  • Die Bootloader-Installationsroutine der Distribution schlägt aus unerfindlichen Gründen fehl.
  • Ein Distributionsupgrade/Kernelupdate schlägt fehl und der PC bootet nicht mehr. Der Installer bietet keine separate Installationsroutine für den Bootloader an, eine Neuinstallation wäre dadurch erforderlich.
  • Man hat mehrere Distributionen parallel installiert und möchte dafür Sorge tragen, dass jede ihren eigenen Bootloader mitbringt, damit sie sich bei künftigen Updates nicht mehr gegenseitig beeinflussen. Stattdessen möchte man lieber die einzelnen Bootloader per Chainloading miteinander verbinden.
  • Die Vorgabe der Distribution gefällt nicht, weshalb man deren Bootloader durch einen anderen ersetzen möchte.
  • Man hat sein System geklont, die neuen Rahmenbedingungen machen nun eine Neuinstallation des Bootloaders erforderlich.

Um den Bootloader zu reparieren oder wunschgemäß anzupassen, ist es also von Vorteil, wenn man in der Lage ist, den Bootloader seiner Wahl separat zu installieren und zu kontrollieren. Dabei kann die Wahl des jeweiligen Bootloaders technischen Gegebenheiten geschuldet sein oder sie ist einfach nur eine Frage des Geschmacks. Es muss also nicht zwingend der mit der jeweiligen Distribution vertriebene Bootloader sein. Es gibt eine Fülle von Bootloadern [30]. Bei Bedarf sollte man sich also mit der Dokumentation zum Bootloader seiner Wahl vertraut machen.

Im Folgenden soll jedoch besonders auf die näheren Details zu GRUB-Legacy eingegangen werden.

GRUB – Grand Unified Bootloader

GRUB (Legacy) in der Versionen 0.9x war bis vor kurzem der am häufigsten verwendete Bootloader unter Linux. Allerdings wird er nicht mehr aktiv weiterentwickelt, er funktioniert aber nach wie vor auf den meisten Systemen recht zuverlässig.

GRUB2 wird seit Version 2.x als stabil bezeichnet und gewinnt – nicht zuletzt durch seine UEFI-Unterstützung [9] – stetig an Bedeutung.

Die folgenden Informationen sollen die notwendigen Kenntnisse vermitteln, um GRUB auch nachträglich korrekt installieren und reparieren zu können, was im Fehlerfall extrem hilfreich sein kann.

Auch sollte hierdurch klar werden, warum sich GRUB nicht ohne Weiteres vollständig sichern lässt, ohne ein Image-Backup der gesamten Festplatte zu erstellen, was oftmals nicht gewünscht oder nicht hilfreich ist.

Ein Linux-Bootloader hat eigentlich nur die Aufgabe, den Kernel und die ggf. zugehörige initramdisk in den Arbeitsspeicher zu laden, sodass der Kernel starten kann.
Diese beiden Dateien werden meist als vmlinuz und initrd bezeichnet, oft aber auch als kernel+Name+Arch.+Vers.Nr. und als initramfs+Name+Arch.+Vers.Nr. benannt. Gespeichert sind diese dann auf einem von Linux lesbaren Dateisystem wie z. B. ext, jfs, reiserfs, xfs, etc. Innerhalb dieses Dateisystems lautet der Speicherort der beiden Dateien meist /boot oder sie liegen im Root-Verzeichnis /.

Das Problem ist, dass normale Programme die Unterstützung des laufenden Betriebssystems benötigen, um auf ein Dateisystem zugreifen zu können. GRUB kann also nicht die Betriebssystem-Unterstützung verwenden, um auf das Dateisystem zuzugreifen, da das Betriebssystem zum Einschaltzeitpunkt des PC ja noch nicht zur Verfügung steht.

Natürlich kann man auch ohne Dateisystem-Unterstützung Dateien in den Speicher laden, indem man eine statische Liste der Sektoren verwendet, die mit den jeweiligen Start- und Endpunkten der zu ladenden Dateien korrespondiert. So arbeiten einige andere Bootloader.

Das hat jedoch den Nachteil, dass bei einer Änderung von Position oder Größe der zu ladenden Dateien, z. B. nach einem Kernelupdate, diese Liste vor dem nächsten Startvorgang aktualisiert werden muss, da sonst das System nicht mehr bootet. GRUB dagegen ist flexibler, denn es ist in der Lage, auf das Dateisystem zuzugreifen, um die Dateien zu laden. Dadurch spielt es keine Rolle, ob diese in ihrer Größe oder Lage innerhalb ihres Suchpfades nachträglich verändert wurden. Diese Flexibilität hat allerdings auch ihren Preis, weshalb GRUB so groß wurde, dass er in bis zu drei Stufen ausgeführt werden muss.

Funktionsweise von GRUB1 und den drei möglichen Stufen

Beim Systemstart wird zuerst die kleine Stage 1 aus den ersten 440 Byte des MBR eingelesen und ausgeführt. Diese Stage 1 zeigt statisch auf den Beginn des Sektors, in dem sich die nächste zu ladende Stage befindet. Falls vorhanden, ist es die Stage 1.5, ansonsten wird direkt die Stage 2 geladen.

Wird also nachträglich die Position der zweiten zu ladenden Stage-Datei (1.5 oder 2) verändert, so kann GRUB nicht mehr korrekt starten. Die statische Verknüpfung wird bei der GRUB-Installation in der Stage 1 erzeugt.

Falls die mittelgroße Stage 1.5 vorhanden ist, so enthält diese den Dateisystemtreiber für den dynamischen Zugriff – also per Partitionsnummer und Dateipfad – auf das Dateisystem, unter dem die Stage 2 sowie alle zugehörigen GRUB-Dateien gespeichert sind. In diesem Fall kann die Stage-2-Datei nachträglich gefahrlos verschoben werden.

Es gibt für die unterschiedlichen Dateisysteme viele unterschiedliche Stage-1.5-Dateien, von denen jedoch nur die eine benötigte installiert wird. Stage 2 ist die größte aller Stufen. Sie enthält die Dateisystemtreiber für alle von GRUB unterstützten Dateisysteme, stellt das Bootmenü dar und ermöglicht es, den Kernel und die InitialRamDisk zu laden, um letztlich Linux zu booten.

Physikalische Lage auf dem Datenträger

Die Stage 1 befindet sich entweder im MBR oder aber im Boot-Sektor einer Partition, weil sie nur dort vom BIOS aus zu erreichen ist.

Die Stage 1.5 kann leider an vielen nicht vorhersagbaren Plätzen wie z. B. nicht allozierter oder auch nur ungenutzten Plattenbereichen abgelegt werden. Der beste Platz ist dabei der, der künftig am unwahrscheinlichsten verschoben oder überschrieben wird.

Wenn die Stage 1 im MBR liegt, dann wird die Stage 1.5 am liebsten in den Bereich zwischen dem ersten Sektor und dem Beginn der ersten Partition geschrieben. Aus Gründen der geometrischen Ausrichtung beginnt die erste Partition nicht am zweiten Sektor, also nicht direkt hinter dem MBR (erster Sektor). So bleibt dazwischen Platz, um die gesamte Stage 1.5 dort unterzubringen.

Für die Stage 2 reicht dieser Platz meist jedoch nicht aus, es sei denn man hat manuell den Beginn der ersten Partition weiter nach hinten verlagert, um den nötigen Platz zu schaffen. Sollte der Platz dort für die Stage 2 jedoch reichen, dann wird sie unter Umständen dort abgelegt und statisch verknüpft.

Auch kann die Stage 1.5 im ersten Sektor einer Partition abgelegt werden, wenn ein Dateisystem den dafür notwendigen Raum frei lässt. ReiserFS z. B. startet erst am Offset 65536 einer Partition, was 64 Kilobyte Platz dafür frei ließe.

Wenn eine Stage 1.5 existiert, dann liegt die Stage 2 liegt bei unixoiden Betriebssystemen normalerweise in der Datei /boot/grub/stage2, die dann an einem beliebigen Platz auf der Platte liegen kann.

Allgemeines

Die „Stage 2“ liest die Konfiguration aus /boot/grub/menu.lst oder /boot/grub/grub.conf ein, zeigt ein Bootmenü an in dem der Nutzer auswählen kann was er booten möchte und lädt anschließend den Kernel sowie dessen Image oder startet den Bootloader eines anderen Betriebssystems wie Windows oder eines anderen zusätzlich installierten Linux auf einer anderen Partition.

Durch anwenderseitige Installationsfehler oder nachträgliche Windows-Installationen (diese ersetzen den vorhandenen Bootloader grundsätzlich, denn sie dulden keine anderen Götter neben sich), kommt es gelegentlich zum Überschreiben des vorherigen Bootloaders. Wenn man es vorher versäumt hat diesen zu sichern, empfiehlt sich die erneute Installation von GRUB. Das Risiko ist gering, denn es wird lediglich der Bootloader im MBR und nicht die Partitionstabelle überschrieben. Zusätzlich wird in der definierten Partition das Verzeichnis /boot/grub/ mit einigen Dateien erzeugt. Eine bereits vorhandene grub.conf wird übernommen.

Hinweis: GRUB weist Gerätenamen auf Grundlage des BIOS zu. Wenn man seine BIOS-Einstellungen ändert, können sich auch die Buchstaben und Ziffern der Geräte dadurch ändern. Durch Ändern der Bootreihenfolge der Geräte muss man womöglich auch die GRUB-Konfiguration ändern. Sonst kann es dazu kommen, dass das System nicht mehr bootet.

GRUB mit der SystemRescueCD installieren

Der hier beschriebene Vorgang ist der bevorzugte Weg, gültig für GRUB Legacy (aber nicht für GRUB2 wegen dessen abweichender Syntax).

Gebootet wird mit der SystemRescueCD [24]. Dort existieren unterhalb von /mnt/ gleich einige unbenutzte Einhängepunkte, in die man die Partition einhängen muss, auf welcher die /boot/grub/-Dateien installiert werden sollen. Der Einfachheit halber nimmt man /mnt/custom, natürlich geht auch jeder andere oder selbst erzeugte Einhängepunkt, aber die Syntax muss dann entsprechen angepasst werden. Beliebige Live-CDs, die diese Voraussetzungen erfüllen, sollten ebenfalls funktionieren.

Los geht es mit dem gängigsten Szenario: GRUB in den MBR schreiben und /boot/grub/ soll auf sda1 installiert werden.

Beispiel 1

1
2
mount /dev/sda1 /mnt/custom
grub-install --recheck --root-directory=/mnt/custom /dev/sda

Zuerst muss man die alte grub.conf unter /boot/grub/ kopieren oder erzeugen, wenn sie nicht vorhanden ist. Danach kopiert/installiert man das Betriebssystem/Kernel und ggf. vorhandene Initrd nach /boot/, sofern nicht vorhanden.

Danach muss man neu starten und testen ob es funktioniert. Falls nicht, ggf. obige Konstellation mit der GRUB-Shell durchführen:

1
2
3
4
grub
root (hd0,0)
setup (hd0)
quit

Die Bezeichnung hd0,0 entspricht dabei sda1 (als Zielpartition für die Stage 2 in /boot/grub) und die Angabe <hd0> entspricht sda (als Ziel für den MBR).

Nun sollte es aber gehen, vorausgesetzt die grub.conf stimmt.

Beispiel 2

Das Gleiche funktioniert natürlich mit jedem beliebigen Ziel, in das /boot/grub geschrieben werden soll. Hier wären dann lediglich folgende Änderungen bei der Installation vorzunehmen:

1
2
mount /dev/sdxn /mnt/custom
grub-install --recheck --root-directory=/mnt/custom /dev/sda

Zuerst muss man die alte grub.conf unter /boot/grub/ kopieren oder erzeugen, sofern sie noch nicht vorhanden ist. Danach kopiert und installiert man das Betriebssystem/Kernel und eine gegebenenfalls vorhandene Initrd nach /boot/, sofern diese nicht ohnehin schon vorhanden sind.

Danach muss man neu starten und testen ob es funktioniert hat. Falls nicht, ggf. obige Konstellation mithilfe der GRUB-Shell durchführen:

1
2
3
4
grub
root (hd1,4)
setup (hd0)
quit

Die Bezeichnung hd1,4 entspricht sdb5 (als Zielpartition für die Stage 2 in /boot/grub) und die Angabe <hd0> entspricht sda (als Ziel für den MBR).

Beispiel 3

Beispiel 3 verwendet das Chainloader-Prinzip. Hierzu muss GRUB Nr. 1 exakt wie in Beispiel 1 installiert werden. In der grub.conf des ersten Betriebssystems muss man zusätzlich noch folgenden Eintrag beim Bootloader hinzufügen:

1
2
3
title = Linux
rootnoverify (hd1,1)
chainloader +1

GRUB Nr. 2 installiert man in den Boot-Sektor der zweiten Partition der zweiten Platte (sdb2):

1
2
mount /dev/sdb2 /mnt/custom
grub-install --recheck --root-directory=/mnt/custom /dev/sdb2

Dann muss man die alte grub.conf unter /boot/grub/ kopieren oder erzeugen, wenn sie nicht vorhanden ist. Danach kopiert/installiert man das Betriebssystem/Kernel und ggf. vorhandene Initrd nach /boot/, sofern diese nicht vorhanden sind.

Danach muss man neu starten und testen ob es funktioniert. Falls nicht, ggf. obige Konstellation mit der GRUB-Shell durchführen:

1
2
3
4
grub
root (hd1,1)
setup (hd1,1)
quit

Das erste hd1,1 entspricht sdb2 (als Zielpartition für die Stage 2 in /boot/grub). Das zweite hd1,1 entspricht dem ersten Sektor (Bootsektor) von sdb2 als Ziel für die Stage 1 des zweiten auf dem System installierten Bootloaders.

Hinweis: Der o.g. Parameter --recheck ist besonders dann zu empfehlen, wenn die Drive.map (Laufwerkszuordnung zum BIOS) nicht stimmt oder eine Fehlermeldung ausgibt, was meistens beim Start einer Live-Umgebung der Fall ist. Beim lokalen Rechnerstart kann man ihn meist weglassen, also wenn man z. B. einen zweiten oder dritten GRUB in die jeweiligen System-Partitionen hinzufügen möchte.

Durch die oben gezeigte Vorgehensweise ist kein umständliches vorheriges chroot erforderlich, nur um GRUB per Paketmanager zu installieren, so wie es manche Reparaturanleitung empfiehlt.

Problemfälle aus der Praxis

Bei kuriosen Fehlern, die sich trotz mehrfacher Neuinstallation von GRUB anscheinend nicht beseitigen lassen, sollte man am besten Folgendes als mögliche Ursache überprüfen:

Zeigt der symbolische Link im Verzeichnis /boot/grub/menu.lst auf die Datei grub.conf im gleichen Verzeichnis? Das ist z. B. bei Gentoo ein symbolischer Link auf die grub.conf.

Zeigt der symbolische Link im Verzeichnis /boot/boot auf das gleichnamige Verzeichnis und lässt einen beim Betreten immer tiefer nach /boot/boot/ abtauchen, dann ist das so korrekt. Ansonsten heißt es nun, den falschen Link händisch zu korrigieren oder zu löschen und dann GRUB erneut zu installieren.

Ohne vorherige Korrektur oder Löschen würde sich nichts ändern, denn diese Dateien werden beim erneuten Installieren beibehalten!

Natürlich kann man im Zweifelsfall auch das gesamte /boot-Verzeichnis rekursiv löschen, GRUB neu installieren, den Kernel wieder ins /boot kopieren und dann mit der GRUB-Shell so wie zuvor mit dem root– und setup-Befehl alles nochmal installieren/verifizieren. Danach sollte alles wieder wie gewünscht funktionieren.

Backup oder kein Backup

Man kann die Nutzer in zwei Gruppen einteilen: Diejenigen, die regelmäßig Backups durchführen, und diejenigen, die noch niemals einen Datenträgerdefekt hatten.

Als Eigenmotivation, künftig zur ersten Gruppe zählen zu wollen, braucht man nur etwas näher darüber nachdenken, was der Verlust der eigenen Daten für einen selbst bedeuten würde.

Die Grundlagen zum Sichern vor und Wiederherstellen nach dem Ernstfall sollten nun vorhanden sein. So kann man künftig auftretenden Hardwaredefekten oder Datenverlusten schon etwas gelassener entgegen sehen und ist im Ernstfall, der leider fast immer irgendwann eintritt, wieder zeitnah einsatzbereit.

Der Artikel Desaster Recovery mit Hilfe der richtigen Backup Strategie von Andreas Klein, erschienen bei freiesMagazin unterliegt der CC-BY-SA-3.0 Unportted. Es wird die Erlaubnis gewährt, den Artikel unter den Bestimmungen der Creative-Commons-Lizenz zu kopieren, zu verteilen und/oder zu modifizieren.