So aktualisieren Sie einen Produktionsserver von Debian 12 auf Debian 13

Die Antwort vorab: ja, es ist Zeit

Zwei Fakten entscheiden über den Zeitpunkt. Erstens: Debian 12 "bookworm" verlor am 10. Juni 2026 den regulären Security-Support; es wird jetzt vom LTS-Team gepflegt (bis Juni 2028), das die meisten Pakete abdeckt, aber eine schmalere Garantie bietet als die volle Unterstützung des Security-Teams. Zweitens: Debian 13 "trixie" ist fast ein Jahr alt und steckt fünf Point-Releases tief (13.5 zum Zeitpunkt der Erstellung). Die Early-Adopter-Phase ist längst vorbei.

Das Upgrade selbst ist klassisches Debian: unglamourös und zuverlässig. Die Kurzfassung:

1. Bringen Sie bookworm vollständig auf den neuesten Stand, und räumen Sie zurückgehaltene Pakete sowie Drittanbieter-Repositories auf.
2. Richten Sie die APT-Quellen auf trixie aus.
3. apt update → apt upgrade --without-new-pkgs → apt full-upgrade → Reboot.

Auf einem Produktionsserver steckt die Arbeit in der Vorbereitung, nicht in den Befehlen, besonders bei einer Maschine, die Sie nur über SSH erreichen. Befehle und Adressen in diesem Leitfaden sind illustrativ; setzen Sie Ihre eigenen Werte ein, und lesen Sie parallel dazu die offiziellen Versionshinweise; sie bleiben die maßgebliche Quelle, und dieser Leitfaden folgt ihrem Verfahren.

Was Sie bekommen: Debian 13 in einer Tabelle

Die verbleibende Support-Laufzeit ist die andere Hälfte des Bildes: trixie erhält vollen Security-Support bis etwa August 2028 und LTS bis Juni 2030, vier Jahre mehr Patches als die Maschine, die Sie gerade aktualisieren.

Checkliste vor dem Upgrade

Erledigen Sie das alles, bevor Sie die Quellen anfassen. Eine halbe Stunde hier ist es, was das Upgrade langweilig macht.

1. Aktuellen Stand herstellen und Paketstatus prüfen

Upgrades, die Releases überspringen, werden nicht unterstützt; Sie müssen zuerst auf dem neuesten bookworm-Point-Release sein:

apt update && apt full-upgrade    # finish updating Debian 12
dpkg --audit                      # must be silent (no broken packages)
apt-mark showhold                 # holds will sabotage the upgrade — clear them

Entfernen Sie anschließend, was nicht dazugehört: Drittanbieter-Repositories (deaktivieren Sie sie; fügen Sie trixie-kompatible Versionen später wieder hinzu), alles aus bookworm-backports (kein Upgrade-Pfad) sowie Pakete, die Sie nicht mehr nutzen; jedes Paket, das Sie jetzt entfernen, kann später nicht mehr in Konflikt geraten.

2. Sichern, was eine Wiederherstellung möglich macht

Ein echtes Backup Ihrer Daten, plus die günstigen Kopien des Systemzustands, die die Versionshinweise verlangen:

tar czf /root/pre-upgrade-etc.tar.gz /etc
cp -a /var/lib/dpkg /root/pre-upgrade-dpkg
dpkg --get-selections '*' > /root/pre-upgrade-selections.txt

Seien Sie ehrlich zu sich selbst, was den Rollback angeht: es gibt keinen unterstützten Downgrade-Pfad. Geht das Upgrade unwiederbringlich schief, führt der Weg zurück über Ihr Backup (oder Neuprovisionierung und Wiederherstellung, was auf einem Host mit schneller Provisionierung oft schneller geht). Entscheiden Sie jetzt, wie Ihr Wiederherstellungsplan aussieht, nicht um 2 Uhr nachts mitten in einem Vorfall.

3. Besonderheiten bei Remote-Servern: der Teil, der Sie rettet

Diese drei Punkte sind es, die „einen Server im Rack aktualisieren“ von „einen Laptop aktualisieren“ unterscheiden, und der erste ist die tückischste Falle in diesem Zyklus:

• Pinnen Sie Ihre Netzwerk-Interface-Namen fest. Die Versionshinweise zu trixie warnen, dass manche NICs (insbesondere beim i40e-Treiber, sowie manche ACPI-Systeme) unter dem neuen Kernel den Interface-Namen ändern. Wenn Ihre /etc/network/interfaces eno1 sagt und der neue Kernel es enp5s0 nennt, startet die Maschine ohne Netzwerk. Bei einer Remote-Maschine ist das ein toter Server. Pinnen Sie den Namen vor dem Upgrade mit einer systemd-.link-Datei an die MAC-Adresse:

# /etc/systemd/network/10-persistent-eth0.link
[Match]
MACAddress=aa:bb:cc:dd:ee:ff

[Link]
Name=eth0

(Verwenden Sie die MAC-Adresse Ihrer NIC aus ip link; verweisen Sie dann in Ihrer Netzwerkkonfiguration auf diesen fest gepinnten Namen.)

• Führen Sie das Upgrade innerhalb von tmux oder screen aus. Bricht Ihre SSH-Verbindung mitten in full-upgrade ab, hält eine losgelöste Sitzung das Upgrade am Leben, statt dpkg halb fertig zurückzulassen.
• Bestätigen Sie, dass der Out-of-Band-Konsolenzugriff funktioniert: IPMI/KVM-over-IP. Testen Sie den Login, bevor Sie ihn brauchen. Das macht aus jedem Worst-Case-Szenario in diesem Artikel eine Zehn-Minuten-Reparatur statt einer Neuprovisionierung.

4. Prüfen Sie die Stolperfallen, die auf Sie zutreffen

Aus der Liste der bekannten Probleme diejenigen, die Servern gefährlich werden:

• OpenSSH 10 entfernt DSA-Schlüssel vollständig. Ist ein Authorized Key oder Host-Key noch DSA (das müsste schon uralt sein), ersetzen Sie ihn vor dem Upgrade durch Ed25519, sonst sind Sie beim ersten SSH-Versuch nach dem Upgrade ausgesperrt.
• Datenbanken und Mail: Fahren Sie MariaDB sauber herunter, bevor Sie aktualisieren (die versionsübergreifende Crash-Recovery schlägt fehl); das Konfigurationsformat von Dovecot hat sich inkompatibel geändert; RabbitMQ hat keinen direkten Upgrade-Pfad. Nutzen Sie eines davon, lesen Sie zuerst die jeweiligen Abschnitte und planen Sie die Migration auf Service-Ebene.
• Verschlüsseltes Root? Stellen Sie sicher, dass systemd-cryptsetup vor dem Neustart installiert ist.
• Speicherplatz: apt sagt Ihnen, was full-upgrade auf / benötigt; prüfen Sie außerdem, ob /boot ~300 MB frei hat. Zu klein dimensionierte Boot-Partitionen aus alten Provisioning-Vorlagen sind ein klassischer Upgrade-Stopper.

Das Upgrade

Schritt 1: APT auf trixie ausrichten

Bookworm-Systeme verwenden in der Regel noch das klassische Einzeiler-Format. Bearbeiten Sie /etc/apt/sources.list (und alles in /etc/apt/sources.list.d/) und ersetzen Sie bookworm durch trixie. Achten Sie auf die Benennung der Security-Suite:

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

(APT 3.0 bevorzugt das neue deb822-Format, aber die Umstellung ist sauberer nach dem Upgrade: eine Änderung nach der anderen. apt modernize-sources erledigt das dann für Sie.)

Schritt 2: die drei Befehle

Innerhalb Ihrer tmux-Sitzung:

apt update
apt upgrade --without-new-pkgs    # minimal upgrade first — safer ordering
apt full-upgrade                  # the real event

Die zweiphasige Struktur ist bewusst gewählt und stammt direkt aus den Versionshinweisen: Der minimale Durchlauf aktualisiert, was er kann, ohne etwas Neues zu installieren oder zu entfernen (Pakete, die in dieser Phase „zurückgehalten“ werden, sind normal), was das Ausmaß gleichzeitiger Änderungen reduziert, wenn full-upgrade anschließend Kernel, ABI-Übergänge und Entfernungen übernimmt. Rechnen Sie mit ein paar Conffile-Abfragen: Die sichere Standardantwort ist, Ihre eigene Version zu behalten (N) und die Unterschiede danach zu prüfen; full-upgrade schlägt außerdem vor, veraltete Pakete zu entfernen, und es lohnt sich, diese Liste vor dem Bestätigen wirklich zu lesen.

Auf einem typischen Server lädt das ein paar Gigabyte herunter und dauert je nach Paketanzahl und Festplattengeschwindigkeit irgendwo zwischen fünfzehn Minuten und einer Stunde.

Schritt 3: Neustart und Überprüfung

systemctl reboot

Bestätigen Sie dann sofort die Grundlagen, sobald der Server wieder da ist:

cat /etc/debian_version   # expect 13.x
uname -r                  # expect a 6.12 kernel
systemctl --failed        # what didn't come up?
ss -tlnp                  # are your services listening?

Kommt er nicht zurück: Das ist der Moment für die KVM-Konsole. Die zwei wahrscheinlichsten Übeltäter bei einer Remote-Maschine sind die Interface-Umbenennung (behoben durch das .link-Pinning von oben, oder an der Konsole behebbar) und Bootloader-/Initramfs-Probleme, beide out-of-band diagnostizierbar.

Schritt 4: Aufräumen nach dem Upgrade

apt autoremove --purge     # dependencies nothing needs anymore
apt purge '?obsolete'      # packages no longer in any repo
apt modernize-sources      # optional: convert sources to deb822, now that things are stable

Trixie-Änderungen, die Sie nach dem Upgrade prüfen sollten

Drei Verhaltensänderungen überraschen Leute, die aktualisiert statt neu installiert haben:

• /tmp ist jetzt ein RAM-gestütztes tmpfs (bis zu 50 % des RAM), aktiviert beim ersten Neustart nach dem Upgrade, mit automatischer Bereinigung: Dateien, die 10 Tage lang in /tmp (30 in /var/tmp) nicht benutzt wurden, werden gelöscht. Schreibt eine Anwendung große temporäre Dateien, verweisen Sie sie anderswohin oder kehren Sie zu einem festplattengestützten /tmp zurück (systemctl mask tmp.mount und Neustart). Beachten Sie, dass aktualisierte Systeme einen Kompatibilitäts-Snippet für tmpfiles.d erhalten, der das alte Bereinigungsverhalten beibehält; prüfen Sie /etc/tmpfiles.d/tmp.conf, um zu sehen, in welchem Regime Sie sich befinden.
• /etc/sysctl.conf wird nicht mehr gelesen. Kernel-Tuning, das Sie dort abgelegt hatten, greift stillschweigend nicht mehr; verlagern Sie es in Dateien unter /etc/sysctl.d/*.conf (die Firewall-/Tuning-Einstellungen aus unserer Hardening-Checkliste liegen ohnehin schon dort).
• Kleinere Tools entfernt: last/lastlog sind weg (nutzen Sie lslogins, wtmpdb); isc-dhcp-client gilt als veraltet. Einfaches ping funktioniert jetzt ohne Root-Rechte. Skripte, die von den alten Tools ausgingen, brauchen eine kleine Anpassung.

Die Servernetzwerkkonfiguration ist unverändertes Terrain: trixie-Serverinstallationen verwenden standardmäßig weiterhin ifupdown (/etc/network/interfaces), sodass Ihre bestehende Konfiguration direkt übernommen wird, das Umbenennungsrisiko einmal beiseitegelassen.

Häufig gestellte Fragen

Wie lange dauert der gesamte Vorgang?

Planen Sie ein Wartungsfenster von ein bis zwei Stunden für einen unkomplizierten Server ein: Der Download und die Installation der Pakete dauern meist unter einer Stunde, dazu ein Neustart plus Ihre Überprüfungszeit. Die Vorbereitung (Backups, Audits, Pinning) kostet davor noch eine halbe Stunde, muss aber nicht innerhalb des Fensters liegen. Was das Budget sprengt, ist übersprungene Vorbereitung. Ein zurückgehaltenes Paket oder ein volles /boot, das Sie erst mitten im Upgrade entdecken, macht aus einem Routinejob einen Nachmittag.

Kann ich direkt von Debian 11 auf 13 upgraden?

Nein. Upgrades, die Releases überspringen, werden ausdrücklich nicht unterstützt. Der Weg ist 11 → 12 → 13, wobei Sie jeden Sprung (einschließlich Neustart) abschließen, bevor Sie den nächsten beginnen. Liegen Sie auf einer Maschine zwei Releases zurück, wägen Sie ehrlich zwischen einer Neuprovisionierung auf Debian 13 mit Wiederherstellung der Daten und zwei aufeinanderfolgenden In-Place-Upgrades ab; auf einem Host mit schneller Provisionierung gewinnt die Neuinstallation oft sowohl bei der Zeit als auch beim Vertrauen.

Ist es sicher, das über SSH zu machen?

Ja, mit den drei Vorsichtsmaßnahmen aus der Checkliste: Arbeiten Sie innerhalb von tmux/screen (damit eine abgebrochene Verbindung dpkg nicht killt), pinnen Sie Interface-Namen vor dem Upgrade fest (damit der neue Kernel Ihre NIC nicht unter der Netzwerkkonfiguration wegbenennen kann), und lassen Sie den Out-of-Band-Konsolenzugriff vorab verifizieren. Tausende Remote-Debian-Server werden auf diese Weise in jedem Release-Zyklus aktualisiert; die Horrorgeschichten sind fast immer auf eine dieser drei ausgelassenen Vorsichtsmaßnahmen zurückzuführen.

Sollte ich meine APT-Quellen auf das neue deb822-Format umstellen?

Irgendwann schon, ja. Es ist der Standard für Neuinstallationen, die Tools von APT 3.0 gehen davon aus, und das Einzeiler-Format gilt als veraltet (auch wenn es noch jahrelang unterstützt wird). Tun Sie es aber nach dem Release-Upgrade, mit apt modernize-sources, nicht währenddessen: Eine Konfigurationsformat-Migration in dasselbe Änderungsfenster wie ein Distributions-Upgrade zu packen, macht jeden Ausfall nur schwerer zuzuordnen.

Debian 14 kommt bald; sollte ich darauf warten?

Nein. „Forky“ wird irgendwann 2027 erwartet, ohne angekündigte Termine, und darauf zu warten bedeutet, bookworm noch mehr als ein Jahr auf schrumpfendem LTS-Support laufen zu lassen. Aktualisieren Sie jetzt auf trixie, genießen Sie vollen Security-Support, und wenn forky ein oder zwei Point-Releases an Reife hat, können Sie denselben Sprung erneut machen. Dieser Rhythmus (ungefähr ein Jahr nach jedem Release aktualisieren) ist das angenehme Tempo für Debian im Produktivbetrieb.

Bereitstellung auf Serverside

Zwei Dinge auf unserer Plattform nehmen diesem Verfahren die Angst: KVM-over-IP-Konsolenzugriff auf jedem Debian Dedicated Server (sodass eine Interface-Umbenennung oder ein Boot-Problem zu einer Konsolensitzung statt einem Support-Ticket wird) und Provisionierung in unter einer Minute auf ASN 55285, was Neuprovisionierung und Wiederherstellung zu einem wirklich schnellen Plan B macht (und eine frische Debian-13-Installation zum einfachen Plan A für neue Maschinen).

Mehr Lesestoff zu Debian und angrenzenden Upgrade-Themen: So wählen Sie die richtige Linux-Distribution, die Hardening-Checkliste für die erste Stunde für jede frisch aktualisierte Maschine, und sinnvolle Standard-Firewall-Regeln.