Die wichtigsten Terminal-Befehle für deinen Server

Wer einen eigenen Server betreibt, lebt (zumindest zeitweise) im Terminal. Dieser Artikel ist dein Werkzeugkasten: die Befehle, die du wirklich brauchst – einmal zum Debuggen, wenn der Server plötzlich lahmt, und einmal für die tägliche Arbeit. Kein trockenes Handbuch, sondern die Auswahl, die sich im Alltag bewährt hat.

Was bauen wir?

Kein Setup diesmal, sondern eine praxiserprobte Referenz. Wir gehen zwei Werkzeugkästen durch:

1. Performance debuggen – wenn der Server zäh wird: top, htop, btop, ctop, iotop, nload, ncdu und kill. Damit findest du heraus, was die Ressourcen frisst, und greifst ein.
2. Tägliche Arbeit – die Befehle, die du ständig tippst: ls, cd, nano, wget, curl, dig, tmux, history, sudo, scp, rsync, dd und ssh-agent.

Alle Beispiele sind auf einem echten Debian 13-Server gelaufen; die gezeigten Ausgaben sind real. Die interaktiven Vollbild-Werkzeuge (top, htop, btop, ctop, nload, ncdu) zeigen wir dir zusätzlich im Bild, damit du die Oberfläche wiedererkennst – die kopierbaren Einzelbefehle bleiben bewusst als Text zum Abtippen.

Voraussetzungen

• Ein Server, auf den du dich per SSH einloggen kannst – etwa aus Erste Schritte mit dem netcup-VPS.
• Ein Benutzer mit sudo-Rechten zum Installieren von Paketen.
• Keine Angst vor der Kommandozeile – die legen wir hier gemeinsam ab.

sudo apt update && sudo apt install -y htop btop iotop nload ncdu tmux rsync

Schritt für Schritt

Zuerst der Debugging-Werkzeugkasten – die Befehle für den Moment, in dem der Server klemmt. Danach die Werkzeuge für die tägliche Arbeit.

top und htop: der erste Blick

top ist auf jedem Linux vorhanden und zeigt live die laufenden Prozesse, sortiert nach CPU-Last. Für den schnellen Blick reicht es:

top

Oben siehst du Load-Average, Speicher und die Prozessliste. Die wichtigste – und kryptischste – Zeile ist %Cpu(s). Ihre acht Werte sagen dir, womit die CPU beschäftigt ist:

• us (user) – normale Programme im Userspace (deine Apps, Container-Prozesse).
• sy (system) – der Kernel selbst (Systemaufrufe, Treiber, Netzwerk-Stack).
• ni (nice) – Userspace-Prozesse mit herabgesetzter Priorität (per nice gestartet).
• id (idle) – Leerlauf. Hoher id = viel Luft nach oben, niedriger id = die CPU ist ausgelastet.
• wa (io-wait) – die CPU wartet auf die Festplatte. Dauerhaft hoch heißt: dein Flaschenhals ist die Disk, nicht die Rechenleistung (dann weiter mit iotop, siehe unten).
• hi (hardware interrupts) – Zeit für Hardware-Interrupts (Geräte melden sich).
• si (software interrupts) – Zeit für Software-Interrupts (oft Netzwerk-Verarbeitung).
• st (steal) – nur auf VPS/virtuellen Servern: Rechenzeit, die der Hypervisor deiner VM „gestohlen" hat, weil andere Gäste auf demselben Wirt liefen. Dauerhaft hoher st heißt, der Wirt ist überbucht – ein Grund, den Tarif oder Anbieter zu hinterfragen.

Mit q beendest du die Ansicht. top ist aber spartanisch – der Nachfolger htop ist deutlich lesbarer: farbige Balken pro CPU-Kern, Maus-Bedienung und einfaches Sortieren.

htop

Achte oben auf die CPU-Balken (ein Balken je Kern) und den Mem-Balken. In der Liste sortierst du mit F6 nach einer Spalte (z. B. %MEM), suchst mit F3 einen Prozess und beendest ihn mit F9. Genau hier findest du den Dienst, der gerade alles ausbremst.

btop: der schicke Systemmonitor

btop (Version 1.3.2 im Test) geht noch einen Schritt weiter: CPU, Arbeitsspeicher, Festplatten-I/O und Netzwerk in einem hübschen, mausbedienbaren Dashboard – alles auf einen Blick.

btop

Für den täglichen Gesundheits-Check ist btop unser Favorit, weil du Netzwerk und Disk gleich mitsiehst und nicht mehrere Tools brauchst. Beenden mit q oder Esc.

ctop: Docker-Container live überwachen

Läuft dein Server mit Docker, willst du wissen, welcher Container wie viel zieht. htop zeigt nur Prozesse – ctop zeigt Container. Es ist nicht in den Paketquellen, also holen wir die fertige Datei (Version 0.7.7):

sudo curl -L -o /usr/local/bin/ctop https://github.com/bcicen/ctop/releases/download/v0.7.7/ctop-0.7.7-linux-amd64
sudo chmod +x /usr/local/bin/ctop

Wir laden die Datei bewusst mit vollem Pfad und machen sie ausführbar – kein blindes curl … | bash. Danach startest du es einfach:

ctop

Du bekommst pro Container eine Zeile mit CPU, RAM, Netzwerk und Disk-I/O, live aktualisiert. Mit Enter auf einem Container öffnest du ein Menü zum Stoppen, Neustarten oder Log-Anzeigen – ideal, wenn ein einzelner Dienst Amok läuft.

iotop und nload: Festplatte und Netzwerk

Manchmal ist nicht die CPU das Problem, sondern die Festplatte. iotop zeigt, welcher Prozess gerade liest und schreibt (braucht Root):

sudo iotop

Sortiert nach Schreib-/Leserate erkennst du sofort den I/O-Fresser – oft ein Backup, eine Datenbank oder ein außer Kontrolle geratenes Log. Für das Netzwerk macht nload dasselbe: eingehender und ausgehender Durchsatz in Echtzeit, mit kleinem Graph.

nload

Mit den Pfeiltasten wechselst du zwischen den Netzwerk-Interfaces (oder du gibst das gewünschte direkt an, z. B. nload eth0). Praktisch, um zu prüfen, ob gerade ein großer Upload läuft – oder ob unerwarteter Traffic den Anschluss verstopft.

ncdu: den Speicherfresser finden

Die häufigste Ursache für einen kaputten Server ist eine volle Festplatte. Den groben Überblick gibt df:

df -h /

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda4       251G   11G  230G   5% /

df sagt dir dass es eng wird, aber nicht wo. Das erledigt ncdu – ein interaktiver Verzeichnis-Analyzer, der dir zeigt, welche Ordner den Platz belegen:

sudo ncdu /

ncdu scannt und listet die größten Verzeichnisse oben. Mit den Pfeiltasten navigierst du hinein, mit d löschst du gezielt (Vorsicht!). So findest du in Sekunden das riesige Log-File oder den vergessenen Backup-Ordner.

kill: hängende Prozesse beenden

Hast du in htop oder top die PID (Prozess-ID) des Übeltäters gefunden, beendest du ihn mit kill:

kill 12345

Das schickt ein höfliches „bitte beenden" (Signal TERM), das dem Prozess erlaubt, sauber aufzuräumen. Reagiert er nicht, folgt die harte Variante:

kill -9 12345

-9 (Signal KILL) beendet sofort und gnadenlos. Nutze es erst als letzten Ausweg – der Prozess kann dabei keine Daten mehr sichern. Kennst du nur den Namen, hilft pkill nginx, das alle passenden Prozesse trifft.

Damit endet der Debugging-Kasten. Jetzt die Werkzeuge für die tägliche Arbeit.

ls, cd und nano: navigieren und bearbeiten

Das Grundgerüst jeder Terminal-Sitzung. cd wechselt das Verzeichnis, ls listet den Inhalt. Am nützlichsten ist ls mit Optionen:

ls -lh

-l zeigt Details (Rechte, Besitzer, Größe, Datum), -h macht die Größen lesbar (4.0K statt 4096). Mit ls -la siehst du auch versteckte Dateien (die mit . beginnen). Zum Bearbeiten von Konfigurationsdateien ist nano der einsteigerfreundlichste Editor:

sudo nano /etc/hosts

Unten stehen die Tastenkürzel: Strg+O speichert („WriteOut"), Strg+X beendet. Kein kryptisches vim – genau richtig, um schnell eine Zeile zu ändern.

wget, curl und dig: Daten holen und Netzwerk prüfen

wget lädt Dateien herunter – ideal für Downloads:

wget https://DEINE_QUELLE/datei.tar.gz

curl ist der Schweizer-Taschenmesser für HTTP. Besonders wertvoll: nur die Antwort-Header ansehen, um zu prüfen, was ein Server zurückgibt:

curl -I https://example.com

HTTP/2 200
date: Sat, 18 Jul 2026 09:55:49 GMT
content-type: text/html
server: cloudflare

Der Status 200 heißt „alles ok", 301/302 sind Weiterleitungen, 404 „nicht gefunden". Für DNS-Fragen ist dig das Werkzeug – etwa um zu prüfen, ob deine Domain auf den richtigen Server zeigt:

dig +short example.com A

172.66.147.243
104.20.23.154

+short liefert nur die reine Antwort (die IP-Adresse). Ohne den Schalter siehst du den vollen Bericht inklusive Antwortzeit – unverzichtbar, bevor Traefik ein Zertifikat holen kann (siehe Domain mit Server verbinden).

tmux: die Sitzung, die nie abbricht

Das wichtigste Werkzeug für Fernwartung. Startest du ein langes Kommando (Update, Backup, Kompilieren) über SSH und deine Verbindung bricht ab, stirbt normalerweise auch dein Prozess. tmux löst das: Es hält deine Sitzung auf dem Server am Leben, egal ob du verbunden bist.

tmux

Du landest in einer tmux-Sitzung und arbeitest normal. Bricht die Verbindung ab (oder du schließt bewusst mit Strg+B, dann D – „detach"), läuft alles weiter. Beim nächsten Login hängst du dich wieder dran:

tmux attach

tmux kann noch viel mehr (geteilte Fenster, mehrere Panes). Die Tastenkürzel beginnen alle mit dem „Prefix" Strg+B. Eine kompakte Übersicht aller Kürzel findest du auf dem tmux-Cheatsheet – das lohnt sich zum Ausdrucken.

scp, rsync und dd: kopieren und übertragen

scp kopiert Dateien über SSH – vom lokalen Rechner auf den Server und zurück:

scp datei.txt DEIN_BENUTZER@DEINE_SERVER_IP:/opt/ziel/

Für alles außer einzelnen Dateien ist rsync überlegen: Es überträgt nur Änderungen, kann fortsetzen und synchronisiert ganze Verzeichnisbäume. Teste immer zuerst mit -n (Trockenlauf), bevor du wirklich kopierst:

rsync -avn /quelle/ /ziel/

sending incremental file list
created directory /ziel
./
datei.txt
sub/
sub/mehr.txt

sent 147 bytes  received 63 bytes  420.00 bytes/sec
total size is 11  speedup is 0.05 (DRY RUN)

-a erhält Rechte und Zeitstempel, -v ist gesprächig, -n zeigt nur, was passieren würde. Sieht es gut aus, lässt du das -n weg. rsync funktioniert auch über SSH (rsync -av /quelle/ user@server:/ziel/) und ist damit das Rückgrat vieler Backup-Skripte.

dd schließlich kopiert roh, Block für Block – etwa um ein Boot-Image auf einen USB-Stick zu schreiben. Es ist mächtig und gnadenlos (dazu unten mehr):

sudo dd if=image.iso of=/dev/sdX bs=4M status=progress

history, sudo und ssh-agent: die kleinen Helfer

history zeigt deine zuletzt getippten Befehle mit Nummer – praktisch, um einen langen Befehl von gestern wiederzufinden:

history | grep docker

Mit !123 führst du den Befehl mit Nummer 123 erneut aus, mit Strg+R suchst du interaktiv rückwärts. sudo führt einen einzelnen Befehl mit Administratorrechten aus – immer nur so viel Recht wie nötig:

sudo systemctl restart docker

ssh-agent schließlich merkt sich dein SSH-Schlüssel-Passwort für die Sitzung, damit du es nicht bei jeder Verbindung neu eintippen musst:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Danach loggst du dich ein, ohne die Passphrase erneut einzugeben – bis du dich abmeldest. Mehr zu sicheren SSH-Schlüsseln steht in SSH absichern.

Wenn es nicht funktioniert

Symptom: dd hat die falsche Festplatte überschrieben – Daten weg.

Ursache & Lösung: dd fragt nicht nach und heißt nicht umsonst spöttisch „disk destroyer". Prüfe das Ziel (of=) immer vorher mit lsblk, und verwechsle nie sda mit sdb. Es gibt kein Rückgängig – im Zweifel lieber dreimal lesen.

Symptom: kill -9 hat einen Dienst beendet, aber die Datenbank ist danach beschädigt.

Ursache & Lösung: -9 gibt dem Prozess keine Chance, sauber zu schließen. Nutze immer zuerst kill ohne -9 und gib dem Prozess ein paar Sekunden. Erst wenn er wirklich hängt, folgt die harte Variante.

Symptom: rsync hat viel mehr kopiert (oder gelöscht) als erwartet.

Ursache & Lösung: Der abschließende Schrägstrich entscheidet: rsync -a /quelle/ kopiert den Inhalt von quelle, rsync -a /quelle kopiert den Ordner mit hinein. Und --delete löscht im Ziel alles, was in der Quelle fehlt. Erst mit -n testen, immer.

Symptom: Ein Werkzeug meldet „command not found".

Ursache & Lösung: Das Paket ist nicht installiert. Installiere es (siehe Tipp-Box oben) oder prüfe den Namen. Manche Tools wie iotop brauchen zudem sudo, um überhaupt Daten zu sehen.

Symptom: Nach tmux ist bei erneutem Login „alles weg".

Ursache & Lösung: Du hast eine neue Sitzung gestartet statt dich anzuhängen. tmux ls listet laufende Sitzungen, tmux attach -t 0 hängt dich an die erste. Nur tmux allein erzeugt jedes Mal eine frische.

Wartung & Backups

• Diese Befehle sind dein Backup-Werkzeug. rsync, scp und dd sind das Fundament jeder Sicherungsstrategie. Für echte, verschlüsselte Off-Site-Backups baust du darauf auf – siehe Backups mit Restic, das intern die gleiche Logik nutzt.
• Hilf dir selbst. Jeder Befehl bringt seine Doku mit: man rsync öffnet das Handbuch, rsync --help zeigt die Optionen kompakt. Für knappe Praxisbeispiele lohnt sich das Paket tldr (sudo apt install tldr), das statt seitenlanger man-Pages die drei, vier häufigsten Anwendungsfälle zeigt.
• Bleib aktuell. Halte die Werkzeuge über sudo apt update && sudo apt upgrade frisch; ctop aktualisierst du, indem du die neue Release-Datei erneut herunterlädst. Die Versionen sind bewusst genannt (Stand des Tests) – neuere funktionieren in aller Regel genauso.
• Ehrlich zum Aufwand: Diese Referenz musst du nicht auswendig lernen. Leg sie als Lesezeichen ab und komm wieder, wenn der Server klemmt. Nach ein paar Wochen sitzen die wichtigsten Handgriffe von allein.