100 Tage netcup: was dir vorher niemand sagt

Auf diesem VPS entsteht jedes Rezept dieser Seite. Seit dem 16. Juli läuft er, und in der Zeit haben wir rund zwanzig Anwendungen darauf aufgesetzt, getestet und wieder abgeräumt. Dieser Artikel ist die Bilanz: was tatsächlich passiert ist, und die Eigenheiten, über die wir gestolpert sind.

Kein Werbetext. Die unangenehmste Zahl steht gleich in Schritt 2.

Was bauen wir?

Nichts – wir berichten. Am Ende weißt du, was dich bei netcup im Dauerbetrieb erwartet, welche vier Eigenheiten dich sonst je einen Abend kosten, was die Preisrunde vom September für dich bedeutet – je nachdem, ob du Bestandskunde bist oder neu bestellst – und wie netcup auf eine kritische Kernel-Lücke reagiert hat.

Die Maschine ist ein VPS 1000 G12 mit 4 vCore, 8 GB RAM und 251 GB Platte, auf Debian 13. Darauf laufen dauerhaft nur ein Reverse Proxy und wechselnde Test-Setups.

Voraussetzungen

Keine – das hier ist ein Bericht, kein Rezept. Wenn du mitlesen und bei dir nachsehen willst, brauchst du nur einen SSH-Zugang zu deinem eigenen Server. Die Befehle in Schritt 2 laufen auf jedem Linux-Host mit Docker.

Wer noch gar keinen Server hat: Die Tarife stehen in der netcup-Übersicht, und was dein Vorhaben wirklich braucht, schätzt der Server-Rechner.

Schritt für Schritt

Schritt 1: Was in 79 Tagen passiert ist

Das Langweiligste zuerst, und das ist als Kompliment gemeint:

Der Server lief durch. Keine Ausfälle, keine abgestürzten Dienste, keine Supportfälle. Die automatischen Sicherheitsupdates haben in der ganzen Zeit genau zweimal etwas zu tun gehabt – beide Male Docker, am 21. Juli. Das ist kein Mangel, sondern Debian stable: Es passiert selten etwas, und wenn, dann gezielt.

Die 39 apt-Läufe sagen dabei mehr über uns als über den Server: Es sind fast ausschließlich unsere eigenen Installationen für Tutorials, nicht automatische Wartung. Ein Server hält sich eben nicht selbst sauber. Was ohne Zutun passiert, sind genau jene zwei Sicherheitsupdates – alles andere steht und fällt damit, dass jemand hinsieht.

Zwei Einschränkungen, damit die Zahl nicht besser klingt als sie ist. Erstens sagt „79 Tage Laufzeit" nichts über Verfügbarkeit aus – wir haben nicht von außen gemessen, sondern nur festgestellt, dass die Maschine nicht neu gestartet ist. Zweitens gilt das für den Host, nicht für alles darauf:

docker ps --format "{{.Names}}\t{{.Status}}"

traefik-traefik-1   Up 2 weeks

Der Reverse Proxy lief eben nicht 79 Tage, sondern zwei Wochen. Ein Docker-Update hat ihn irgendwann neu gestartet. Das ist unkritisch und genau das, was restart: unless-stopped leisten soll – aber „der Server läuft seit elf Wochen" und „dein Dienst lief elf Wochen" sind zwei verschiedene Aussagen.

Eine Zahl aus der Tabelle verdient noch einen Blick: 31 Let’s-Encrypt-Zertifikate in 79 Tagen. Jedes Test-Setup bekam eine eigene Subdomain, und für jede holt Traefik ein eigenes Zertifikat. Das ist unauffällig, bis man weiß, dass Let’s Encrypt pro registrierter Domain 50 Zertifikate in 7 Tagen ausstellt – global, unabhängig davon, welcher Account fragt. Danach füllt sich das Kontingent nur langsam wieder auf, mit einem Zertifikat alle gut drei Stunden.

Über 79 Tage verteilt ist das völlig unkritisch. Wer aber an einem Nachmittag zwanzig Subdomains durchprobiert und dabei ein paarmal von vorn anfängt, steht plötzlich vor einem Proxy, der keine Zertifikate mehr bekommt – und sucht den Fehler bei sich. Für Testreihen gibt es deshalb Let’s Encrypts Staging-Umgebung, die dieselbe Mechanik ohne Kontingent durchspielt.

Schritt 2: Die Platte füllt sich – und es sind nicht deine Daten

Hier die unangenehme Zahl. Ein Blick auf die Platte:

df -h /

/dev/vda4       251G   73G  169G  31% /

73 GB belegt. Auf einem Server, auf dem genau ein Container läuft. Die Erklärung:

docker system df

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          107       1         74.58GB   68.43GB (91%)
Containers      1         1         8.192kB   0B (0%)
Build Cache     33        0         209.5MB   4.096kB

107 Images, 74,58 GB, davon 91 % wegwerfbar. Nicht die Daten füllen den Server, sondern die Reste. Jedes docker compose down räumt Container und Volumes ab – die heruntergeladenen Images bleiben liegen. Die größten Brocken bei uns:

3.69GB  mcr.microsoft.com/playwright:v1.56.0-noble
3.50GB  ghcr.io/paperless-ngx/paperless-ngx:3.1.3
3.45GB  mcr.microsoft.com/playwright:v1.61.1-noble
3.38GB  stirlingtools/stirling-pdf:2.14.3
3.12GB  ghcr.io/immich-app/immich-server:v3.1.0
3.11GB  ghcr.io/immich-app/immich-server:v3.0.3

Zweimal Playwright, zweimal Immich – jedes Update legt ein neues Image daneben, das alte bleibt. Nach ein paar Monaten hat man eine Image-Halde, von der man nichts merkt, bis die Platte eng wird.

Das ist der Punkt, an dem die Tarifgeneration plötzlich zählt. Unser VPS 1000 ist ein G12 mit 251 GB. Der aktuelle G12.5 kommt mit 128 GB. Dieselbe Halde wäre dort schon über die Hälfte der Platte – und das, bevor überhaupt Nutzdaten anfallen.

Aufräumen ist eine Zeile:

docker image prune -a

Das entfernt alle Images, die gerade kein Container benutzt. Lass es laufen, wenn du weißt, was läuft; sonst zieht der nächste Start die Images neu. Für den Alltag reicht das mildere docker image prune – das wirft nur unbenannte Zwischenschichten weg.

Schritt 3: Mail geht nicht raus, und es liegt nicht an dir

Die erste Eigenheit, die Zeit kostet. Du setzt einen Mailserver auf, alles sieht gut aus, und ausgehende Mail läuft in einen Timeout auf Port 25.

Schuld ist netcups Default-Policy „netcup Mail block": Sie sperrt die Ports 25, 465 und 587 nach außen. Gemessen haben wir genau das – diese drei laufen in einen Timeout, während 993, 22 und 443 offen sind.

Der wichtige Teil: Das ist kein Supportfall. Du nimmst dem Server die Policy im Server Control Panel unter Firewall → Policys selbst ab, ohne Ticket, ohne Wartezeit. Viele suchen den Fehler stattdessen stundenlang in Postfix. Wie es geht, steht in netcup-Firewall einrichten; dass deine Mail danach auch ankommt, ist noch einmal ein eigenes Thema in E-Mail-Zustellbarkeit.

Schritt 4: Die Firewall ist bei UDP zustandslos

Die Eigenheit, die am meisten verwirrt, weil sie sich wie ein kaputter Server anfühlt.

Bei TCP merkt sich die netcup-Firewall, dass du eine Verbindung aufgebaut hast, und lässt die Antwort durch. Bei UDP tut sie das nicht. Dein Server fragt einen DNS-Server auf Port 53, die Antwort kommt von Port 53 zurück – und fliegt raus, weil keine Regel sie erwartet.

Das Ergebnis: Namensauflösung und Zeitsynchronisation funktionieren nicht, obwohl ausgehend alles erlaubt scheint. Du brauchst für DNS und NTP eigene Eingangsregeln auf Quellport 53 und 123. Die fertige, wiederverwendbare Policy dafür steht ebenfalls in netcup-Firewall einrichten.

Wer die SCP-Firewall gar nicht nutzt, merkt davon nichts – dann schützt nur die Firewall auf dem Server selbst.

Schritt 5: Eingehend ist fast alles zu

Die dritte Eigenheit ist die harmloseste, kostet aber genauso sicher einen Nachmittag, wenn man sie nicht kennt. Offen sind bei uns eingehend 22, 80 und 443. Sonst nichts.

Gemessen: Ein Dienst auf 8443 lief von außen in einen Timeout, während er auf dem Server selbst tadellos antwortete. Genau dieses Muster – lokal geht’s, von außen nicht – ist das Erkennungszeichen.

Jeder weitere Port ist eine eigene Policy im SCP. Wir mussten das einmal für Jitsi machen, das UDP 10000 für die Medienströme braucht. Plane das ein, bevor du einen Dienst auswählst, der exotische Ports braucht.

Schritt 6: Die Preisrunde – und was Bestandskunden niemand sagt

Am 22. September hat netcup die Preise für Neubestellungen erhöht und das im eigenen Forum offen begründet: Die Einkaufspreise für RAM und Flash-Speicher liegen beim Fünffachen von vor einem Jahr, der Markt ist bis in die Refurbished-Ware leergekauft.

Bemerkenswert ist weniger die Erhöhung als die Begründung. netcup legt offen, welche vier Möglichkeiten zur Wahl standen: alles abverkaufen und auf „ausverkauft" stellen, die Server massiv überbuchen, die Preise halten und dafür die Spezifikationen zusammenstreichen – oder die Produkte an das Marktniveau anpassen. Entschieden haben sie sich für den vierten Weg. Man muss die Preise nicht mögen, aber die Alternative „gleicher Preis, heimlich weniger Leistung" wäre für dich als Betreiber die unangenehmere gewesen, weil man sie erst merkt, wenn es klemmt.

Was sich ändert:

Zur Platte schreibt netcup, man provisioniere weiterhin flash-basiert mit RAID 6, könne aber „nur NVMe nicht garantieren". Das ist etwas anderes als „keine NVMe mehr" – man weiß vorher nicht, was man bekommt.

Und jetzt der Teil, den man leicht übersieht, obwohl er bares Geld wert ist:

• Bestandsverträge werden nicht erhöht. Wer einen Server hat, zahlt weiter seinen Preis.
• Upgrades laufen zum alten Preis. netcup hat dafür eigens Kapazität auf der Bestands-Hardware freigehalten. Ein RS 1000 G12 lässt sich also auf einen RS 2000 G12 zu den alten Konditionen hochziehen – das gilt auch bei der Verlängerung.
• Die Tauschbörse erhält die alten Preise. Übernimmst du dort einen Vertrag, behältst du die G12-Konditionen, solange Angebote da sind.

Praktisch heißt das: Wenn du ohnehin wachsen willst, ist ein Upgrade des bestehenden Vertrags deutlich günstiger als eine Neubestellung. Und wenn du neu einsteigst, lohnt ein Blick in die Tauschbörse, bevor du bestellst.

Schritt 7: Tag 94 – netcup startet alle Server neu

Kurz vor Redaktionsschluss kam doch noch ein Neustart, und zwar nicht von uns. Am 15. Oktober wurde PwnEscape veröffentlicht (CVE-2026-99999, CVSS 9.3): ein Fehler im IPv4-Netzwerkstack des Linux-Kernels. Ein Gast kann damit über präparierte Pakete Speicher des Hosts auslesen; im Labor des Entdeckers reichte das bis zur Codeausführung auf dem Host. Gefunden hat ihn pwn.ai bei einem Sicherheitswettbewerb von Vercel. Der Fix steckt seit dem 14. Oktober im Kernel – wirksam wird er aber erst, wenn der KVM-Host mit dem gepatchten Kernel neu bootet. Und mit dem Host gehen alle VMs darauf mit.

Für einen Anbieter, auf dessen Hosts fremde Kunden nebeneinander laufen, ist das der schlimmste Fall: Eine VM könnte den Speicher ihrer Nachbarn lesen. netcup kündigte am 16. Oktober auf netcup-status.de blockweise Neustarts aller VPS und Root-Server ab dem 17. an, mit 20 bis 30 Minuten Unterbrechung je Server. Die Meldung sprach zunächst nur von Softwareupdates. In einem Nachtrag vom 19. Oktober nennt netcup den Grund ausdrücklich: PwnEscape, bekannt geworden erst wenige Stunden vor Beginn der Neustarts. Normalerweise, schreibt netcup dort, kündige man solche Wartungen mit mehreren Tagen Vorlauf an – das sei hier nicht möglich gewesen.

Bei uns war es am 18. Oktober so weit. Das Journal zeigt, wie der Neustart ankam:

journalctl -b -1 -u systemd-logind --no-hostname | grep hypervisor

Oct 18 10:19:30 systemd-logind[774]: System is powering down (hypervisor initiated shutdown).

hypervisor initiated shutdown heißt: netcup hat den Server über den QEMU-Gast-Agenten geordnet heruntergefahren, wie mit einem Druck auf den Ein-Aus-Schalter. Dienste wurden sauber beendet, Dateisysteme synchronisiert. Um 10:34 lief er wieder – 14½ Minuten Unterbrechung, weniger als angekündigt. Traefik kam dank restart: unless-stopped von selbst wieder hoch, zu tun war nichts.

Bemerkenswert ist das Timing. Einen öffentlichen Exploit gab es zu dem Zeitpunkt nicht; der Entdecker rechnet erst in einigen Wochen damit. netcup hat nicht gewartet, bis es einen gibt, sondern zwei Tage nach der Veröffentlichung mit den Neustarts begonnen. Eine Viertelstunde Ausfall an einem Sonntagvormittag ist dafür ein guter Preis – die Alternative wäre ein Host, auf dem eine fremde VM in deinen Speicher sieht.

Was du daraus mitnimmst:

• Dienste müssen ohne dich starten. Prüf, dass alles mit restart: unless-stopped oder als aktivierte systemd-Unit läuft. Ein Container, den du einmal von Hand gestartet hast, ist nach so einem Neustart einfach weg.
• Angekündigt heißt nicht terminiert. Die Statusmeldung nannte einen Zeitraum von Tagen, keine Uhrzeit pro Server. Die Benachrichtigungs-Mail kommt laut netcup inzwischen etwa eine Stunde vor dem Neustart des einzelnen Servers – an die Adresse aus dem Kundenkonto, also sieh zu, dass du die auch liest. Wer wissen will, wann sein Dienst wirklich weg war, braucht ein Monitoring von außen, etwa Uptime Kuma.
• Den Host patcht netcup, den Gast du. PwnEscape steckt im Kernel des KVM-Hosts, nicht in deiner VM – dort gibt es nichts zu tun, und ein Kernel-Update im Gast hätte nicht geholfen. Für deinen eigenen Kernel gilt trotzdem weiter, was unter „Wartung & Backups" steht.

Ob es dich schon getroffen hat, zeigt last:

last -x reboot shutdown | head -3

reboot   system boot  6.12.111+deb13-a Sun Oct 18 10:34 - still running
reboot   system boot  6.12.111+deb13-a Thu Oct  8 11:29 - 10:19 (9+22:49)
shutdown system down  6.12.111+deb13-a Sun Oct 18 10:19 - 10:34  (00:14)

Ein shutdown ab dem 17. Oktober, den du nicht selbst ausgelöst hast, war dieser Neustart. Achte auf die Kernel-Spalte: vor und nach dem Neustart dieselbe Version, 6.12.111. Neu gebootet hat der Host darunter, nicht unser System. Der Eintrag vom 8. Oktober ist übrigens unser eigener: der Neustart nach einem Kernel-Update, mit dem die Laufzeit aus Schritt 1 nach 84 Tagen endete.

Drei Tage später, am 21. Oktober, kam der nächste Notfall – diesmal in PHP (CVE-2026-109618 und -109619). netcup nahm Webhosting und Managed Server vorübergehend vom Netz und spielte selbst gepatchte PHP-Versionen ein. Auf einem VPS passiert das nicht: Dort steckt PHP in deinen Container-Images, und die aktualisiert niemand außer dir. Wie du herausfindest, welche deiner Dienste betroffen sind, steht in Den ganzen Docker-Stack sicher aktuell halten.

Wenn es nicht funktioniert

Dein Problem ist nicht dabei? Alle Fehlermeldungen durchsuchen →

Wartung & Backups

Nach hundert Tagen ist die Liste dessen, was man wirklich regelmäßig tun muss, kurz – aber sie ist nicht leer.

Monatlich aufräumen. docker image prune -a gehört in den Kalender, sonst wiederholt sich Schritt 2 bei dir. Zwei Minuten, und auf kleinen Platten der Unterschied zwischen „läuft" und „Disk full" an einem Sonntagabend.

Neu starten, wenn ein neuer Kernel da ist. Den Kernel des Hosts aktualisiert netcup – wie bei PwnEscape notfalls mit einem Neustart deines Servers. Den Kernel in deiner VM aktualisierst du. Automatische Sicherheitsupdates installieren ihn, aktivieren ihn aber nicht. Prüf mit ls /var/run/reboot-required und plane den Neustart selbst, statt ihn jahrelang aufzuschieben. Elf Wochen Laufzeit sind kein Ausweis von Qualität, wenn darunter ein ungepatchter Kernel läuft.

Snapshots sind kein Backup. Sie liegen beim selben Anbieter auf derselben Infrastruktur und helfen dir gegen einen kaputten Upgrade-Versuch, nicht gegen einen verlorenen Account. Wie man sie im SCP anlegt, steht in netcup Server Control Panel – das echte Backup gehört verschlüsselt weg vom Server, etwa mit restic.

Einmal im Quartal in die Rechnung sehen. Nach der Preisrunde sind Bestandsverträge und Neubestellungen unterschiedlich teuer. Wenn du wachsen willst, prüf zuerst das Upgrade deines bestehenden Vertrags – nicht den Warenkorb.