What are we building?

You get to know the netcup Server Control Panel (SCP) – the web interface to your server – and create a snapshot there: a complete image of your server disk, to which you return in a few minutes if a mishap happens. By the end you know when a snapshot is your rescue – and why it’s still no substitute for a real backup.

Prerequisites

• A netcup server, e.g. your first VPS.
• Your SCP credentials – they are in the netcup welcome email and are different from your SSH login.

Step by step

Step 1: Log into the SCP and find the server

Open servercontrolpanel.de and log in with your SCP credentials. You land in the server list; a click on your server opens the overview with product, status and hardware. At the top you see the tabs through which you control everything – snapshots are under “Media”.

Step 2: Create a snapshot

Go to Media → Snapshots. Under Create snapshot you fill in:

• Name: name it after the why, not the date alone – e.g. before-update-2026-07. That way you later know what it was for.
• Description: one sentence of context (optional, but helpful).
• Disk: usually vda (your system disk).
• Type: here lies the most important decision – see below.

Offline or online snapshot?

• Offline snapshot: the server is briefly shut down for the capture. This guarantees a consistent state – the right choice when databases are running, and when you can afford the brief downtime.
• Online snapshot: capture while running, without downtime. Convenient, but with active writes (e.g. a database mid-write) the image can be inconsistent.

A click on Create starts the process; depending on the amount of data it takes a few minutes. It runs in the background – the creation date and type then appear in the list above once it’s done. Best schedule the brief downtime of an offline snapshot for a quiet time; after that your return point is set and you can tackle the planned change.

Step 3: Restore a snapshot

If something went wrong, you find the snapshot in the list under Snapshots; in the Actions column there’s Restore.

Step 4: The other safety lines in the SCP

The SCP has more than snapshots – good to know for an emergency:

• Display (VNC console): direct screen access to the server, even when SSH refuses – the safety line from the SSH tutorial.
• Rescue system: boots the server into an emergency Linux to repair a broken installation.
• Media → Images / DVD drive: install a different operating system.

When things go wrong

Maintenance & backups

• Snapshot ≠ backup – the most important point. A snapshot lives at netcup, under your account, in one slot and is meant as a momentary snapshot. If the account, the data center or your access fails, it’s gone too. It’s a quick safety net, not an off-site backup.
• Snapshot before every risky action. Before big updates, migrations or delicate config changes: snapshot first, then start. Afterwards you can calmly replace it with the next one.
• Snapshots age. A months-old snapshot brings you back to a long-outdated state – when in doubt, worse than no snapshot. Renew it specifically before every larger action; a fresh return point is worth more than an old one.
• For real safety you need both. Complement the snapshot with encrypted off-site backups – how that works is shown in the tutorial on backups with Restic. Rule of thumb: snapshot for the quick return, Restic for “my server is gone”.

What are we building?

In the netcup SCP we build a network firewall from composable policy templates: a base template (that every server needs), one for SSH, and one for web (HTTP/HTTPS). You assign these building blocks to your server as needed – a web server gets base + SSH + web, a server without a website only base + SSH. By the end, everything inbound is blocked except what you deliberately allow.

A netcup-specific detail makes the difference: for UDP the firewall works statelessly – which is why services like DNS and NTP need their own inbound rule, otherwise they suddenly get stuck. Why that is and how the base template solves it is shown in step 2.

Prerequisites

• A netcup server, e.g. your first VPS.
• Your SCP credentials (customer number + SCP password from the netcup welcome email – different from your SSH login).
• Clarity about your SSH port: the default is 22, and it stays that way when hardening SSH. If you changed it elsewhere, use your real port – otherwise you lock yourself out when activating.

Step by step

Step 1: Open Firewall Policies in the SCP

Log into the Server Control Panel and open the Firewall Policies menu item at the top. Here you create reusable rule sets (“policies”) – independent of the individual server. You only assign them later.

Step 2: Build the base template

Click Create firewall policy, give it the name Serverküche Base and, via Add rule, create these four rules – all INBOUND and ACCEPT:

Two things that make the difference here:

• DNS/NTP via the Src Port, not the destination port. Your server queries DNS/NTP (outbound); the reply comes back from port 53 or 123. Because UDP is stateless, you need this inbound rule – otherwise there’s no name resolution and no time synchronization, even though “everything else” seems to work.
• Never forget ICMPv6. Without Neighbor Discovery, IPv6 breaks completely. ICMP (v4) on top is useful for ping and path MTU discovery. netcup’s default policy “Ping allow” does already cover ICMP – it’s deliberately in the base template again so your foundation stays complete even if you ever remove the netcup defaults.

Step 3: Small building blocks for SSH and web

Instead of one big rule monolith, you create atomic templates that you freely combine. Create two more policies following the same pattern:

• Serverküche SSH – one rule: INBOUND, TCP, ACCEPT, destination port 22.
• Serverküche Web – two rules: INBOUND, TCP, ACCEPT, destination port 80 and 443.

The gain: the base rules appear only once, not duplicated in every policy. If a service is added later (e.g. a mail server or WireGuard), you build another small template for it and plug it in – without touching the existing ones.

Step 4: Assign templates to the server

Switch to Server → your server → “Firewall” tab and click Edit firewall policies. Move the appropriate ones from Available firewall policies to Selected: for a web server Serverküche Base + Serverküche SSH + Serverküche Web.

Confirm with Apply and then Save. Check that the “Firewall active” switch is turned on. The assigned rules now appear in the list – together with netcup’s default policies (more on those below).

Step 5: Ready-made templates for common services

Exactly following the pattern from step 3, here are ready-made templates for the most common self-hosting services. Each is its own small template, all rules are INBOUND and ACCEPT. Build only the ones you really need and plug them, as in step 4, into Serverküche Base + Serverküche SSH.

Mail server (mailcow & co.)

Two things that additionally belong to a mail server:

• Web UI and certificates: mailcow needs 80/443 for the web interface and the Let’s Encrypt retrieval – just assign the Serverküche Web template along with it.
• Enable outbound SMTP: a mail server must be able to deliver on port 25 outbound. netcup blocks that with the default policy “netcup Mail block” – you have to remove it on the server (see “When things go wrong”). And without a correct PTR/reverse-DNS entry your mails land in spam.

WireGuard VPN

51820 is the usual default – use the value from your ListenPort. Only this one inbound rule is needed; the replies to the clients go out outbound.

OpenVPN

The default is UDP 1194. The TCP rule only if you deliberately run OpenVPN over TCP (some additionally put it on TCP 443 to get through restrictive foreign networks) – otherwise leave it out.

Zabbix monitoring

Here it depends on the server’s role:

The Zabbix server additionally needs 80/443 for the web frontend (Serverküche Web). If you run active checks, the agent connects outbound to the server on 10051 – for that, no inbound rule is needed on the agent host.

Checkmk

In the default pull mode, the Checkmk server fetches the data actively – so it connects outbound to 6556 of the agents. Inbound, therefore, only the monitored host needs port 6556. The Checkmk server itself gets by with 80/443 (Serverküche Web); 8000 and 6557 only if you use push mode or distributed monitoring.

Coturn / TURN server (Nextcloud Talk, Matrix)

The large UDP relay range is the default – the actual audio/video streams run over it. You can narrow it in the coturn configuration (min-port/max-port) and then set the firewall rule to the same, smaller range.

Your own DNS server (AdGuard Home, Pi-hole, Unbound)

Careful, this is exactly the opposite direction to the base template: there Src 53 allows the replies to your own DNS queries; here Dst 53 allows the queries of foreign clients to your DNS server. Both exist side by side without problems.

Remote database access (emergency only)

When things go wrong

Maintenance & backups

• Test access after every change. Firewall rules are the classic way to lock yourself out. Keep a second session open, check a new connection, only then finish.
• New services = new template. If you later need another port (game server, WireGuard VPN over UDP, database), create a small template of your own and assign it additionally. The existing building blocks stay untouched.
• Mind the order. netcup evaluates the rules top to bottom; the first matching rule wins. For pure ACCEPT rules that doesn’t matter – but as soon as you use your own DROP rules, watch the order relative to the ACCEPTs.
• Know netcup’s default policies. “netcup Mail block” (outbound SMTP on ports 25/465/587 blocked) and “netcup Ping allow” are predefined. Via Restore default policies you can, in an emergency, get back to a known, working baseline if you locked yourself out with your own rules – together with the VNC console, your second safety net.