Stell dir vor, es ist Freitagnachmittag, 16:30 Uhr. Du hast den Auftrag, einen in die Jahre gekommenen Webserver auf eine neue Instanz umzuziehen. Du denkst dir: „Kein Problem, ich ziehe einfach eine Debian List Of Installed Packages, spiele die auf dem neuen System ein und fertig ist die Laube.“ Drei Stunden später sitzt du fluchend vor dem Monitor, weil die Hälfte der Konfigurationsdateien fehlt, Abhängigkeiten sich gegenseitig blockieren und der Apache-Server partout nicht starten will, weil ein obskures Modul fehlt, das zwar installiert ist, aber eine völlig andere Versionsnummer hat als auf dem alten System. Ich habe das in Projekten für mittelständische Hoster und Rechenzentren oft gesehen. Leute verbringen ganze Nächte damit, Fehler zu beheben, die nur entstanden sind, weil sie dachten, eine einfache Liste der Pakete sei ein vollständiges Backup oder ein Blueprint für eine Replikation. Das ist ein Irrglaube, der dich in der Praxis teuer zu stehen kommt. Ein Server ist kein Legobausatz, bei dem man nur die Steine zählen muss. Wer blind auf automatische Listen vertraut, ohne die Mechanik dahinter zu verstehen, baut sich eine Zeitbombe.
Der fatale Fehler beim Export der Debian List Of Installed Packages
Der größte Schnitzer passiert meistens schon beim ersten Befehl. Die meisten Admins werfen ein schnelles dpkg --get-selections in das Terminal und fühlen sich sicher. In meiner Erfahrung führt das direkt ins Chaos. Warum? Weil dieser Befehl dir lediglich sagt, welche Pakete den Status „install“ haben. Er unterscheidet nicht zwischen Paketen, die du explizit installiert hast, und solchen, die nur als Abhängigkeit mitgeschleift wurden. Wenn du diese Liste auf einem neuen System einspielst, blähst du dein System künstlich auf. Du installierst Altlasten mit, die auf dem neuen Kernel vielleicht gar nicht mehr nötig sind oder – noch schlimmer – mit neueren Bibliotheken kollidieren.
Ich erinnere mich an einen Fall, bei dem ein Admin eine Liste von einem Debian 10 System auf ein frisches Debian 11 übertragen wollte. Durch das ungefilterte Einspielen wurden hunderte Pakete als „manuell installiert“ markiert, die eigentlich automatisch verwaltet werden sollten. Das Ergebnis war ein System, das bei jedem Sicherheitsupdate Fehlermeldungen spuckte, weil apt autoremove nicht mehr funktionierte. Die Bereinigung dieses Chaos dauerte zwei Arbeitstage. Ein qualifizierter Techniker kostet in Deutschland locker 80 bis 120 Euro pro Stunde. Rechne dir den Schaden selbst aus. Statt einer groben Liste brauchst du den Fokus auf das, was wirklich zählt: die explizit installierten Pakete.
Warum apt-mark die bessere Wahl ist
Wenn du wirklich wissen willst, was auf deiner Kiste läuft, solltest du apt-mark showmanual verwenden. Das zeigt dir nur die Pakete, die ein Mensch (oder ein Skript) bewusst angefordert hat. Alles andere regelt das Paketmanagement von selbst. Das spart dir beim Neuaufbau des Systems massiv Zeit, weil du dich nicht mit kaskadierenden Abhängigkeitsfehlern herumschlagen musst. Ein sauberer Ansatz trennt das Grundsystem von deinen spezifischen Anpassungen. Alles andere ist digitales Messitum.
Die Illusion der identischen Hardware
Ein weiterer Punkt, an dem viele scheitern, ist die Annahme, dass die Liste der Pakete hardwareunabhängig sei. Ich habe Techniker erlebt, die eine Liste von einem physischen Dell-Server nahmen und versuchten, damit eine virtuelle Instanz bei einem Cloud-Anbieter hochzuziehen. Das Problem: Die Liste enthielt spezifische Treiberpakete, Firmware und Tools für RAID-Controller, die in der VM nichts zu suchen hatten. Das System startete zwar, aber im Hintergrund liefen Dienste Amok, die ständig nach Hardware suchten, die physisch gar nicht existierte.
Diese Geister-Dienste fressen Ressourcen und machen die Fehlersuche in Logfiles zur Qual, weil alles mit Timeouts und Warnungen überflutet wird. In meiner Praxis hat sich bewährt, solche hardwarenahen Pakete vor dem Export konsequent auszusortieren. Wer das ignoriert, zahlt später mit einer instabilen Umgebung. Ein stabiler Server braucht Minimalismus, keine Kopie von jedem Treiber, den Debian jemals gesehen hat. Du musst lernen, zwischen Applikationsschicht und Infrastrukturschicht zu unterscheiden.
Das vergessene Problem der Drittanbieter-Quellen
Du schaust in deine Debian List Of Installed Packages und siehst dort Pakete wie google-cloud-sdk oder docker-ce. Du denkst, ein einfaches apt install auf dem neuen Server wird das schon richten. Falsch gedacht. Die Standard-Paketquellen von Debian kennen diese Programme nicht. Wenn du die sources.list und die dazugehörigen GPG-Schlüssel nicht vorher sicherst und auf das neue System überträgst, wird deine Installation krachend scheitern.
Ich habe Projekte gesehen, bei denen ganze Deployment-Pipelines stillstanden, weil jemand vergessen hatte, dass die Software aus einem privaten Repository kam. Der Zeitverlust war enorm, weil erst mühsam recherchiert werden musste, woher die Pakete ursprünglich stammten. Die Liste der installierten Pakete ist nur die halbe Wahrheit. Ohne die Information, woher diese Pakete kommen, ist sie fast wertlos. Du musst die Konfiguration unter /etc/apt/sources.list.d/ als festen Bestandteil deiner Strategie begreifen. Wer nur die Namen der Pakete speichert, hat am Ende nur eine Einkaufsliste ohne den passenden Supermarkt dazu.
Konfigurationsdateien sind nicht Teil des Pakets
Hier liegt der Hund begraben: Viele glauben, dass mit der Installation der Pakete auch die Arbeit getan ist. Ein fataler Irrtum. Die Paketverwaltung in Debian kümmert sich um die Binärdateien, nicht um deine individuellen Anpassungen in /etc. Wenn du eine Liste von 500 Paketen installierst, hast du 500 Standard-Konfigurationen. Dein Webserver wird keine Anfragen beantworten, deine Datenbank wird keine Verbindung erlauben und deine Firewall wird alles blockieren.
In einem realen Szenario bedeutete das für ein Unternehmen, dass zwar alle Pakete innerhalb von 20 Minuten installiert waren, die manuelle Wiederherstellung der Konfigurationen jedoch drei Tage dauerte, weil kein Backup der /etc-Ordner vorhanden war. Die Kosten für den Ausfall der Webseite während dieser Zeit lagen im fünfstelligen Bereich. Eine Paketliste ersetzt niemals ein echtes Konfigurationsmanagement. Du musst Tools wie Ansible oder zumindest ein gut gepflegtes Git-Repository für deine Konfigurationsdateien nutzen. Die Liste der Pakete ist lediglich das Skelett, die Konfiguration ist das Fleisch und die Muskeln. Ohne sie bewegt sich gar nichts.
Vorher-Nachher Vergleich: Eine Server-Wiederherstellung
Betrachten wir ein typisches Beispiel aus der Praxis, um den Unterschied zwischen einem amateurhaften und einem professionellen Vorgehen zu verdeutlichen.
Der falsche Weg (Vorher):
Ein Administrator führt dpkg --get-selections > pakete.txt aus. Er kopiert diese Datei auf einen neuen Server und versucht, mit dselect update und dpkg --set-selections < pakete.txt alles zu installieren. Das System meldet sofort hunderte Konflikte, weil Pakete aus Debian-Backports fehlen, die auf dem alten System vorhanden waren. Er verbringt Stunden damit, jedes fehlende Repository manuell nachzutragen. Am Ende sind zwar alle Pakete drauf, aber der Server verhält sich völlig anders, weil die Versionen der Bibliotheken nicht zusammenpassen. Er muss händisch in den Konfigurationsdateien nach Fehlern suchen, die durch Versionssprünge entstanden sind. Die Downtime beträgt 14 Stunden.
Der richtige Weg (Nachher):
Der Administrator nutzt apt-mark showmanual für eine saubere Liste. Er sichert zusätzlich den kompletten Ordner /etc/apt/ inklusive aller Trusted-Keys. Bevor er die Pakete auf dem Zielsystem installiert, vergleicht er die Debian-Versionen. Er spielt zuerst die Repositories ein, aktualisiert den Paket-Cache und lässt dann ein Skript laufen, das die Pakete installiert. Da er auch ein Backup der /etc/ mit rsync gezogen hat, spielt er die Konfigurationen gezielt zurück. Er prüft mit diff, ob sich Standard-Konfigurationen zwischen den Debian-Versionen geändert haben. Der Server ist nach 90 Minuten voll einsatzbereit. Alle Dienste laufen exakt so wie vorher. Der Unterschied ist nicht die Software, sondern die Vorbereitung und das Verständnis für die Zusammenhänge.
Der Mythos der Vollständigkeit bei Meta-Paketen
Ein häufig unterschätztes Problem sind Meta-Pakete wie build-essential oder gnome. In deiner Liste taucht vielleicht nur der Name des Meta-Pakets auf. Wenn sich aber zwischen zwei Debian-Releases die Definition dieses Meta-Pakets ändert, fehlen dir plötzlich wichtige Werkzeuge, auf die sich deine Skripte verlassen. Ich habe das oft bei Entwicklungs-Servern erlebt. Ein Update des Meta-Pakets führte dazu, dass ein bestimmter Compiler nicht mehr automatisch mitinstalliert wurde. Plötzlich funktionierten die Build-Prozesse nicht mehr, und die Entwickler saßen untätig herum.
Du darfst dich nie blind darauf verlassen, dass ein Paketname in Zukunft genau das gleiche beinhaltet wie heute. In der Welt von Debian ist Stabilität zwar das oberste Gebot, aber die Zusammensetzung von Softwaregruppen ändert sich. Wenn du geschäftskritische Software betreibst, musst du die spezifischen Abhängigkeiten kennen, anstatt dich auf bequeme Sammelpakete zu stützen. Es ist mühsamer, die einzelnen Komponenten zu dokumentieren, aber es bewahrt dich vor bösen Überraschungen, wenn das Betriebssystem ein Major-Upgrade erfährt.
Realitätscheck: Was du wirklich brauchst
Machen wir uns nichts vor: Eine Liste installierter Pakete ist ein nützliches Werkzeug, aber kein Allheilmittel. Wer denkt, damit eine Disaster-Recovery-Strategie zu haben, belügt sich selbst. In der echten Welt der IT-Infrastruktur reicht es nicht, Befehle abzutippen, die man in einem Blogpost gelesen hat.
Erfolg mit Debian-Systemen erfordert Disziplin. Du musst deine Infrastruktur als Code betrachten. Das bedeutet:
- Dokumentiere jedes Repository, das nicht zum Standard-Umfang gehört.
- Trenne deine Daten von der Systempartition.
- Nutze Versionierung für deine Konfigurationsdateien.
- Teste deine Wiederherstellung regelmäßig auf einer Test-Instanz.
Wenn du glaubst, dass du im Ernstfall mit einer Textdatei und einem apt install alles retten kannst, wirst du scheitern. Es braucht Erfahrung, um zu wissen, welche Pakete man ignorieren kann und welche lebenswichtig sind. Ein guter Administrator zeichnet sich nicht dadurch aus, dass er die längste Liste hat, sondern die kürzeste – weil er weiß, wie er sein System schlank und wartbar hält. Der Weg zum stabilen Server führt über tiefes Verständnis der Paketmechanik, nicht über oberflächliche Automatisierung. Es ist harte Arbeit, es ist oft langweilig, aber es ist der einzige Weg, um nachts ruhig schlafen zu können, während die Server draußen im Rechenzentrum ihren Dienst tun. Wer die Abkürzung nimmt, landet meistens in einer Sackgasse, die viel Zeit und noch mehr Geld kostet. Sei nicht dieser Admin. Sei derjenige, der den Prozess beherrscht, anstatt von ihm beherrscht zu werden.
