KeyHelp-Server von Debian 12 auf 13 upgraden: offizielles Skript, Rückfragen und Prüfliste
Debian 12 ist aus dem regulären Support. So bringen Sie einen KeyHelp-Server mit dem offiziellen Skript auf Debian 13: beide Läufe, alle Rückfragen im Wortlaut, der BIND-Fehler und eine Prüfliste, getestet in einer VM.
Geprüft am 01.10.2026 · für KeyHelp 26.1.1
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu

Wer KeyHelp auf Debian 12 „Bookworm“ betreibt, sollte das Upgrade auf Debian 13 „Trixie“ jetzt planen: Die reguläre Sicherheitsunterstützung für Debian 12 endete laut Debian-Projekt am 11. Juli 2026, danach läuft nur noch die Langzeitunterstützung (LTS) bis zum 30. Juni 2028, und das auch nur für ausgewählte Architekturen. KeyHelp selbst meldet Debian 12 in seiner API bereits als „end_of_life“. Keyweb stellt für den Wechsel ein offizielles Upgrade-Skript bereit. Diese Anleitung richtet sich an Administratoren kleiner Hosting-Server, Agenturen und KMU, die KeyHelp nach unserer Anleitung KeyHelp installieren und absichern eingerichtet haben. Sie zeigt den Ablauf so, wie er in unserem Test tatsächlich aussah: mit allen Rückfragen im Wortlaut, den Fehlermeldungen, die harmlos sind, und einer Prüfliste für danach.
Voraussetzungen
- Vollständige Sicherung: Ein Snapshot beim Provider ist der schnellste Rückweg. Zusätzlich gehört eine externe KeyHelp-Sicherung dazu, siehe KeyHelp-Backups richtig einrichten. Keyweb weist ausdrücklich darauf hin, dass ein abgebrochenes Upgrade von Hand zurückgebaut werden muss.
- KeyHelp-Version: Debian 13 unterstützt KeyHelp laut Keyweb seit Version 25.2. Wir haben mit KeyHelp 26.1.1 (Build 3698) getestet. Das Skript führt vor dem Systemwechsel selbst noch einen KeyHelp-Update-Lauf aus.
- Root-Zugriff per SSH und zusätzlich ein Konsolenzugang beim Provider (VNC, serielle Konsole), falls SSH nach einem Neustart nicht zurückkommt.
- Zeitfenster: Planen Sie eine Stunde ein. Web, Mail und FTP sind während des Upgrades und zweier Neustarts zeitweise nicht erreichbar.
- Freier Speicher: Im Test lud das Upgrade rund 364 MB Pakete. Prüfen Sie vorher mit
df -h /, dass deutlich mehr Platz frei ist. - Alte PHP-Interpreter: Laut Keyweb stehen unter Debian 13 zusätzliche PHP-Interpreter erst ab PHP 7.4 zur Verfügung. Stellen Sie Domains mit älteren Versionen vorher um.
- Eigene Paketquellen: Das Skript überschreibt
/etc/apt/sources.list. Notieren Sie eigene Einträge vorher.
Rückfallplan
Legen Sie vor dem Start fest, ab wann Sie zurückrollen: etwa wenn der Server nach dem zweiten Lauf nicht startet oder Mail länger als das geplante Zeitfenster ausfällt. Der Rückweg ist dann der Provider-Snapshot, nicht ein Reparaturversuch unter Zeitdruck. Ein halb aktualisiertes System lässt sich nicht sauber auf Debian 12 zurückstufen. Notieren Sie deshalb vorher, wo im Kundenmenü des Providers die Snapshot-Wiederherstellung liegt.
Schritt 1: Ausgangslage festhalten
Halten Sie den Zustand vor dem Upgrade für den späteren Vergleich fest:
keyhelp version
cat /etc/debian_version
uname -r
php -v | head -1
mariadb --version
df -h /
cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/
systemctl --failed
Starten Sie neu, falls ein Kernel-Update aussteht; das Skript prüft das am Anfang. Legen Sie zum Schluss den Snapshot an.
Verifizieren: systemctl --failed meldet keine fehlerhaften Dienste, und keyhelp version zeigt im Test:
KeyHelp : 26.1.1 (Build 3698)
Operating System : Debian 12.15 (64-bit)
Schritt 2: Upgrade-Programm in screen starten
Damit eine abreißende SSH-Verbindung das Upgrade nicht abbricht, empfiehlt Keyweb screen:
apt install -y screen
screen -S upgrade
Starten Sie darin das offizielle Programm mit dem Befehl von Keyweb:
wget --no-check-certificate https://install.keyhelp.de/scripts/upgrade_operating_system.sh -O upgrade_operating_system.sh && bash upgrade_operating_system.sh
Nach einem Verbindungsabbruch holen Sie die Sitzung mit screen -r upgrade zurück. Der Startbildschirm:
This application performs an operating system upgrade on your server.
From: Debian 12 To: Debian 13
-------------------------------------------------------------------------
The upgrade guide can be found here: https://keyhelp.de/help/os-upgrades
Please make sure you read and follow the upgrade guide carefully.
-------------------------------------------------------------------------
> Pre-checking system...
... Press [ENTER] to start the upgrade | Abort with [CTRL] + [C]
Was das Skript intern tut
Die Datei upgrade_operating_system.sh ist nur ein kleiner Starter. Sie prüft Root-Rechte, ob /home/keyhelp/www/keyhelp/ existiert und ob curl vorhanden ist. Dann erkennt sie das System: Bei Debian 12 ohne Fortsetzungsmarke lädt sie keyhelp_debian_upgrade_12_to_13 herunter, speichert es als PHP-Datei, aktiviert ionCube mit phpenmod ioncube und führt es mit php aus. Dieses eigentliche Upgrade-Programm ist mit ionCube verschlüsselt, sein Inhalt ist also nicht einsehbar. Was es tut, zeigen nur seine Ausgaben.
Wichtig ist die Fortsetzungsmarke: Beim Start legt das Programm die Datei /home/keyhelp/www/keyhelp/.continue_upgrade_debian_12_to_13 an. Läuft das System bereits unter Debian 13 und die Datei existiert, setzt der zweite Aufruf das Upgrade fort, statt neu zu beginnen. Ohne diese Datei meldet der Starter unter Debian 13 „No upgrade available.“ Die Optionen -s und -c erzwingen Start oder Fortsetzung; nutzen Sie sie nur auf Anweisung des Supports.
Verifizieren: Der Startbildschirm zeigt „From: Debian 12 To: Debian 13“. Erscheint stattdessen „No upgrade available.“ oder „No KeyHelp installation found.“, stimmt die Ausgangslage nicht.
Schritt 3: Erster Lauf und Rückfragen
Nach [ENTER] arbeitet das Programm diese Stationen ab:
> Disable all RAM drives
> Update current operating system to latest state (This can take several minutes)...
> Update ionCube...
> Update SourceGuardian...
> Lock panel...
> Perform last KeyHelp update run...
> Update ioncube.ini...
> Update sourceguardian.ini...
> Update sources list...
> Perform upgrade (hand over to dist-upgrade)...
Ab „Lock panel“ ist das Panel gesperrt. Die Paketquellen, auch die Rspamd-Quelle, werden auf trixie umgestellt. Ein Countdown rät, bei mehr als einer Minute Stillstand selbst dist-upgrade aufzurufen; im Test war das nicht nötig.
Danach stellt der Paketmanager Fragen. Die erste kommt als blauer Dialog bei der Konfiguration von libc6:
Restart services during package upgrades without asking?
< Yes > < No >
Wir haben „Yes“ gewählt. Danach folgen Fragen zu Konfigurationsdateien, die KeyHelp angepasst hat, etwa:
Configuration file '/etc/fail2ban/filter.d/postfix.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
...
*** postfix.conf (Y/I/N/O/D/Z) [default=N] ?
Antworten Sie mit N. Andere Pakete fragen per Dialog „What do you want to do about modified configuration file …?“; dort ist „keep the local version currently installed“ vorausgewählt, [ENTER] genügt. So verlangt es auch Keyweb. Die Fragen im Test:
| Datei | Art der Frage | Antwort |
|---|---|---|
/etc/awstats/awstats.conf | Text (Y/I/N/O/D/Z) | N |
/etc/proftpd/modules.conf | Dialog | keep the local version |
/etc/fail2ban/filter.d/apache-common.conf | Text | N |
/etc/fail2ban/filter.d/postfix.conf | Text | N |
/etc/bind/named.conf, named.conf.local, named.conf.options | Text | N |
/etc/ssh/sshd_config | Dialog | keep the local version |
/etc/apache2/mods-available/ssl.conf | Text | N |
/etc/clamav/freshclam.conf | Dialog | keep the local version |
/etc/dovecot/dovecot.conf | Dialog | keep the local version |
Gegen Ende meldet der Paketmanager einen BIND-Fehler, den der zweite Lauf behebt (siehe „Typische Fehler“):
/etc/bind/named.conf:11: parsing failed: file not found
dpkg: error processing package bind9 (--configure):
installed bind9 package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
bind9
E: Sub-process /usr/bin/dpkg returned an error code (1)
Anschließend aktiviert das Programm ionCube und SourceGuardian, startet sich selbst neu und hält an:
> Pre-checking system...
Attention The server reports that a reboot is required to install pending updates.
Please reboot your server, then start this upgrade application again.
Verifizieren: cat /etc/debian_version zeigt bereits 13.7, und ls /home/keyhelp/www/keyhelp/.continue_upgrade_debian_12_to_13 findet die Fortsetzungsmarke. Im Test dauerte dieser Lauf rund 17 Minuten.
Schritt 4: Neustart und zweiter Lauf
Starten Sie den Server neu:
reboot
Danach läuft der Debian-13-Kernel, aber dovecot, named und proftpd standen im Test auf „failed“. Das ist der erwartete Zwischenstand. Starten Sie in einer neuen screen-Sitzung das Programm mit demselben Befehl wie in Schritt 2. Es erkennt die Fortsetzung:
... Press [ENTER] to continue the upgrade | Abort with [CTRL] + [C]
Nach [ENTER] passt es die Dienste an Debian 13 an:
> Update Bind9...
> Install systemd-timesyncd...
> Install python3-pyinotify / python3-systemd...
> Update PHP...
> Update PHP mods...
> Update PHP-FPM...
> Update Dovecot...
> Update Apache...
> Update Postfix...
> Update ProFTPD...
> Update Fail2ban...
> Update current operating system to latest state. This can take several minutes...
> Updating chroot environments, if there are any...
> Ensure correct hostname...
> Cleanup...
> Unlock panel...
> Set new Debian 13 default behaviour for /tmp + /var/tmp RAM drives...
The upgrade was successfully completed.
The system will now reboot.
... Press [ENTER] to reboot | Abort with [CTRL] + [C]
Bei „Update Apache“ schreibt KeyHelp die vHosts neu und legt die PHP-FPM-Pools für PHP 8.4 an. Der Lauf dauerte gut eine Minute. Bestätigen Sie den Neustart mit [ENTER].
Verifizieren: Die Fortsetzungsmarke ist verschwunden, keyhelp version zeigt das neue System:
KeyHelp : 26.1.1 (Build 3698)
Operating System : Debian 13.7 (64-bit)
Schritt 5: Prüfliste nach dem Upgrade
Prüfen Sie die Dienste und den Kundenbetrieb, bevor Sie das Wartungsfenster schließen:
grep PRETTY /etc/os-release
uname -r
systemctl --failed
systemctl is-active apache2 php8.4-fpm mariadb postfix dovecot rspamd named proftpd fail2ban
dpkg --audit
findmnt /tmp
Testen Sie danach eine Kundendomain, Mailversand und -empfang über ein Testpostfach, einen Datenbank-Login und den „Systemstatus“ im Panel. Löschen Sie den Snapshot erst nach einigen stabilen Tagen.
Die Versionen im Test vorher und nachher:
| Komponente | Debian 12 | Debian 13 |
|---|---|---|
| Kernel | 6.1.0-53 | 6.12.111 |
| PHP (System) | 8.2.33 | 8.4.26 |
| MariaDB | 10.11.18 | 11.8.6 |
| Apache | 2.4.68 | 2.4.68 |
| Postfix | 3.7.11 | 3.10.13 |
| Dovecot | 2.3.19.1 | 2.4.1 |
| Rspamd | 4.2.0 | 4.2.0 |
| ProFTPD | 1.3.8 | 1.3.8c |
Verifizieren: systemctl --failed ist leer, dpkg --audit gibt nichts aus, und alle Dienste melden active. Im Test lieferte die PHP-Testseite des Kunden danach:
PHP 8.4.26 DB 11.8.6-MariaDB-0+deb13u1 from Debian rows 1
Typische Fehler
bind9: „parsing failed: file not found“
Das neue BIND-Paket entfernt named.conf.default-zones, die behaltene named.conf bindet sie aber noch ein. Deshalb der Fehler, und named startet nach dem Zwischen-Neustart nicht. Der zweite Lauf korrigiert das bei „Update Bind9“ und bindet named.conf.root-hints ein. Antworten Sie trotzdem mit N und reparieren Sie nichts von Hand.
Dienste nach dem ersten Neustart „failed“
Dovecot, BIND und ProFTPD laufen zwischen beiden Läufen nicht. Für Dovecot nennen die Debian-13-Release-Notes ein inkompatibles Konfigurationsformat, das Skript passt es im zweiten Lauf an. Halten Sie die Pause kurz.
Harmlose Meldungen
sh: 1: dmidecode: not found
Failed to stop php8.2-fpm.service: Unit php8.2-fpm.service not loaded.
WARNING: Module xdebug ini file doesn't exist under /etc/php/8.4/mods-available
postconf: warning: /etc/postfix/main.cf: support for parameter "smtpd_use_tls" will be removed; ...
Diese Zeilen erschienen im Test ohne Folgen. Bei der ersten zugestellten Mail meldet Dovecot einmalig ein Sieve-Skript im alten Format („automatically fixed when re-compiled“).
/tmp liegt jetzt im Arbeitsspeicher
Nach dem Upgrade ist /tmp ein tmpfs, wie es Debian 13 laut Release Notes standardmäßig vorsieht. Große temporäre Dateien belegen damit RAM. Keyweb verweist für Anpassungen auf „Konfiguration“ → „RAM-Drive“ in KeyHelp. /var/tmp lag im Test weiter auf der Platte.
Eigene Paketquellen fehlen
Das Skript schreibt /etc/apt/sources.list neu (laut Keyweb dokumentiert, im Test bestätigt). Tragen Sie eigene Quellen danach mit der passenden Trixie-Version wieder ein.
Häufige Fragen
Kann ich das Upgrade auch per apt full-upgrade selbst machen?
Keyweb verlangt die bereitgestellten Skripte. Der Test zeigt warum: Erst der zweite Lauf macht BIND, PHP-FPM und Dovecot unter Debian 13 lauffähig.
Wie lange sind Webseiten offline?
Im Test dauerte das Upgrade rund 20 Minuten inklusive zweier Neustarts; Ausfallzeiten einzelner Dienste haben wir nicht gemessen. Größere Server brauchen länger.
Werden PHP-Versionen der Kunden umgestellt?
Die System-PHP-Version wechselt von 8.2 auf 8.4, und KeyHelp legt die Pools der Kunden für 8.4 neu an. Zusätzliche Interpreter, die Sie im Panel installiert haben, haben wir nicht getestet; Versionen unter 7.4 gibt es laut Keyweb unter Debian 13 nicht.
Bleiben DKIM-Schlüssel und Postfächer erhalten?
Postfächer, Anmeldung und Zustellung funktionierten im Test weiter. Rspamd lief schon unter Debian 12. DKIM haben wir nicht gesondert geprüft.
Testumfang
Wir haben einen frischen KeyHelp-26.1.1-Server auf Debian 12.15 mit Testkunde, Domain, Postfach und Datenbank in einer virtuellen Maschine nach Debian 13.7 gebracht; Web, Mail und Datenbank liefen danach. Auffällig war nur der BIND-Fehler im ersten Lauf, den der zweite behob. Nicht geprüft wurden Rückspielen eines Snapshots, Let's-Encrypt-Zertifikate, DKIM und zusätzliche PHP-Interpreter. Testen Sie diese Punkte auf Ihrem Server selbst.
Fazit
Das offizielle Skript erledigt den Wechsel von Debian 12 auf 13 zuverlässig, verlangt aber Aufmerksamkeit: zwei Läufe, ein Neustart dazwischen, rund ein Dutzend Fragen zu Konfigurationsdateien und eine Fehlermeldung, die man kennen muss. Wer vorher sichert, die Fragen mit „beibehalten“ beantwortet und den Zwischenzustand nicht für einen Defekt hält, ist in einer knappen halben Stunde fertig. Danach laufen PHP 8.4 und MariaDB 11.8, und der Server erhält wieder reguläre Sicherheitsupdates. Für weitere Härtung lohnt der Blick auf automatische Sicherheitsupdates mit unattended-upgrades.
Weiterführende Anleitungen und Quellen
- KeyHelp installieren und absichern: das kostenlose Hosting-Panel für eigene Server
- KeyHelp-Backups richtig einrichten: externe Sicherung, Rotation und getesteter Restore
- Keyweb: Upgrade von Debian 12 auf Debian 13
- Keyweb: KeyHelp 25.2 mit Debian-13-Unterstützung
- Upgrade-Skript upgrade_operating_system.sh
- Debian 13: Release Notes, Punkte beim Upgrade
- Debian 12: Release-Informationen und Supportzeitraum


