Als ich letzte Woche über die verschiedenen Möglichkeiten berichtete, eine ISO-Datei auf einen USB-Stick zu bringen, habe ich auch das dd-Kommando vorgestellt. Immer im Hinterkopf, die Kommandos eindeutig und mit Links zu den man-Pages zu schreiben, da insbesondere mit dd viele schwerwiegende Fehler begangen werden können, fiel mir auch wieder eine Frage auf Serverfault ein, die vor knapp 2 Jahren im Netz die Runde machte: "Recovering from a rm -rf /" (hier aus dem Internet Archive, da das Original bereits gelöscht wurde)
Der Fragesteller, Betreiber eines kleinen Hostingproviders mit ca. 1500 Kunden, nutzte ein Ansible-Script für die Wartung, welches rm -rf {foo}/{bar} (Warnung für alle, welche die Materie nicht kennen: gefährliches Kommando!) enthielt und aufgrund eines Fehlers die Variablen undefined ließ. Den Rest könnt ihr euch vorstellen. Die Situation wurde nochmals gekrönt, indem alle seine Backups gemountet waren. SNAFU eben.
Die eigentlich lustigste Sache befindet sich in den Antworten. Ein Nutzer empfiehlt ihm, mit testdisk eine file recovery zu machen, vorher aber Sicherheitskopie von der betroffenen Maschine mit dd zu erstellen. Ein eigentlich sinnvoller Schritt. Die Antwort vom Fragesteller:
I swapped if and of while doing dd. What to do now?
Okay, da lag ich am Boden.
Das musste ein Hoax sein (ja, war es zum Glück auch). Serverfault war über die unübliche Aufmerksamkeit nicht so erfreut.
Auch wenn es ein Spaß war, es zeigt, wie einfach solche Fehler passieren können! Achtet deshalb immer darauf, was bei euch if und of ist und vor allem, was das Kommando tut. Und Vorsicht mit solchen Kommandos in Automatisierungsskripten!
Ja, einige werden jetzt sagen, dass ein klassisches "rm -rf /" eigentlich mittlerweile nicht mehr so einfach möglich ist, da es Schutzmechanismen gibt, aber auch dazu gab es bereits Threads auf Serverfault.
