Plesk: Fallstricke bei Installation und Update
Die richtige Reihenfolge von Betriebssystem und Panel, Konflikte mit vorinstallierten Diensten und was vor einem grossen Versionssprung gesichert gehört.
Das Wichtigste
- Plesk gehört auf ein frisch installiertes System. Vorhandene Webserver-, Mail- oder Datenbankdienste führen zu Konflikten, die schwer zu entwirren sind.
- Das Panel verwaltet die Konfigurationsdateien selbst. Änderungen von Hand werden beim nächsten Schreibvorgang überschrieben.
- Vor einem Versionssprung: Snapshot des Servers und ein eigener Export der Inhalte. Das Panel-Backup allein reicht nicht.
- Nach jeder Aktualisierung Mail und TLS gezielt prüfen – dort treten die meisten Folgefehler auf.
Ein Panel nimmt Arbeit ab und legt sich dabei zwischen dich und das System. Wer die Grenze kennt, kommt gut damit zurecht – wer sie überschreitet, verbringt Abende mit Fehlersuche.
Reihenfolge: erst das System, dann das Panel
Plesk richtet Webserver, Mailserver, Datenbank und DNS selbst ein und erwartet dafür ein sauberes System. Was zu Konflikten führt:
- ein bereits installierter Apache oder nginx mit eigener Konfiguration
- ein vorhandener Mailserver, der Port 25 belegt
- eine laufende MySQL- oder MariaDB-Instanz mit eigenen Benutzern
- Firewallregeln, die das Panel nicht kennt
- ein anderes Panel, das noch Reste hinterlassen hat
Die Reihenfolge, die funktioniert:
- Betriebssystem frisch installieren, in einer von Plesk unterstützten Version.
- Nur Grundlegendes einrichten: Netzwerk, Zeitzone, SSH-Schlüssel.
- Plesk installieren.
- Danach die Dienste über das Panel konfigurieren.
Was das Panel selbst verwaltet
Plesk erzeugt die Konfigurationsdateien von Apache, nginx, Postfix und Dovecot aus seiner eigenen Datenbank. Änderungen direkt in diesen Dateien verschwinden beim nächsten Schreibvorgang – spätestens, wenn im Panel irgendetwas an der Domain geändert wird.
Dauerhafte Anpassungen gehören stattdessen an die vorgesehenen Stellen:
| Anpassung | richtiger Ort |
|---|---|
| Direktiven pro Domain | Panel: „Apache- und nginx-Einstellungen” → zusätzliche Direktiven |
| Serverweite Vorlagen | /usr/local/psa/admin/conf/templates/custom/ |
| PHP-Einstellungen | Panel: PHP-Einstellungen pro Domain |
| Cronjobs | Panel: geplante Aufgaben |
| Firewall | Panel-Erweiterung, nicht ufw parallel |
Die Vorlagen unter templates/custom/ sind der Weg für Änderungen, die für alle Domains gelten sollen. Sie überschreiben die Standardvorlagen und überleben Aktualisierungen.
Vor einem Versionssprung
Ein Update auf eine neue Hauptversion greift tief ein: Es tauscht Komponenten, migriert die Panel-Datenbank und passt Konfigurationen an. Vorher gehört gesichert:
# Datenbanken
for db in $(mysql -N -e 'SHOW DATABASES' | grep -vE 'information_schema|performance_schema|sys'); do
mysqldump --single-transaction --quick "$db" | gzip > "/backup/$db-$(date +%F).sql.gz"
done
# Webinhalte
tar czf "/backup/vhosts-$(date +%F).tar.gz" /var/www/vhosts
# Panel-Konfiguration
plesk bin pleskbackup --server -v /backup/plesk-full
Dazu, falls der Anbieter es anbietet, ein Snapshot der gesamten virtuellen Maschine. Der ist die einzige Sicherung, die auch dann hilft, wenn das Panel nach dem Update nicht mehr startet.
Und: die Liste aller Domains mit ihren DNS-Einträgen exportieren. Wenn Plesk auch als DNS-Server dient, hängt daran die Erreichbarkeit.
Nach dem Update gezielt prüfen
Die Punkte, an denen erfahrungsgemäss etwas hängt:
- Panel erreichbar auf Port 8443.
- Webseiten laden – nicht nur die Startseite, auch eine Seite mit Datenbankzugriff.
- TLS-Zertifikate gültig. Nach Updates kommt es vor, dass eine Domain auf das selbstsignierte Standardzertifikat zurückfällt.
- Mailversand und -empfang. Eine Testmail in beide Richtungen, und im Quelltext prüfen, ob DKIM noch signiert.
- Cronjobs vorhanden und beim letzten Termin gelaufen.
- PHP-Version pro Domain unverändert – bei Aktualisierungen wird gelegentlich auf eine andere Version zurückgestellt.
# Zustand aller Dienste
plesk sbin service --list
# Reparaturlauf, wenn etwas nicht stimmt
plesk repair all -n # -n: nur prüfen, nichts ändern
plesk repair all -y # tatsächlich reparieren
Der Reparaturlauf erst mit -n starten und die Ausgabe lesen. Er greift teilweise weit ein und setzt Konfigurationen auf den Panel-Stand zurück – was gewollt ist, wenn jemand von Hand editiert hat, und unerwünscht, wenn eine bewusste Ausnahme dabei verlorengeht.
Der Klassiker: Mail nach dem Update
Wenn nach einer Aktualisierung Mails nicht mehr ankommen, sind es fast immer dieselben drei Ursachen:
- Der Mailserver wurde gegen einen anderen getauscht und die Konfiguration nicht vollständig übernommen.
- Das TLS-Zertifikat für den Mailserver ist nicht mehr zugeordnet, und Clients verweigern die Verbindung.
- Die DKIM-Signierung ist deaktiviert, weil sie pro Domain neu eingeschaltet werden muss.
Der schnellste Weg zur Antwort ist auch hier das Log:
tail -f /var/log/maillog # RHEL-Familie
tail -f /var/log/mail.log # Debian-Familie
Eine Testmail senden, während das Log mitläuft. Die Fehlermeldung steht dort im Klartext.
Häufige Fragen
Kann ich Plesk auf einem laufenden Server nachinstallieren?
Technisch ja, empfohlen ist es nicht. Plesk erwartet, die Dienste selbst einzurichten. Trifft es auf einen vorhandenen Webserver oder Mailserver, entstehen Konflikte bei Ports, Konfigurationspfaden und Benutzern. Der zuverlässige Weg ist ein neuer Server und ein Umzug der Inhalte.
Warum sind meine Änderungen an der Apache-Konfiguration verschwunden?
Weil Plesk die Konfiguration aus seiner eigenen Datenbank neu erzeugt. Für dauerhafte Anpassungen gibt es im Panel die zusätzlichen Direktiven pro Domain oder Vorlagendateien unter conf.d – nur was dort steht, überlebt.
Was muss ich vor einem Major-Update sichern?
Einen Snapshot des Servers, falls der Anbieter das anbietet, plus einen eigenen Export: Datenbanken als Dump, Webinhalte als Archiv, Mailkonten per IMAP-Kopie und die Liste der Domains samt DNS-Einträgen. Ein Panel-Backup nützt wenig, wenn das Panel selbst nicht mehr startet.
Wie prüfe ich nach dem Update, ob alles läuft?
Gezielt in dieser Reihenfolge: Panel erreichbar, Webseiten laden, TLS-Zertifikate gültig, Mailversand und -empfang funktionieren, Cronjobs sind noch eingetragen, Datenbankzugriff aus den Anwendungen heraus.
Weiterlesen
- Linux-Grundlagen für Webserver
Paketverwaltung, Dienste, Rechte, Firewall und die Kommandos, mit denen du eine Störung in Minuten eingrenzt.
- Backup-Strategie für Webprojekte
3-2-1 auf Webprojekte übersetzt: Was gesichert gehört, wie oft, und warum ein Backup ohne getesteten Restore keins ist.
- AWStats einrichten und Logs richtig lesen
Logfile-Analyse ohne JavaScript: Installation, Cron-Lauf, Bot-Filter und die Kennzahlen, die wirklich etwas aussagen.
- Monitoring und Logauswertung im Alltag
Was überwacht gehört, welche Schwellen sinnvoll alarmieren und wie du aus Logs eine Störungsursache herausliest.