Debian 13 Upgrade: Sicher von Bookworm zu Trixie wechseln

Ein Debian-13-Upgrade auf einem produktiven Server ist kein einzelner APT-Befehl, sondern eine Release-Migration mit Vorprüfung, dokumentierter Repository-Umstellung, Wartungsfenster, Validierung und Rückfallplan. Debian unterstützt Upgrades von Debian 12 Bookworm auf Debian 13 Trixie für viele Standardinstallationen über APT. Ob der Neustart nach dem Bookworm-to-Trixie-Upgrade sauber endet, hängt aber von Paket-Holds, Drittanbieter-Repositories, i386-Abhängigkeiten, freiem Platz in /boot und der Bootloader-Konfiguration ab.

Dieses Runbook ist als Debian-13-Upgrade-Checkliste für Server, VMs und Workstations aufgebaut. Du findest konkrete APT-Kommandos, Beispiele für eine Debian 13 sources.list, Prüfungen für Debian Trixie i386, typische Fehlerbilder und klare Kriterien für einen Rollback über Snapshots oder Backups.

Wann lohnt sich das Debian-13-Upgrade?

Debian 13 Trixie ist seit dem 9. August 2025 die stabile Debian-Version. Stand Juni 2026 ist Debian 13.5 der aktuelle Point-Release; prüfe vor Deinem Wartungsfenster trotzdem die aktuellen Debian-Release-Notes und Security Advisories. Ein Point-Release ist ein guter Upgrade-Zeitpunkt, weil frühe Korrekturen bereits in den stabilen Paketstand eingeflossen sind.

Beginne nicht mit dem wichtigsten Produktivsystem. Geeignete erste Kandidaten sind Testumgebungen, CI-Runner, interne VMs und Workstations, auf denen Du Deine Anwendungen gegen Trixie-Pakete prüfst. Danach folgen weniger kritische Server mit dokumentiertem Wiederherstellungsweg. Produktive Datenbank-Server, Firewalls, Storage-Systeme und zentrale Authentifizierungsdienste gehören ans Ende der Reihenfolge.

Debian 13 erhält insgesamt fünf Jahre Unterstützung: regulären Support bis zum 9. August 2028 und Long-Term-Support bis zum 30. Juni 2030. Die Debian-Release-Notes nennen mehr als 14.100 neue Pakete, rund 69.830 Pakete insgesamt, mehr als 44.000 aktualisierte Pakete und mehr als 8.800 entfernte veraltete Pakete. Diese Paketbewegung ist für Server relevant, wenn Anwendungen alte Bibliotheken, Python-Module, PHP-Erweiterungen oder verwaiste Admin-Tools verwenden.

Besondere Vorsicht gilt bei Legacy-Hardware, 32-Bit-Abhängigkeiten, geschäftskritischen Workloads und Drittanbieter-Repositories ohne Trixie-Unterstützung. i386 ist in Debian 13 keine reguläre Release-Architektur mehr, sondern nur noch als Co-Architektur für 32-Bit-Software auf amd64 vorgesehen. armel wird laut Debian-Hinweisen nur noch für Upgrades unterstützt, nicht für Neuinstallationen.

Preflight-Check vor der Repository-Umstellung

Schließe den Preflight-Check ab, bevor Du Bookworm-Repositories änderst. So trennst Du Paketprobleme im alten System von Konflikten, die erst durch Trixie entstehen. Wenn Du die Grundlagen zu APT, dpkg, systemd und Update-Prozessen vertiefen willst, passt die Schulung Debian Linux - Administration als fachlicher Hintergrund.

apt update
apt full-upgrade

dpkg --audit
apt-mark showhold

lsb_release -a 2>/dev/null || cat /etc/os-release
dpkg --print-architecture
dpkg --print-foreign-architectures

df -h / /boot 2>/dev/null || df -h /
find /etc/apt/sources.list.d -maxdepth 1 -type f -print
grep -R -n -E 'bookworm|bullseye|testing|unstable' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null || true

Prüfung	Aktion vor dem Upgrade
Release	Nur Debian 12 Bookworm als Ausgangspunkt verwenden und vorher vollständig aktualisieren.
Architektur	amd64 bevorzugen. Ein primäres i386-System nicht als normale produktive Trixie-Migration planen.
dpkg-Audit	Halb konfigurierte oder beschädigte Pakete vor dem Release-Wechsel reparieren.
Held Packages	Holds dokumentieren und nur entfernen, wenn Du die Auswirkung auf die Anwendung geprüft hast.
Drittanbieter-Repositories	Jedes Repository deaktivieren, ersetzen oder explizit auf signierte Trixie-Pakete umstellen.
Speicherplatz	Besonders /boot, Root-Dateisystem und Paket-Cache prüfen.

Sichere zusätzlich Paketlisten und manuell installierte Pakete. Diese Dateien ersetzen kein Backup, beschleunigen aber die Analyse, wenn APT Pakete entfernt oder eine Anwendung nach dem Upgrade fehlt.

mkdir -p /root/pre-trixie
apt-mark showmanual > /root/pre-trixie/apt-manual.txt
apt-mark showhold > /root/pre-trixie/apt-hold.txt
dpkg --get-selections > /root/pre-trixie/dpkg-selections.txt
dpkg-query -W -f='${binary:Package} ${Version} ${Architecture}\n' > /root/pre-trixie/dpkg-versions.txt

Debian 13 sources.list sauber auf Trixie umstellen

Eine einfache Debian 13 sources.list für Systeme ohne zusätzliche Komponenten sieht so aus. Ergänze contrib und non-free nur, wenn installierte Pakete diese Bereiche benötigen.

deb http://deb.debian.org/debian trixie main non-free-firmware
deb http://security.debian.org/debian-security trixie-security main non-free-firmware
deb http://deb.debian.org/debian trixie-updates main non-free-firmware

# optional erst nach erfolgreichem Basis-Upgrade aktivieren
# deb http://deb.debian.org/debian trixie-backports main non-free-firmware

Wenn Dein System Deb822-Dateien wie /etc/apt/sources.list.d/debian.sources nutzt, ändere nicht parallel zusätzlich eine klassische sources.list. Ein mögliches Deb822-Beispiel:

Types: deb
URIs: http://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: http://security.debian.org/debian-security
Suites: trixie-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Das Haupt-Repository liefert die Paketbasis. Das Security-Repository liefert Sicherheitsupdates. trixie-updates enthält stabile Korrekturen zwischen Point-Releases. Backports gehören nicht in die erste Migrationsphase, weil sie neuere Paketstände in die Abhängigkeitsauflösung einbringen.

Ersetze nicht blind jedes Vorkommen von bookworm durch trixie. Ein pauschaler sed-Befehl verändert auch Drittanbieter-Repositories, die eventuell keine signierten Trixie-Pakete anbieten. Dokumentiere jede geänderte Repository-Datei mit altem Eintrag, neuem Eintrag, Paket-Herkunft und Ansprechpartner. Diese Dokumentation hilft später bei apt policy paketname.

Upgrade in zwei kontrollierten APT-Phasen ausführen

Starte Remote-Upgrades in tmux oder screen. Eine verlorene SSH-Verbindung darf den dpkg-Prozess nicht abbrechen. Für kritische Server brauchst Du zusätzlich Out-of-Band-Zugriff, eine Recovery-Konsole oder Zugriff auf die Virtualisierungskonsole.

tmux new -s trixie-upgrade
script -a /root/pre-trixie/upgrade.log

apt update
apt -s upgrade --without-new-pkgs
apt upgrade --without-new-pkgs

apt -s full-upgrade
apt full-upgrade

Nach apt update darfst Du keine Signaturfehler, fehlenden Release-Dateien oder 404-Fehler ignorieren. Prüfe die Simulationen: Wenn APT zentrale Pakete entfernen will, unterbrich das Upgrade und kläre die Ursache. Die minimale Phase mit apt upgrade --without-new-pkgs aktualisiert Pakete ohne neue Abhängigkeiten. Die eigentliche Release-Migration läuft mit apt full-upgrade, weil APT dabei Pakete installiert, ersetzt oder entfernt, wenn Abhängigkeiten das verlangen.

Bei Konfigurationsabfragen unter /etc vergleichst Du die Maintainer-Version mit Deiner lokalen Datei. Behalte lokale Änderungen bei manuell angepassten Dateien wie sshd_config, nginx.conf oder postgresql.conf, wenn die Anpassungen weiterhin benötigt werden. Installiere Maintainer-Versionen nur, wenn Deine Änderungen dokumentiert, migriert oder nicht mehr erforderlich sind.

Typische Pitfalls beim Debian-13-Upgrade

Entfernte Pakete und ABI-Änderungen

Debian 13 entfernt laut Release-Notes mehr als 8.800 veraltete Pakete. Prüfe vor dem Neustart, ob APT zentrale Pakete entfernt hat, die Deine Anwendung noch lädt. Besonders wichtig sind Bibliotheken, Sprachruntime-Pakete, Monitoring-Agenten, Datenbank-Extensions und Pakete aus Drittanbieter-Repositories.

apt -s full-upgrade | grep -E '^(Remv|Inst|Conf)' || true
grep -E '^(Remove|Purge):' /var/log/apt/history.log || true

Die Trixie-Release-Notes nennen außerdem die 64-Bit-time_t-ABI-Umstellung, die vor allem 32-Bit-Userlands und Multiarch-Pakete betrifft, sowie wcurl, HTTP/3-Unterstützung in curl, HTTP-Boot-Unterstützung, offizielle riscv64-Unterstützung und arm64-Härtung gegen ROP- sowie COP/JOP-Angriffe. Relevante Punkte solltest Du in Dein eigenes Testprotokoll übernehmen, statt sie nur als Release-Neuheiten zu lesen.

Debian Trixie i386 prüfen

Der Punkt Debian Trixie i386 ist besonders wichtig für Multiarch-Systeme. Wenn dpkg --print-architecture i386 ausgibt, plane keine normale produktive Trixie-Migration. In der Praxis ist dann meist ein Neuaufbau auf amd64 oder eine gesondert getestete Crossgrade-Strategie nötig. Wenn i386 nur als Foreign Architecture auf amd64 auftaucht, inventarisiere die 32-Bit-Pakete und ihre Abhängigkeiten.

dpkg --print-architecture
dpkg --print-foreign-architectures
dpkg-query -W -f='${binary:Package} ${Version} ${Architecture}\n' | grep ' i386$' || true
apt-cache rdepends --installed libc6:i386 2>/dev/null || true

Entferne i386 nicht vorschnell. Wine, Steam, einzelne Hersteller-Agenten oder alte 32-Bit-Tools können davon abhängen. Wenn keine 32-Bit-Pakete mehr installiert sind, entfernst Du die Foreign Architecture erst nach dem Upgrade und nach bestandenen Anwendungstests.

Bootloader, initramfs und Kernel

Kontrolliere nach dem Full-Upgrade die Kernel-Installation, den verfügbaren Platz in /boot und die Bootloader-Aktualisierung. Bei Systemen mit angepassten Kernel-Parametern, initramfs-Hooks, verschlüsselten Dateisystemen oder speziellen Storage-Treibern gehört die Prüfung der Boot-Kette in das Wartungsfenster. Für tiefere Arbeit an Kernel-Parametern, initramfs, Boot-Parametern und Linux-System-Tuning passt die Schulung Linux Systemanpassungen Deep Dive - Performante, stabile Systeme gestalten.

df -h /boot /boot/efi 2>/dev/null || df -h /boot
dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'
ls -lh /boot
update-initramfs -u -k all
if command -v update-grub >/dev/null; then update-grub; fi
bootctl status 2>/dev/null || true
efibootmgr -v 2>/dev/null || true

Nach Library-Updates müssen betroffene Dienste neu starten. Prüfe systemd-Units und Boot-Logs statt nur den Exit-Code von APT. Wenn needrestart installiert ist, nutze es als zusätzliche Kontrolle, aber verlasse Dich nicht allein darauf.

Post-Upgrade-Validierung und Cleanup

Reboote nach der Paketmigration kontrolliert und validiere den laufenden Trixie-Kernel. Prüfe danach Dienste, Boot-Logs, APT-Quellen und Anwendungstests.

uname -a
cat /etc/os-release
systemctl --failed --no-pager
journalctl -p warning -b --no-pager

apt update
apt list --upgradable
grep -R -n 'bookworm' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null || true
apt autoremove --purge --simulate

Entferne obsolete und verwaiste Pakete erst nach Smoke-Tests. Beispiele für prüfbare Anwendungstests sind curl -fsS http://127.0.0.1/health für Web-Services, psql -c 'select 1' für PostgreSQL, mysqladmin ping für MariaDB oder MySQL und ein Login-Test gegen LDAP, Kerberos oder PAM, wenn der Server Authentifizierung bereitstellt.

Dokumentiere geänderte Konfigurationsdateien, neu gestartete Dienste, entfernte Pakete, manuelle Nacharbeiten und offene Risiken. Monitoring-Systeme müssen nach dem Upgrade wieder grüne Checks für CPU, RAM, Disk, systemd-Units, Zertifikatslaufzeiten, HTTP-Statuscodes, Datenbank-Replikation und Backup-Jobs liefern. Für Betriebsprüfungen findest Du ergänzend passende Monitoring- und Logging-Schulungen.

Rollback-Plan: Snapshots statt APT-Downgrade

Ein belastbarer Rollback-Plan existiert vor dem ersten apt full-upgrade. APT-Downgrades von Trixie zurück nach Bookworm sind für produktive Systeme keine verlässliche Rückfallstrategie, weil Maintainer-Skripte, Datenbank-Migrationen, geänderte Konfigurationsdateien, entfernte Pakete und ABI-Änderungen nicht automatisch in den Bookworm-Zustand zurückkehren.

VMs: Erstelle einen konsistenten Snapshot nach Dienststopp oder mit quiesced Filesystem, wenn die Virtualisierungsplattform das unterstützt.
Dateisysteme: Nutze Btrfs-, ZFS- oder LVM-Snapshots und teste vorher den Boot aus dem Snapshot-Ziel.
Bare Metal: Lege ein vollständiges Backup mit Systempartitionen, EFI-Partition, Bootloader, Datenverzeichnissen und Restore-Medium an.
Datenbanken: Erstelle zusätzlich logische Dumps oder replizierte Standby-Systeme, weil Dateisystem-Snapshots ohne Konsistenzpunkt Transaktionen verlieren können.

Definiere Rollback-Kriterien schriftlich: fehlender Boot, fehlender Netzwerkzugriff nach Reboot, inkompatible Anwendung, gebrochene Drittanbieter-Pakete, fehlgeschlagene Datenbank-Prüfung oder rote Monitoring-Checks nach Ablauf des Wartungsfensters. Wenn eines dieser Kriterien eintritt, stellst Du Snapshot oder Backup wieder her, statt Paketstände manuell zurückzumischen.

Der nächste konkrete Schritt ist eine Bestandsaufnahme: Führe den Preflight-Check auf einem Bookworm-Testsystem aus, erstelle die Repository-Dokumentation, teste das Upgrade mit denselben Drittanbieter-Repositories und schreibe die gemessenen Validierungsschritte in Dein eigenes Betriebs-Runbook.