© Andrii Marushchynets / 123rf.com

Gerade für Desktops spielen Rescue-Systeme eine herausgehobene Rolle, weil Desktops sich nicht ad hoc so einfach neu installieren lassen. Der Markt ist in den letzten Jahren allerdings in Bewegung geraten.

Die große Zeit der Rettungssysteme für Linux- und andere Computer ist vorbei: Beliebte Lösungen wie Rescatux sind mittlerweile verwaist oder ihre Entwicklung pausiert zumindest seit mehreren Jahren. Auch bei Knoppix tut sich derzeit nicht mehr allzu viel, da der Entwickler Klaus Knopper mittlerweile als Dozent und Vizepräsident für Digitalisierung an der Hochschule Kaiserslautern stark eingespannt ist.

Immerhin drei waschechte Rettungssysteme existieren noch und erfreuen sich einer aktiven Entwicklung: Grml, SystemRescue und Finnix. Wir fühlen dem Trio und auch dem Urgestein Knoppix im Folgenden näher auf den Zahn.

Knoppix

Wer in der IT schon ein paar Lenze hinter sich gebracht hat, bei dem klingelt garantiert ein Glöckchen im Kopf, wenn der Name Knoppix fällt: Knoppix (Abbildung 1) galt über viele Jahre als mit Abstand beste Linux-Distribution zum Ausprobieren des freien Betriebssystems. Das maßgeblich von Klaus Knopper entwickelte und gepflegte System genoss auch wegen seines Erfinders großen Ruhm, insbesondere innerhalb der deutschsprachigen Linux-Gemeinde. Knopper ist längst gern gesehener Redner bei Konferenzen und Messen wie dem LinuxTag. Obendrein nutzten zur Blütezeit der Distribution zahlreiche Administratoren Knoppix, um beispielsweise im Rahmen von Updates beschädigte Systeme zu reparieren. Insofern galt Knoppix stets auch als potentes Rescue-System.

Abbildung 1: Knoppix gilt als Pionier des Live-Linux auf CD und entwickelte sich später auch in Richtung Rescue-System weiter, mittlerweile gilt seine Entwicklung aber als weitgehend eingestellt.

Mittlerweile ist der einstige Knoppix-Ruhm allerdings etwas verblasst. Die letzte Knoppix-Version, datiert auf 2022, war eine exklusive Beilage des Linux-Magazins, die auf der offiziellen Knoppix-Website gar nicht zum Herunterladen zur Verfügung steht. Dass die Relevanz von Knoppix und ganz grundsätzlich die Relevanz des Prinzips Rescue-System nachgelassen hat, hat aber noch einen anderen Grund: Wo Administratoren im Rechenzentrum früher durchaus zu Knoppix oder dem weiter verbreiteten Grml griffen, um einem System wieder auf die Beine zu helfen, geben heute Lifecycle-Management-Lösungen und Automation den Ton an.

Der Drang hin zur Containerisierung bei den großen Herstellern wie Red Hat oder Canonical hat obendrein dazu geführt, dass Systeme heute deutlich seltener überhaupt Hilfe benötigen. Das Distributionsupgrade von einer Major-Version eines Systems auf die nächste war früher ein nervenaufreibender Akt. Heute umfasst es vor allem die Updates zentraler Werkzeuge des Betriebssystems, während das Update der eigentlichen Anwendungen über Container läuft. Systemd tut ein Übriges, um klassische Fehlerquellen wie Änderungen an der Netzwerkkonfiguration von Systemen nicht mehr automatisch in ein Desaster zu verwandeln. Gerade im Rechenzentrum ist der Bedarf an Rettungssystemen, die man etwa auf einem USB-Stick bei sich haben kann, in den vergangenen Jahren deshalb massiv gesunken.

Benötigt werden Rettungssysteme aber noch immer, vor allem auf Desktops. Hier sind die Spielregeln andere: Nutzer haben keine Lust darauf das alltägliche Arbeitsgerät, im Falle von Problemen vollständig zu löschen, neu aufzusetzen und die wertvollen Daten hinterher per Backup wieder einzuspielen. Auch auf Desktops kommen schwere Havarien des Systems heute zwar deutlich seltener vor als in der Vergangenheit. Weil einerseits Komponenten wie der Linux-Kernel und die Teil des Grundsystems heute deutlich robuster als in der Vergangenheit sind, und weil die Entwickler typischer Desktop-Komponenten obendrein heute auch Rollback-Optionen für den Fehlerfall in ihre Werkzeuge integrieren. Trotzdem ist die Gefahr, dass nach dem Neustart des eigenen Linux-Systems statt des gewohnten Splash-Screens nur noch eine Fehlermeldung kommt auf Desktops heute noch immer gegeben und viel größer als auf Servern. Schon allein deshalb, weil Desktops in den meisten Fällen deutlich regelmäßiger mit Updates ausgestattet werden und dadurch implizit die Gefahr steigt, dass etwas kaputt geht.

Gerade wer Linux auf dem Desktop nutzt, hat insofern auch heute noch Bedarf an einem System wie Knoppix. Weil dieses aber nur noch in einer veralteten Version zur Verfügung steht, stellt sich die Frage nach der passenden Alternative. Durchforstet man das Netz nach aktuellen Rescue-Systemen für Linux. stößt man auf die immer selben Vertreter ihrer Zunft: Grml, RescueSystem (das zuvor noch als RescueSystemCD firmierte) sowie Finnix sind die drei übrig gebliebenen großen Vertreter ihrer Gilde. Komplementär dazu liefert – auch darin liegt ein Grund für den Niedergang der Rescue-Systeme – jede gängige Desktop-Distribution ein Live-Image ihrer selbst, das den Startvorgang und die Modifikation bestehender Systeme ermöglicht. Jede Ubuntu-CD etwa lässt sich ebenso in einen Live-Desktop booten wie aktuelle Images von Open Suse oder Fedora Core. Grund genug, die diversen Optionen genauer anzuschauen und zu beschreiben.

Grml

So etwas wie der Veteran unter den Rettungssystemen ist Grml (Abbildung 2). Die Distribution existiert bereits seit 2005, ihr Hauptmaintainer ist bis heute der Österreicher Michael Prokop, der selbst ebenfalls Debian-Entwickler ist. Kein Wunder also, dass der Grml-Unterbaut aus Debian GNU/Linux besteht. Das war nicht immer so – in der Anfangszeit basierte Grml noch auf Knoppix, erst später änderte Prokop den Unterbau. Mittlerweile ist auch die Grml-Entwicklung deutlich langsamer geworden; die aktuelle Grml-Version datiert auf den Februar 2024 und ist damit aber noch aktuell und auf aktuellen Systemen zu nutzen. Kernel 6.6 trägt dazu entscheidend bei.

Abbildung 2: Grml ist ein echtes Rescue Linux, das zwar eine grafische Oberfläche bietet, den Benutzer aber nicht zwingt, diese auch zu verwenden. Der Kommandozeilen-Modus ist ebenso gut nutzbar. Quelle: Grml / Michael Prokop

Seinen Namen hat das System übrigens von der lautmalerischen Umschreibung des Geräuschs, das Administratoren von sich geben, wenn sie einem System mit Grml zu Leibe rücken müssen. Dieses ist dafür indes perfekt ausgerüstet: Desktop-Umgebungen wie KDE oder GNOME fehlen zwar, dafür bringt Grml aber wenigstens die deutlich schlankeren Alternativen Openbox und Fluxbox mit. Auf eine grafische Oberfläche müssen Admins bei Grml also nicht verzichten, obwohl diese im Regelfall vorrangig als Terminal-Multiplexer zum Einsatz kommen dürften, also um viele Terminals gleichzeitig anzuzeigen.

Pflicht ist die grafische Oberfläche allerdings nicht. Wer also lieber mit der puren Konsole arbeitet, hat in Grml dazu problemlos die Möglichkeit. Von großem Interesse sind für die meisten Nutzer bei Grml vor allem die vielen enthaltenen Konfigurations- und Reparaturwerkzeuge. In Sachen Dateisystemreparatur etwa bringt Grml die volle Palette der Werkzeuge mit, um alle gängigen Linux-Dateisysteme zu inspizieren und zu reparieren. Dasselbe gilt für die Reparatur des Logical Volume Managers (LVM) unter Linux. Auch SoftwarerAID-Konfigurationen sind leicht mit Grml zu untersuchen und wiederherzustellen, sofern das technisch möglich ist.

Besonders verbessert haben sich bei Grml gerade in den späteren Jahren außerdem die verfügbaren Modi, die Grml für den eigenen Betrieb und dessen Vorbereitung bereitstellt. Dazu muss man wissen: Ursprünglich war die Auswahl der Software, die Grml mitbrachte, vor allem vom Wunsch getragen, Platz zu sparen. Das galt sowohl für den Datenträger, auf dem Grml die Admins erreicht, als auch für die Menge an Daten, die Grml auf laufenden Systemen – in Ermangelung lokalen Plattenspeichers – laden sollte. Der ursprüngliche Gedanke war, dass Grml auf eine normale CD passen und auch auf älteren Systemen mit wenig RAM klaglos funktionieren sollte.

Beide Beschränkungen sind inzwischen aber weggefallen. Server oder auch Desktops mit CD-Laufwerk finden sich immer seltener, und viele Admins haben ohnehin keinen Brenner mehr, mit dem sie entsprechende Medien herstellen könnten. Obendrein hat selbst ein recht spartanisch ausgestattetes Notebook heute selten weniger als 8 Gigabyte RAM, die für den Betrieb auch eines großen Grml-Abbilds problemlos ausreichen. Trotzdem geht Michael Prokop mit dem RAM in Grml-Zielsystemen nicht verschwenderisch um, Grml weist noch immer einen ausgesprochen schlanken Fußabdruck auf. Mit CD-ROMs müssen sich Interessierte auch nicht mehr herumschlagen: »grml2usb« existiert seit Jahren und ermöglicht es, eine lauffähige Grml-Installation in kürzester Zeit auf einen handelsüblichen USB-Stick zu schreiben. Wer sich einen Gefallen tun möchte, greift zu einem Stick mit USB-3. Die sollten eigentlich längst Standard sein, noch immer trifft man im Laden aber regelmäßig auf Sticks mit dem langsamen USB-2.

Quasi als Sahnehäubchen auf dem Muffin winkt Grml obendrein mit der Möglichkeit, ein vollständiges Debian-System auf einem Zielsystem zu installieren. Dazu nutzt Grml »debootstrap«, also eben jene Komponente, die letztlich auch der Debian-Installer selber nutzt. In Summe gilt: Grml richtet sich eher an Server-Admins, bietet mithin aber freilich auch erfahrenen Desktop-Nutzern die Möglichkeit, ein System nach einem Problem wiederherzustellen. Nötige Werkzeuge wie »chroot« liegen dafür bei. Obendrein ist Grml aktuell und bringt einen modernen Kernel mit, was die Erkennung zeitgenössischer Hardware deutlich erleichtert.

SystemRescue

Ebenfalls als echter Veteran im Geschäft der Rescue-Distributionen gilt SystemRescue (Abbildung 3). Das erkennt man schon am Namen, denn SystemRescue heißt das Werkzeug erst seit dem Jahr 2020. Der vorherige Name SystemRescueCD deutet darauf hin, für welche Art von Zielmedium die Distribution eigentlich konzipiert war: Ebenso wie Grml sollte SystemRescue nämlich die CD sein, die der Administrator mit ins Rechenzentrum nimmt, um dort Notfallarbeiten auszuführen. Auch bei SystemRescue drehen die Uhren sich aber offenbar weiter und längst ist von CD-Laufwerken keine Rede mehr. Stattdessen kommt SystemRescue heute als ISO-Abbild daher, das sich auch auf USB-Sticks schreiben lässt, und wie Grml bieten die SystemRescue-Macher dafür ein eigenes Werkzeug an. Zumal es mit der CD mittlerweile ohnehin knapp würde, denn die durchschnittliche Abbildgröße von SystemRescue liegt mittlerweile mindestens bei 800 Megabyte, die auf eine CD regulär nicht mehr passen.

Abbildung 3: SystemRescue war früher vorrangig für den Einsatz auf CDs konzipiert und kommt mit grafischer Oberfläche in Form von Xfce daher. Die Distribution bietet allerlei praktische Rettungswerkzeuge wie »ddrescue«. Quelle: SystemRescue

Auch sonst gibt es zwischen SystemRescue und Grml einige Parallelen. Auch hier stößt der Nutzer zum Beispiel auf eine grafische Oberfläche, die bei SystemRescue allerdings auf dem etwas komfortableren Xfce fußt. Die aktuelle Version der Distribution 11.02 vom 29. August 2024 hat außerdem ein Linux in der Version 6.6.47 an Bord, die aktuell genug für alle gängigen Hardwarespielereien sein dürfte. Unter der Haube fußt SystemRescue auf Arch Linux, der genutzte Paketmanager ist also Pacman. Auch SystemRescue bietet übrigens einen Modus zur dauerhaften Installation; hier landet dann aber wirklich SystemRescue auf der Platte und nicht wie bei Grml ein echtes Debian, das auch ohne Grml problemlos funktioniert.

Bei der Auswahl der verfügbaren Werkzeuge in SystemRescue gibt dieses sich vielseitig. Desktopsoftware für eine schnelle Recherche liegt etwa in Form von Firefox 128.1.0 bei, Chromium hingegen fehlt. “Klein aber fein” lautet das Motto also, und trotzdem hat SystemRescue ein paar Highlights im Gepäck. Dazu gehört zweifelsohne die komplette Toolchain für alle gängigen Linux-Dateisysteme ebenso wie Werkzeuge, um MDRAID-Laufwerke oder LVM-Volumes zu reparieren. Vim liegt in der aktuellen Version 9.1 bei, sodass das Editieren von Konfigurationsdateien leicht ist. Auch gängige Programmiersprachen wie Python oder Perl sind an Bord, sodass sich SystemRescue auch als Plattform eignet, um eigene Reparaturwerkzeuge auszurollen.

Wer temporär einen Samba-Dienst betreiben möchte, findet diesen ebenfalls in SystemRescue vor. Ebenso wie Grml enthält SystemRescue zudem GNU Parted zum Partitionieren von Datenträgern sowie die korrespondierende GUI GParted. Backup-Werkzeuge gehören ebenso zum Lieferumfang wie »ddrescue«, mittels dessen sich Blockgeräte auch dann noch zumindest zum Teil auslesen lassen, wenn andere Teile defekt sind. Als Highlight darf Ntfs-3g gelten, ein NTFS-Treiber, mittels dessen sich auch Windows-Systeme bei Bedarf flicken lassen. Hier wird deutlich, dass SystemRescue sich nicht nur an Linux-Nutzer richtet. Wer als Windows-Anwender allerdings noch nie eine Linux-Kommandozeile unter den Fingern hatte, verfällt besser nicht in Euphorie: SystemRescue ist kein zugängliches Allerweltssystem, sondern richtet sich klar an erfahrene Sysadmins mit Linux-Hintergrund, die wissen, was sie tun. Falls es mit der Rettung eines Windows-Systems ad hoc nicht klappt, kann SystemRescue zumindest die Daten des Systems so sichern, dass sie sich im Nachgang auf einem anderen Windows-Rechner wiederherstellen lassen. Gängige Debugging-Werkzeuge wie »ping« oder »traceroute« runden das Angebot ab.

SystemRescue richtet sich mithin nicht nur an Administratoren, die ein konkretes System reparieren wollen, sondern spricht auch jene Situationen an, in denen vor allem ein laufendes System in einem bestimmten Netzwerk mit funktionierender Shell notwendig ist. Entsprechend greifen viele Firmen, die SystemRescue einsetzen, zu einem Trick und machen das System als Standard-Option in einem Netboot-Verfahren verfügbar. So ist SystemRescue auf jedem vom Netz startenden System verfügbar – ebenso wie der Speichertester Memtest, den die Distribution ebenfalls an Bord hat.

Ob Administratoren sich für Grml oder SystemRescue entscheiden, ist vorrangig eine Frage der eigenen Präferenz. Wer eine Debian- oder Ubuntu-Historie hat, wird Grml intuitiv leichter zu bedienen finden, wer eher in der Arch-Welt zu Hause ist, findet in SystemRescue eine überzeugende Alternative.

Finnix Linux

Finnix Linux (Abbildung 4) ist in sich so etwas wie ein Paradoxon. Denn die Distribution datiert zurück bis ins Jahr 1999, und trotzdem haben selbst viele eingefleischte Linux-Admins von ihr bis dato nichts gehört. Wer Finnix intuitiv in Finnland verortet, liegt ebenfalls daneben: Benannt ist das Produkt stattdessen nach seinem Hauptentwickler Ryan Finnie, dessen Kernmotivation ebenso wie bei Knoppix, Grml, SystemRescue und den diversen anderen Distributionen im Erstellen eines Rettungssystems für kaputte Linux-Installationen bestand.

Inwiefern man diese Abstammungsgeschichte stimmig findet, bleibt allerdings dem Betrachter überlassen – denn eingangs basierte Finnix noch auf Red Hat Linux 6.0. Später diente Knoppix als Grundlage des Systems, bis Ryan Finnie schließlich den Schwenk hin zu Debian GNU/Linux vollzog und seither vorrangig Pakete aus dem Testing-Zweig der Debian-Distribution hernimmt. Dabei hat Finnix seine Ursprünge nie vergessen: Auch heute noch gilt das Prinzip, dass Finnix so schmal wie möglich sein soll. Entsprechend hat ein installiertes Finnix-Grundsystem gerade einmal 400 Megabyte. Finnix ist damit die einzige Distribution in diesem Vergleich, die auch heute noch völlig mühelos auf eine normale CD passen würde. Selbstverständlich bieten die Finnix-Entwickler aber auch Möglichkeiten, um das System auf einen USB-Stick zu packen und von dort aus zu benutzen.

Abbildung 4: Anders als Grml und SystemRescue geht Finnix das Thema puristisch an: Nicht nur wird ein GUI ab Werk nicht gestartet, sondern es liegt dem System auch keins bei. Der Mühe Lohn sind schlanke 480 Megabyte für das gesamte Abbild des Betriebssystems. Quelle: Finnix / Ryan Finnie

In Sachen Hardware gibt Finnix sich entsprechend genügsam. Weniger als ein Gigabyte RAM ist nötig, um das System sinnvoll zu benutzen, sodass selbst uralte Computer mit Finnix wiederzubeleben sind. Die Entwickler selbst geben als mindeste Voraussetzung sogar nur 32 MByte an, ergänzt allerdings mit der Bemerkung, dass Finnix durchaus mehr RAM nutzen kann, falls dieser verfügbar ist.

Von den Probanden im Vergleich ist Finnix zudem das aktuellste System. Die letzte Finnix-Release liegt zwar etwas länger zurück als jene von SystemRescue, weil Finnix sich aber aus Debians Testing-Zweig bedient, steht ein aktueller Linux-Kernel 6.8 ebenso zur Verfügung wie eine modernere Toolchain für das Grundsystem. Finnix bietet zudem den größten Support unterstützter Zielplattformen. 32-Bit-Intel-CPUs unterstützt Finnix im Gegensatz etwa zu SystemRescue uneingeschränkt, und auch auf PowerPC-Systemen lässt Finnix sich nutzen, allerdings nur bis einschließlich Finnix 111. Obendrein stellen die Finnix-Entwickler ein Werkzeug namens »finnix-live-build« bereit, das auch Finnix-ISO-Abbilder für andere Architekturen bauen kann, vor allem die ARM- und ARM64-Architekturen spielen hier eine große Rolle. Finnix für ARM64 im Eigenbau kann durchaus eine attraktive Option für die Admins von Mac-Systemen mit Apples M-Prozessor sein, weil es auf diesen grundsätzlich auch lauffähig ist. Von Versprechen im Hinblick auf irgendeine Form der Nutzbarkeit sehen die Finnix-Leute hier aber wohlweislich ab.

Der Purismus in Sachen Distributionsgröße oder unterstützter Plattform fordert auf der praktischen Seite übrigens durchaus seinen Tribut. Anders als Grml oder SystemRescue kommt Finnix beispielsweise nicht mit einer grafischen Oberfläche daher. Das erleichtert einerseits die Wartung der Distribution, weil man sich seitens der Entwickler sämtliche Probleme mit Xorg, Wayland und anderen Lösungen vom Hals schafft. Andererseits sorgt der Ansatz aber auch dafür, dass Finnix sich wirklich nur an erfahrene Profi-Admins wendet, die beispielsweise wissen, wie sie die – durchaus in Mehrzahl vorhandenen – Terminals eines Finnix-Systems aufrufen und nutzen.

Im Hinblick auf die nötigen Werkzeuge zur Systemrettung und Wiederherstellung gibt Finnix sich hingegen keine Blöße. Die meisten Dateisysteme lassen sich mit Finnix entsprechend ebenso prüfen und reparieren wie verschlüsselte Laufwerke mittels Cryptsetup, MDRAID-Laufwerke unter Linux oder LVM-Volumes. Auch ein Backup-Werkzeug liegt der Distribution bei, um Daten von einem lokalen Datenträger woandershin zu kopieren, sollte man letztlich doch die Neuinstallation eines Systems beabsichtigen. Selbstredend finden Nutzer bei Finnix zudem ebenfalls Werkzeuge, um ein fertiges Finnix-Abbild auf eine CD oder einen USB-Stick zu kopieren. Obgleich Finnix wie beschrieben mit 480 MByte problemlos auf eine reguläre CD passen würde, dürften die meisten Admins heute eher zum USB-Stick greifen oder Finnix gleich als System aus einer Netboot-Umgebung heraus zur Verfügung stellen.

Live-Umgebungen

Auch wenn Knoppix heute nicht mehr ganz so regelmäßig gewartet wird wie einst, leben diverse Ideen von Klaus Knopper doch in der gesamten Community fort. Die Live-CD-Abbilder, die alle modernen Desktop-Distributionen heute im Portfolio haben, legen davon Zeugnis ab. Denn mit seiner Idee, ein ganzes Linux-System auf CD zu pressen und von dieser startbar zu machen, gelang Knopper einst ein durchaus großer Wurf. Die Idee zu bootbaren Live-Systemen hatten zwar durchaus schon findige Köpfe vor Knopper – er aber machte die Idee aber so populär, dass sie nach und nach auf die gesamte Linux-Welt übergriff.

Manchem altgedienten Linux-Jünger werden die regelmäßig aufkeimenden Diskussionen in Erinnerung geblieben sein, die sich darum drehten, Knoppix wegen seiner einfachen Nutzbarkeit auf Festplatte zu installieren. Ursprünglich war Knoppix eigentlich auch nicht als reines Rettungssystem konzipiert, sondern sollte vor allem Linux ohne Installation ausprobierbar machen. Als andere sahen, dass das Konzept funktioniert, folgten sie dem Beispiel. Canonical etwa bot von Ubuntu relativ früh ISO-Abbilder an, die direkt in ein Live-System starteten, aus dem heraus sich dann die eigentliche Installation des Betriebssystems anstoßen ließ. Wer sich hier auch an den Grml-Ansatz erinnert fühlt, liegt durchaus richtig – auch Grml zählt in dieser Hinsicht zu den Pionieren.

Heute ist die Welt der Live-Umgebungen fast schon unübersichtlich. Was vorrangig daran liegt, dass jede Distribution, die etwas auf sich hält, eine solche hat. Wer beispielsweise die aktuellen ISO-Abbilder von Ubuntu 24.04 herunterlädt, kann diese wahlweise auf eine DVD bannen oder auf einen USB-Stick schreiben und von diesem unmittelbar seinen Rechner starten. UnionFS & Co. machen es möglich: Das vom Stick gestartete Linux verhält sich so, wie sich auch ein fest installiertes Linux verhalten würde (Abbildung 5). Ein wichtiger Faktor dabei ist auch, dass die Live-Linux heute streng genommen gar nicht mehr read-only sein und alle Inhalte im RAM behalten müssen. Anders als die CDs und DVDs der Knoppix-Jahre sind USB-Sticks schließlich beschreibbar, und gerade dabei kommen UnionFS und seine diversen Ableger und Nachfolger ins Spiel. Administratoren haben heute regelmäßig einen USB-Stick parat, der ein fein getuntes Rettungssystem enthält, das sich durchaus verändern lässt.

Abbildung 5: Zwischen der Live-Version von Kubuntu 24.04 und der installierten Version auf der Platte sind keine großen Unterschiede auszumachen. Auf Rettung spezialisiert ist Kubuntu aber freilich nicht. Quelle: Canonical

Wie beschrieben legten erst spätere Knoppix-Versionen den Fokus etwas stärker auf Systemwerkzeuge, mit denen sich auch Reparaturversuche starten ließen. Wer daraus schließt, dass die Live-Systeme der gängigen Distributionen nicht sonderlich gut auf das Thema Havarie-Korrektur vorbereitet sind, liegt allerdings auch richtig. Wer etwa die aktuellen Live-Abbilder von Kubuntu oder Open Suse hernimmt, bekommt zwar einen realistischen Eindruck von Art und Funktionsweise des Systems. Und möglicherweise finden sich im Rahmen der ohnehin meist installierten Standardpakete auf dem System auch diverse Werkzeuge, die die Rettung eines lokalen Systems ermöglichen. Zum Teil bieten die Distributoren den Menüpunkt “Recovery” sogar im Bootloader-Menü des Live-Abbilds an, wodurch ein anderes oder anders konfiguriertes System vom Stick gestartet wird. In Summe ist die Korrektur von Fehlern und das Retten bestehender Systeme aber nicht der Fokus der Live-Versionen der Desktop-Distributionen. Werkzeuge wie »ddrescue« sind aber immerhin nachinstallierbar – vorausgesetzt der Administrator weiß, was er tut, und wonach er suchen muss. Aus seiner Sicht empfiehlt es sich insofern, für echte Rettungsmissionen lieber zu einer der spezialisierten Distributionen wie Grml, SystemRescue oder Finnix zu greifen.

Fazit

Schaut man sich heute etwa auf DistroWatch um, merkt man schnell: Die ganz große Zeit der Rettungssysteme für Linux- und andere Computer ist vorbei. Beliebte Lösungen wie Rescatux sind mittlerweile verwaist oder ihre Entwicklung pausiert zumindest seit mehreren Jahren. Auch bei Knoppix tut sich nicht mehr allzu viel. Immerhin drei waschechte Rettungssysteme existieren noch und erfreuen sich einer aktiven Entwicklung: Grml, SystemRescue und Finnix. Für welche der Lösungen ein Admin sich entscheidet, obliegt vorrangig den eigenen Präferenzen. Eine schlechte Wahl trifft man in keinem der drei Fälle. (jcb)