netcup SCP-Protokoll lesen: Was es aufzeichnet und was nicht

Wer hat den Server neu gestartet, und wann wurde zuletzt ein Image eingespielt? Das netcup Server Control Panel (SCP) führt dafür im Reiter Protokoll ein eigenes Logbuch. Es ist schnell gefunden, aber was es aufzeichnet und was nicht, steht in der Doku von netcup nur knapp. Diese Anleitung zeigt Schritt für Schritt, wie Sie das Protokoll lesen, was hinter den Einträgen steckt und wo seine Grenzen liegen. Grundlage ist das Protokoll unseres Testservers, eines VPS 500 G12.5, auf dem wir für diese Reihe Images, Snapshots, Apps und Einstellungen verändert haben.

Dies ist Teil 5 der Reihe „netcup Spezial“.

Voraussetzungen

• netcup-VPS oder Root-Server mit Zugang zum SCP, im Test ein VPS 500 G12.5
• Für den Abgleich mit dem System: SSH-Zugang
• Etwa 15 Minuten

Schritt 1: Das Protokoll öffnen

Öffnen Sie im SCP Ihren Server und den Reiter Protokoll. Laut netcup werden dort alle wesentlichen Änderungen an Ihrem System aufgezeichnet. Auf unserem frisch gelieferten Server war die Liste leer, obwohl er bereits einmal gestartet worden war.

Oben links wählen Sie, wie viele Einträge eine Seite zeigt: 10, 25, 50, 100 oder 200. Die Voreinstellung ist 10, ältere Einträge stehen dann auf weiteren Seiten. Unter der Tabelle zeigt das SCP, wie viele Einträge es insgesamt gibt, bei uns am Ende „Zeige 1 bis 19 von 19 Einträgen“.

Verifizieren: Sie sehen die Tabelle mit den Spalten Log-Typ, Datum und Ereignis.

Schritt 2: Die Einträge lesen

Jeder Eintrag hat einen Typ, Datum und Uhrzeit auf die Minute und ein Ereignis. Neue Einträge stehen oben. Bei uns hatten alle Einträge den Typ INFO.

Die Begriffe im Protokoll entsprechen nicht immer den Knöpfen im SCP. Wir haben unsere Aktionen aus den Teilen 1 bis 4 dieser Reihe mit den Einträgen abgeglichen:

Aktion im SCP	Eintrag im Protokoll
Steuerung, Powercycle	Server wurde rebootet
Steuerung, Zurücksetzen	Server wurde resettet
Steuerung, ACPI Herunterfahren	Server ACPI Stop Signal gesendet
Steuerung, Starten	Server wurde gestartet
Einstellungen, UEFI-Boot an	EFI-Stub-Boot starten
Einstellungen, UEFI-Boot aus	EFI-Stub-Boot stoppen
Einstellungen, CPU-Topologie	CPU-Aufbau geändert
Einstellungen, Betriebssystem-Optimierung	OS-Optimierung gesetzt
Medien, Image installieren	Neues Image wurde installiert
Medien, Snapshot erstellen	Snapshot wurde erstellt
Medien, Snapshot exportieren	Snapshot wurde exportiert
Apps, App installieren	App wurde installiert
Apps, App löschen	App wurde gelöscht

Verifizieren: Sie können jeden Eintrag einer Aktion zuordnen, die Sie oder ein Kollege im SCP ausgelöst haben.

Schritt 3: Details aufklappen

Manche Einträge haben links einen Pfeil. Ein Klick klappt eine Zeile mit Details auf.

Bei der Betriebssystem-Optimierung stand dort der gewählte Wert, etwa windows oder linux, bei Apps die Kennung der App wie uptime-kuma-hfgh, bei Snapshots der Name. Besonders aufschlussreich sind die Details bei Image-Installationen.

Beim Image aus dem Katalog nennt das Protokoll den Dateinamen, bei uns app_docker_ubuntu_24.04_gpt-uefi-amd64_20261028.qcow2. Daran lesen Sie ab, welcher Stand eines Images installiert wurde, hier vom 28.10.2026. Bei einem eigenen Image steht der Pfad im Speicher von netcup, mit Ihrer Kundennummer, dem Servernamen und dem Namen des Exports, im Bild durch Beispielwerte ersetzt. Geben Sie Screenshots des Protokolls deshalb nicht ungeprüft weiter.

Verifizieren: Für jede Image-Installation finden Sie den Namen des Images in den Details.

Schritt 4: Was das Protokoll nicht zeigt

Ebenso wichtig ist, was fehlt. Wir haben gezielt Aktionen außerhalb des SCP ausgelöst und danach ins Protokoll geschaut:

• Neustart im Betriebssystem mit systemctl reboot: kein Eintrag.
• Herunterfahren im Betriebssystem mit systemctl poweroff: kein Eintrag, das SCP zeigte danach nur den Status HERUNTERGEFAHREN. Erst unser Start im SCP erschien als „Server wurde gestartet“.
• Gestoppter Dienst SCP Server Satellite aus Teil 3: kein Eintrag.
• Ausschalten durch eine Image-Installation: Nach dem Einspielen eines eigenen Images blieb der Server aus, im Protokoll stand nur „Neues Image wurde installiert“.
• Selbst-Update des Satellite: Die Datei self-update.log aus Teil 3, zuletzt geändert um 20:52, zeigt, dass der Agent ein Image von cr.netcup.net geladen und sich neu gestartet hat. Im Protokoll steht dazu nichts.
• Offline-Snapshot: Der Server fuhr dafür herunter und wieder hoch, im Protokoll stand nur „Snapshot wurde erstellt“.

Ein neuer SSH-Schlüssel unter SSH-Schlüssel tauchte im Protokoll des Servers ebenfalls nicht auf, er gehört zum Konto und nicht zum Server. Kurz gesagt: Das Protokoll zeigt, was über das SCP ausgelöst wurde, nicht, was auf dem Server passiert ist.

Das System selbst kennt diese Vorgänge sehr wohl. last listet Starts und Herunterfahren, auch die aus dem Betriebssystem:

last -x reboot shutdown | head -5

reboot   system boot  6.8.0-147-generi Tue Nov  3 22:35   still running
shutdown system down  6.8.0-147-generi Tue Nov  3 22:34 - 22:35  (00:00)
reboot   system boot  6.8.0-147-generi Tue Nov  3 22:33 - 22:34  (00:00)
shutdown system down  6.8.0-147-generi Tue Nov  3 22:33 - 22:33  (00:00)
reboot   system boot  6.8.0-147-generi Tue Nov  3 22:09 - 22:33  (00:24)

Das Herunterfahren um 22:34 kam aus dem Betriebssystem und fehlt im SCP-Protokoll, das um 22:33 stammte vom ACPI-Signal aus dem SCP. In last sehen beide Einträge gleich aus. Woher ein Herunterfahren kam, zeigt erst der Abgleich mit dem SCP-Protokoll.

Verifizieren: Prüfen Sie bei einem unerwarteten Neustart immer beide Seiten, das SCP-Protokoll und last -x auf dem Server.

Schritt 5: Das Protokoll bei der Fehlersuche nutzen

Ist ein Server unerwartet neu gestartet oder nicht erreichbar, hilft das Protokoll bei der ersten Frage: Kam das aus dem SCP? Steht dort zur passenden Zeit „Server wurde resettet“ oder „Server wurde rebootet“, wurde der Neustart über das SCP ausgelöst. Fehlt ein Eintrag, kam der Neustart nicht über das SCP. Prüfen Sie dann die Logs auf dem Server, etwa auf einen Absturz oder ein automatisches Update mit Neustart. Laut netcup lässt sich über das Protokoll außerdem nachvollziehen, wann eine Störungsmeldung zu Ihrem Server versendet wurde. Eine solche Meldung gab es während unseres Tests nicht.

Bei Ubuntu prüfen Sie den Grund eines Neustarts im System. Ist das Journal nicht dauerhaft gespeichert, wie auf unserem Testserver, zeigt journalctl -b -1 den vorherigen Start nicht an:

Specifying boot ID or boot offset has no effect, no persistent journal was found.

Für die Fehlersuche lohnt es sich deshalb, das Journal dauerhaft zu speichern. Auf unserem Ubuntu reichte dafür der Ordner /var/log/journal:

mkdir -p /var/log/journal
systemctl restart systemd-journald

Gespeichert wurde bei uns erst der folgende Start. Den Start, in dem wir den Ordner angelegt hatten, kannte das Journal danach nicht. Nach dem ersten Neustart zeigte journalctl --list-boots deshalb noch einen Eintrag, nach dem zweiten waren es zwei. Das Ende des vorherigen Starts zeigte dann:

journalctl -b -1 -n 3 --no-pager

systemd-shutdown[1]: Sending SIGTERM to remaining processes...
systemd-journald[293]: Received SIGTERM from PID 1 (systemd-shutdow).
systemd-journald[293]: Journal stopped

Die Zeilen sind um Datum und Hostnamen gekürzt. Wie Sie systematisch nach der Ursache suchen, zeigt unsere Checkliste für nicht erreichbare netcup-Server.

Verifizieren: ls /var/log/journal zeigt einen Unterordner, und journalctl --list-boots zeigt nach zwei Neustarts mehr als einen Eintrag.

Schritt 6: Das Protokoll als Nachweis nutzen

Betreuen Sie Server für Kunden oder arbeiten mehrere Personen im selben SCP, wird das Protokoll zum einfachen Änderungsnachweis. Vor und nach einem Wartungsfenster lohnt ein kurzer Blick: Stehen dort genau die Aktionen, die geplant waren, etwa ein Snapshot vor dem Update und ein Neustart danach? Taucht ein Eintrag auf, den niemand zuordnen kann, ist das ein Grund, die Zugänge zum SCP zu prüfen, siehe unsere Anleitung zur Zwei-Faktor-Anmeldung bei netcup.

Das Protokoll lässt sich im SCP nicht exportieren, wir fanden dafür keinen Knopf. Wer einen Nachweis braucht, macht einen Screenshot oder überträgt die Einträge in sein Ticketsystem. Denken Sie dabei an die Details der Image-Einträge mit Kundennummer aus Schritt 3. Für eigene Notizen genügt oft eine kurze Zeile je Wartung: Datum, Uhrzeit, Aktion im SCP, Ergebnis im System.

Verifizieren: Für Ihre letzte Wartung finden Sie jeden geplanten Schritt im Protokoll wieder.

Typische Fehler

Symptom	Ursache und Lösung
Neustart passiert, aber kein Eintrag	Neustart kam nicht über das SCP. System-Logs prüfen.
Ältere Einträge fehlen	Nur 10 Einträge pro Seite. Seitengröße erhöhen oder weiterblättern.
Eintrag „Server wurde rebootet“ ohne eigenen Neustart	Powercycle über das SCP ausgelöst. Prüfen, wer Zugang zum SCP hat.
Kundennummer und Servername im Screenshot	Details bei eigenen Images enthalten den Speicherpfad. Vor dem Teilen schwärzen.

Häufige Fragen

Sehe ich, wer eine Aktion ausgelöst hat?

In unserem Test zeigte das Protokoll nur Typ, Zeit und Ereignis, keinen Benutzer und keine IP-Adresse.

In welcher Zeitzone stehen die Zeiten?

Im Test passten die Zeiten zur deutschen Ortszeit. Das ACPI-Signal stand im Protokoll um 22:33, und last auf dem Server, der laut journalctl in der Zeitzone CET lief, zeigte das Herunterfahren ebenfalls um 22:33. Die Zeiten sind nur minutengenau.

Fazit

Das Protokoll im SCP ist ein knappes, aber nützliches Logbuch aller Aktionen, die über das SCP laufen. Wer die Begriffe kennt, sieht dort schnell, ob ein Neustart, ein neues Image oder eine geänderte Einstellung aus dem SCP kam. Was im System passiert, zeigt es nicht. Speichern Sie das Journal Ihres Servers deshalb dauerhaft, dann können Sie beide Seiten abgleichen.

Weiterführende Anleitungen und Quellen

• Teil 4: SCP-Einstellungen
• netcup-Server nicht erreichbar: Checkliste
• Das netcup SCP im Überblick
• netcup: Protokoll im SCP