Was bauen wir?

Du lernst das netcup Server Control Panel (SCP) kennen – die Weboberfläche zu deinem Server – und erstellst dort einen Snapshot: einen vollständigen Abzug deiner Server-Festplatte, zu dem du bei einem Missgeschick in wenigen Minuten zurückkehrst. Am Ende weißt du, wann ein Snapshot dein Retter ist – und warum er trotzdem kein Ersatz für ein echtes Backup ist.

Voraussetzungen

• Ein netcup-Server, z. B. dein erster VPS.
• Deine SCP-Zugangsdaten – sie stehen in der netcup-Willkommensmail und sind andere als dein SSH-Login.

Schritt für Schritt

Schritt 1: Im SCP anmelden und den Server finden

Öffne servercontrolpanel.de und melde dich mit deinen SCP-Zugangsdaten an. Du landest in der Server-Liste; ein Klick auf deinen Server öffnet die Übersicht mit Produkt, Status und Hardware. Oben siehst du die Reiter, über die du alles steuerst – Snapshots liegen unter „Medien".

Schritt 2: Einen Snapshot erstellen

Geh auf Medien → Snapshots. Unter Snapshot erstellen füllst du aus:

• Name: benenne ihn nach dem Warum, nicht nach dem Datum allein – z. B. vor-update-2026-08. So weißt du später, wozu er da war.
• Beschreibung: ein Satz Kontext (optional, aber hilfreich).
• Festplatte: in der Regel vda (deine Systemplatte).
• Typ: hier liegt die wichtigste Entscheidung – siehe unten.

![Die Snapshot-Maske im SCP mit Name, Beschreibung, Festplatte und Typ](netcup-snapshot-erstellen.png “„Snapshot erstellen” – Name nach dem Zweck vergeben, Typ bewusst wählen")

Offline- oder Online-Snapshot?

• Offline-Snapshot: Der Server wird für die Aufnahme kurz heruntergefahren. Das garantiert einen konsistenten Stand – die richtige Wahl, wenn Datenbanken laufen, und wenn du dir die kurze Downtime leisten kannst.
• Online-Snapshot: Aufnahme im laufenden Betrieb, ohne Downtime. Bequem, aber bei aktiven Schreibvorgängen (z. B. eine Datenbank mitten im Schreiben) kann der Abzug inkonsistent sein.

Ein Klick auf Erstellen startet den Vorgang; je nach Datenmenge dauert er ein paar Minuten. Er läuft im Hintergrund – in der Liste darüber tauchen anschließend Erstellungsdatum und Typ auf, sobald er fertig ist. Die kurze Downtime eines Offline-Snapshots legst du am besten in eine ruhige Zeit; danach ist dein Rückkehrpunkt gesetzt und du kannst die geplante Änderung angehen.

Schritt 3: Einen Snapshot zurückspielen

Ist etwas schiefgegangen, findest du den Snapshot in der Liste unter Snapshots; in der Spalte Aktionen gibt es Zurückspielen (Restore).

Schritt 4: Die weiteren Rettungsanker im SCP

Das SCP hat mehr als Snapshots – gut zu wissen für den Ernstfall:

• Bildschirm (VNC-Konsole): direkter Bildschirmzugang zum Server, auch wenn SSH streikt – der Rettungsanker aus dem SSH-Tutorial.
• Rettungssystem: bootet den Server in ein Notfall-Linux, um eine kaputte Installation zu reparieren.
• Medien → Images / DVD-Laufwerk: ein anderes Betriebssystem einspielen.

Wenn es nicht funktioniert

Symptom: Der neue Snapshot hat den alten überschrieben.

Ursache & Lösung: Das ist erwartetes Verhalten – ein VPS hat nur einen Snapshot-Slot. Wenn du einen bestimmten Stand aufheben willst, spiele ihn zurück oder sichere die Daten separat, bevor du einen neuen Snapshot anlegst.

Symptom: Nach einem Online-Snapshot-Restore ist die Datenbank beschädigt.

Ursache & Lösung: Ein Online-Snapshot fängt einen laufenden Schreibvorgang womöglich mittendrin ein. Für Server mit Datenbank nimm einen Offline-Snapshot oder erstelle vorher einen Datenbank-Dump.

Symptom: Du kommst nicht ins SCP.

Ursache & Lösung: Das SCP nutzt eigene Zugangsdaten (nicht SSH). Sie stehen in der Willkommensmail; ein vergessenes SCP-Passwort setzt du im netcup-Kundenkonto (CCP) zurück.

Wartung & Backups

• Snapshot ≠ Backup – der wichtigste Punkt. Ein Snapshot liegt bei netcup, unter deinem Account, in einem Slot und ist als Momentaufnahme gedacht. Fällt der Account, das Rechenzentrum oder dein Zugang aus, ist er mit weg. Er ist ein schnelles Sicherheitsnetz, kein ausgelagertes Backup.
• Snapshot vor jeder riskanten Aktion. Vor großen Updates, Migrationen oder heiklen Config-Änderungen: erst Snapshot, dann loslegen. Danach kannst du ihn ruhig durch den nächsten ersetzen.
• Snapshots altern. Ein Monate alter Snapshot bringt dich auf einen längst überholten Stand zurück – im Zweifel schlimmer als kein Snapshot. Erneuere ihn gezielt vor jeder größeren Aktion; ein frischer Rückkehrpunkt ist mehr wert als ein alter.
• Für echte Sicherheit brauchst du beides. Ergänze den Snapshot um verschlüsselte Off-Site-Backups – wie das geht, zeigt das Tutorial zu Backups mit Restic. Faustregel: Snapshot fürs schnelle Zurück, Restic fürs „mein Server ist weg".

Was bauen wir?

Wir bauen im netcup SCP eine Netzwerk-Firewall aus komponierbaren Policy-Templates: ein Basis-Template (das jeder Server braucht), eins für SSH und eins für Web (HTTP/HTTPS). Diese Bausteine weist du deinem Server nach Bedarf zu – ein Webserver bekommt Basis + SSH + Web, ein Server ohne Website nur Basis + SSH. Am Ende ist eingehend alles gesperrt außer dem, was du bewusst erlaubst.

Ein netcup-spezifisches Detail macht dabei den Unterschied: Bei UDP arbeitet die Firewall zustandslos – weshalb Dienste wie DNS und NTP eine eigene Eingangs-Regel brauchen, sonst klemmen sie plötzlich. Warum das so ist und wie das Basis-Template es löst, zeigt Schritt 2.

Voraussetzungen

• Ein netcup-Server, z. B. dein erster VPS.
• Deine SCP-Zugangsdaten (Kundennummer + SCP-Passwort aus der netcup-Willkommensmail – andere als dein SSH-Login).
• Klarheit über deinen SSH-Port: Standard ist 22. Hast du ihn beim SSH-Absichern verlegt, nimm deinen echten Port – sonst sperrst du dich beim Aktivieren aus.

Schritt für Schritt

Schritt 1: Firewall Policys im SCP öffnen

Melde dich im Server Control Panel an und öffne oben den Menüpunkt Firewall Policys. Hier legst du wiederverwendbare Regelsätze („Policys") an – unabhängig vom einzelnen Server. Erst später weist du sie zu.

Schritt 2: Das Basis-Template bauen

Klick auf Firewall Policy erstellen, vergib den Namen Serverküche Basis und lege über Regel hinzufügen diese vier Regeln an – alle EINGEHEND und ACCEPT:

Zwei Dinge, die hier den Unterschied machen:

• DNS/NTP über den Src Port, nicht den Ziel-Port. Dein Server fragt DNS/NTP an (ausgehend); die Antwort kommt von Port 53 bzw. 123 zurück. Weil UDP zustandslos ist, brauchst du diese Eingangs-Regel – sonst gibt es keine Namensauflösung und keine Zeitsynchronisation, obwohl „alles andere" zu funktionieren scheint.
• ICMPv6 nie vergessen. Ohne Neighbor Discovery bricht IPv6 komplett. ICMP (v4) dazu ist für Ping und die Pfad-MTU-Erkennung sinnvoll. netcups Default-Policy „Ping allow" deckt ICMP zwar schon ab – im Basis-Template steht es bewusst nochmal drin, damit dein Fundament auch dann vollständig bleibt, wenn du die netcup-Defaults einmal entfernst.

Schritt 3: Kleine Bausteine für SSH und Web

Statt eines großen Regel-Monolithen legst du atomare Templates an, die du frei kombinierst. Erstelle nach demselben Muster zwei weitere Policys:

• Serverküche SSH – eine Regel: EINGEHEND, TCP, ACCEPT, Ziel-Port 22.
• Serverküche Web – zwei Regeln: EINGEHEND, TCP, ACCEPT, Ziel-Port 80 und 443.

Der Gewinn: Die Basis-Regeln stehen nur einmal da, nicht in jeder Policy dupliziert. Kommt später ein Dienst dazu (z. B. ein Mailserver oder WireGuard), baust du dafür ein weiteres kleines Template und steckst es dazu – ohne die bestehenden anzufassen.

Schritt 4: Templates dem Server zuweisen

Wechsle zu Server → deinen Server → Reiter „Firewall" und klick auf Firewall Policys editieren. Schieb aus Verfügbare Firewall Policys die passenden nach Ausgewählte: für einen Webserver Serverküche Basis + Serverküche SSH + Serverküche Web.

Bestätige mit Übernehmen und dann Speichern. Prüfe, dass der Schalter „Firewall aktiv" eingeschaltet ist. Die zugewiesenen Regeln erscheinen jetzt in der Liste – zusammen mit netcups Default-Policys (dazu unten mehr).

Wenn es nicht funktioniert

Symptom: Nach dem Aktivieren geht keine Namensauflösung mehr (apt update hängt, ping domain.de scheitert, aber ping 1.1.1.1 geht).

Ursache & Lösung: Die DNS-Antworten werden geblockt. Prüfe im Basis-Template die Regel EINGEHEND UDP ACCEPT, Src-Port 53. Wichtig: Quell-Port, nicht Ziel-Port.

Symptom: Die Uhr driftet, oder TLS-Zertifikate werden wegen falscher Zeit abgelehnt.

Ursache & Lösung: Die NTP-Antworten fehlen. Ergänze EINGEHEND UDP ACCEPT, Src-Port 123.

Symptom: IPv6 funktioniert nicht mehr (v4 schon).

Ursache & Lösung: Es fehlt die ICMPv6-Regel. Ohne Neighbor Discovery kann der Server über IPv6 nicht einmal seinen Nachbarn (Router) finden.

Symptom: Du kommst nach dem Aktivieren nicht mehr per SSH rein.

Ursache & Lösung: Die SSH-Regel fehlt oder nennt den falschen Port. Über die VNC-Konsole (SCP → Bildschirm) kommst du trotzdem auf den Server; korrigiere die Policy und speichere neu. Genau dagegen hilft die „zweite Sitzung offen lassen"-Regel oben.

Symptom: Der Server kann keine E-Mails versenden (Port 25 raus geht nicht).

Ursache & Lösung: Das ist kein Fehler deiner Policy, sondern netcups Default-Policy „netcup Mail block" – sie sperrt ausgehendes SMTP (Port 25/465/587) als Spam-Schutz. Für einen echten Mailversand musst du dieses netcup-Template am Server deaktivieren.

Symptom: Der Server läuft zunächst normal und ist nach ein bis zwei Wochen plötzlich offline.

Ursache & Lösung: Nutzt der Server DHCP, wird die Lease-Erneuerung von der Whitelist geblockt – die DHCP-Antwort kommt von UDP-Quell-Port 67, den keine Regel erlaubt, und UDP ist zustandslos. Ergänze EINGEHEND · UDP · ACCEPT · Src 67 im Basis-Template. Statisch konfigurierte netcup-VPS (der Standard) sind davon nicht betroffen.

Wartung & Backups

• Nach jeder Änderung den Zugang testen. Firewall-Regeln sind der klassische Weg, sich selbst auszusperren. Zweite Sitzung offen halten, neue Verbindung prüfen, erst dann fertig.
• Neue Dienste = neues Template. Brauchst du später einen weiteren Port (Game-Server, WireGuard-VPN über UDP, Datenbank), leg ein kleines eigenes Template an und weise es zusätzlich zu. Die bestehenden Bausteine bleiben unberührt.
• Reihenfolge beachten. netcup wertet die Regeln von oben nach unten aus; die erste zutreffende Regel greift. Bei reinen ACCEPT-Regeln ist das egal – sobald du aber eigene DROP-Regeln einsetzt, achte auf die Reihenfolge relativ zu den ACCEPTs.
• netcups Default-Policys kennen. „netcup Mail block" (ausgehendes SMTP auf Port 25/465/587 gesperrt) und „netcup Ping allow" sind vorgegeben. Über Default Policys wiederherstellen kommst du im Notfall auf einen bekannten, funktionierenden Grundzustand zurück, falls du dich mit eigenen Regeln ausgesperrt hast – zusammen mit der VNC-Konsole dein zweites Sicherheitsnetz.