Servermigration für einen Entrümpelungsbetrieb

Ein Entrümpelungsbetrieb lebt von Anfragen, die über das Formular auf der Website hereinkommen. Wenn diese Website langsam ist, merkt das niemand in der Buchhaltung. Man sieht nur, dass weniger Anfragen kommen, und sucht den Fehler beim Wetter oder bei der Konkurrenz.

Am Anfang der Servermigration stand das, was Rümpelschwab uns schilderte: eine Website, die zur Lastzeit am Montagvormittag ins Stocken kam, und ein Shared-Hosting-Paket, das der Betrieb geerbt hatte. Eigene Messungen aus dieser Zeit liegen uns nicht vor.

Ausgangslage

Auf einer solchen Maschine teilen sich viele Websites dieselben Ressourcen, und die eigene Ladezeit hängt davon ab, was die Nachbarn gerade tun.

Dass dieser Effekt messbar ist, zeigt eine Untersuchung zu Noisy-Neighbor-Effekten in Multi-Tenant-Umgebungen (arXiv:2604.03145). Gemessen wurde dort in der Cloud, nicht auf dieser Website.

Vier Schritte zum eigenen Server

Erstens der Bedarf. Hier stützte sich die Entscheidung auf die Schilderung des Betriebs.

Heute würden wir zuerst messen: die Antwortzeit des Servers zur Lastzeit am Montagvormittag und den Largest Contentful Paint im 75. Perzentil, für den ein Wert von 2,5 Sekunden oder weniger als gut gilt. Wer nur den ruhigen Nachmittag misst, sieht das Problem nicht.

Zweitens die Alternative zum Shared Hosting: eine eigene Maschine statt eines größeren Pakets. Ein größeres Paket hätte mehr Speicher und mehr PHP-Prozesse gebracht, die Maschine aber weiter mit fremden Websites geteilt. Die Ursache aus der Ausgangslage wäre geblieben.

Die Wahl fiel deshalb auf eine virtuelle Maschine mit Abrechnung nach Stunden und Monatsdeckel. Dazu Plesk als Oberfläche auf dem Hetzner-Server, weil der Betrieb die Website auch ohne uns bedienen können muss.

Drittens der Umzug selbst: erst die Kopie zum Laufen bringen und prüfen, dann die Adresse umlegen. Wer die Adresse zuerst umlegt, sucht Fehler unter Zeitdruck im laufenden Betrieb.

Viertens der Betrieb danach: Der Server braucht Backups und jemanden, der hinsieht, wenn etwas klemmt; die Aktualisierungen von Debian, PHP und Plesk spielen wir ein. Ein neuer Kernel wirkt erst nach einem Neustart.

Der reguläre Support für Debian 12 endete am 11. Juli 2026, der LTS-Support läuft bis zum 30. Juni 2028. Bis dahin ist der Wechsel auf die nächste Debian-Version zu planen.

Ergebnis

Der Stand heute, am 25. August 2026 auf dem neuen Server selbst ausgelesen: sechs Kerne, 8 GB Arbeitsspeicher, 237 GB SSD, Debian 12 mit Plesk Obsidian, nginx vor Apache, PHP 8.4, TLS 1.3.

Seit dem 4. November 2025 läuft die Maschine ohne Neustart.

Die Kehrseite der langen Laufzeit: Der Neustart für den neuen Kernel steht noch aus und liegt im nächsten Wartungsfenster; bis dahin läuft der Server auf dem alten.

Die Ladezeit vor und nach dem Umzug haben wir nicht gemessen, ein Vorher-Nachher-Vergleich liegt deshalb nicht vor. Nachprüfbar verändert hat sich anderes: Die Ressourcen der Maschine stehen dem Betrieb allein zu, Update- und Neustarttermine liegen in seinem Kalender, die Website lässt sich über Plesk selbst bedienen, und die Backups liegen in eigener Hand.

Was daraus folgt

Die unbequeme Seite des eigenen Servers: Er verlagert Verantwortung. Backups, Aktualisierungen und Überwachung übernimmt beim Shared Hosting der Anbieter; auf dem eigenen Server stehen sie in der Rechnung.

Für einen Handwerksbetrieb, bei dem die Website Anfragen bringt, lohnt der eigene Server. Für einen, bei dem sie eine Visitenkarte ist, nicht.

Quellen

Quellen zuletzt geprüft am 25. August 2026.

• Causal Inference for Quantifying Noisy Neighbor Effects in Multi-Tenant Cloud Environments, arXiv:2604.03145, eingereicht am 3. April 2026. Daraus der Satz zur Nachbarschaft auf einer geteilten Maschine. Die Untersuchung misst Multi-Tenant-Umgebungen in der Cloud, nicht diese Website. arxiv.org/abs/2604.03145

• web.dev (Google): Largest Contentful Paint (LCP), Stand 4. September 2025. Daraus die heute geltende Schwelle: „Good LCP values are 2.5 seconds or less“, gemessen im 75. Perzentil. web.dev, Largest Contentful Paint

• Hetzner Docs: FAQ, Abschnitt Billing. Daraus die Abrechnung nach Stunden mit Monatsdeckel: „Your server’s bill will never exceed its monthly price cap.“ Anbieterangabe. docs.hetzner.com, Cloud Billing FAQ

• Debian: Release Information zu „bookworm“. Daraus Debian 12, veröffentlicht am 10. Juni 2023, regulärer Support bis 11. Juli 2026, LTS-Support bis 30. Juni 2028. debian.org, bookworm

• The PHP Group: Supported Versions. Daraus PHP 8.4, erschienen am 21. November 2024, aktiver Support bis 31. Dezember 2026, Security-Support bis 31. Dezember 2028. php.net, Supported Versions

• IETF: The Transport Layer Security (TLS) Protocol Version 1.3, RFC 8446, Standards Track, August 2018. Daraus die Angabe TLS 1.3. rfc-editor.org, RFC 8446

• Plesk: Release Notes zu Plesk Obsidian 18.0.79, 3. Juli 2026. Daraus der Produktname und der Versionsstand. Anbieterangabe. plesk.com, Obsidian 18.0.79

Eigene Messungen und Kundenangaben

• Ausstattung und Betriebsstand, also sechs Kerne, 8 GB Arbeitsspeicher, 237 GB SSD, Debian 12, Plesk Obsidian, PHP 8.4, TLS 1.3 und der Aufbau mit nginx vor Apache: am 25. August 2026 auf dem beschriebenen Server selbst ausgelesen.

• Laufzeit ohne Neustart seit dem 4. November 2025: Systemlaufzeit am selben Tag auf demselben Server selbst abgelesen.

• Die wiedergegebene Ausgangslage, also die träge Website zur Lastzeit und das geerbte Shared-Hosting-Paket, beruht auf der Schilderung des Betriebs. Eigene Messungen dazu liegen nicht vor, weitere Kundennamen nennen wir nicht.