Homeserver 101

Referenz 🖥️ Homelab 12 Abschnitte Stand 09.07.2026

Komplette Referenz für Planung, Aufbau und Betrieb: Hardware, OS, Storage, Backup, Netzwerk, Fernzugriff, Sicherheit, Docker und Dienste.

01 / 12Start & Regeln

Was ist ein Homeserver & wofür?

Ein Rechner, der 24/7 zuhause läuft und Dienste für dich bereitstellt – statt Cloud-Abos, mit voller Kontrolle über die eigenen Daten.

🎬 Medien
Eigenes Netflix: Filme, Serien, Musik, Hörbücher streamen.
  • Jellyfin, Plex, Navidrome
☁️ Cloud-Ersatz
Dateien, Fotos und Kalender selbst hosten.
  • Nextcloud, Immich, Syncthing
🛡️ Netzwerk
Werbe- und Tracker-Blocker für alle Geräte, lokales DNS.
  • Pi-hole, AdGuard Home
🏠 Smart Home
Zentrale für Automatisierung, lokal statt Hersteller-Cloud.
  • Home Assistant
💾 Backup-Ziel
Zentrale Sicherung aller PCs, Handys und Dokumente.
  • Restic, Paperless-ngx, PBS
🧪 Lernen & Basteln
Linux, Docker, Netzwerke, Virtualisierung in echt lernen.
  • VMs, LXC, Testumgebungen

Die 10 Grundregeln

Zweck vor Kauf. Erst festlegen, was der Server tun soll – daraus ergibt sich die Hardware, nicht umgekehrt.
Klein anfangen. Ein Gerät, ein Dienst, dann erweitern. Kein 10-Dienste-Big-Bang am ersten Wochenende.
RAID ist kein Backup. RAID schützt vor Plattenausfall, nicht vor Löschen, Ransomware, Blitz oder Diebstahl.
Backup vor Daten. Erst wenn die 3-2-1-Sicherung steht, kommen wichtige Daten auf den Server.
Nichts direkt ins Internet. Fernzugriff über VPN (Tailscale/WireGuard). Port-Forwarding nur bewusst, gehärtet und minimal.
Updates sind Pflicht. Ein ungepatchter Server im Netz ist ein offenes Fenster. Feste Update-Routine einplanen.
Dokumentieren. IPs, Ports, Zugänge, Konfigs notieren (Passwortmanager + Git für Compose-Dateien). Zukunfts-Ich dankt.
Restore testen. Ein Backup, das nie wiederhergestellt wurde, ist Hoffnung – kein Backup.
Eine Änderung nach der anderen. Vor Änderungen Snapshot/Backup, danach prüfen. Nie zwei Baustellen gleichzeitig.
Strom zählt. Das Gerät läuft 24/7 – Idle-Verbrauch ist wichtiger als Peak-Leistung. Faustregel: 1 W ≈ 3 €/Jahr.

Standard-Vorgehen: von 0 zum laufenden Server

Zweck & Budget definieren. Welche Dienste? Wie viele Nutzer? Wie viel Speicher in 3 Jahren?
Hardware wählen. Siehe Tab „Hardware“ – für die meisten: gebrauchter Mini-PC oder N100-Box.
OS installieren. Siehe Tab „Betriebssystem“ – Empfehlung: Proxmox (flexibel) oder Debian + Docker (schlank).
Grund-Setup. Updates, feste IP (DHCP-Reservierung), SSH-Key, eigener Admin-User, Zeitzone/NTP.
Storage einrichten. Platten, Dateisystem, ggf. Pool/RAID, SMART-Monitoring aktivieren.
Docker + erster Dienst. Etwas Unkritisches zum Üben, z. B. Uptime Kuma oder ein Dashboard.
Backup einrichten & Restore testen. Erst jetzt wichtige Daten auf den Server geben.
Monitoring & Benachrichtigungen. Uptime Kuma, SMART-Alerts, Backup-Reports (z. B. via ntfy).
Weitere Dienste, einer nach dem anderen. Jeweils: Compose anlegen → testen → dokumentieren → ins Backup aufnehmen.
Fernzugriff zuletzt. Tailscale/WireGuard einrichten – erst wenn Basis, Backup und Sicherheit stehen.
Faustregel Reihenfolge: Stabilität → Sicherheit → Backup → Komfort. Neue Features immer erst, wenn die Ebene darunter steht.

02 / 12Hardware

Hardware-Optionen im Vergleich

OptionPreis (ca.)Idle-VerbrauchLeistungErweiterbarGeeignet für
Raspberry Pi 580–130 €3–6 Wniedrigkaum (USB/NVMe-HAT)Pi-hole, Home Assistant, kleine Dienste
Mini-PC (Intel N100/N150)150–250 €6–12 Wmittelbegrenzt (1× NVMe, 1× SATA)Allround-Einstieg, Docker, Jellyfin
Gebrauchter Office-Mini (Dell/Lenovo/HP „1L“)80–200 €8–15 Wmittel–hochbegrenztPreis-Leistungs-Tipp, Proxmox-Einstieg
Fertig-NAS (Synology/QNAP/Ugreen)300–800 € + Platten15–40 WmittelPlatten ja, sonst wenig„Soll einfach laufen“, viel Storage
Eigenbau (ITX/ATX)400–1000 €20–60 Wfrei wählbarvoll (Platten, PCIe, ECC)Viel Storage + Leistung, ZFS, Zukunftssicherheit
Einsteiger-Empfehlung: gebrauchter 1-Liter-Mini-PC oder N100-Box. Günstig, sparsam, leise – und stark genug für 10+ Container. Aufrüsten kann man später immer noch.

Worauf beim Kauf achten

CPU
Effizienz schlägt Kerne.
  • Intel mit QuickSync (iGPU) = Hardware-Transcoding für Jellyfin/Plex/Immich
  • N100 reicht für die meisten Setups
  • Viele VMs/Nutzer → i5/Ryzen ab 6 Kernen
RAM
Der häufigste Engpass.
  • Nur Docker: 8 GB ok, 16 GB komfortabel
  • Proxmox/VMs: 16–32 GB
  • ZFS mag RAM (Faustregel: ab 8 GB + 1 GB je TB ist komfortabel)
  • ECC: nice-to-have für ZFS/Datengrab, kein Muss im Hobby
Storage-Anschlüsse
Bestimmt die Ausbaufähigkeit.
  • NVMe für OS + Container (schnell)
  • SATA-Ports / HBA für Daten-HDDs
  • USB-Platten nur für Backups, nicht für Pools/RAID
Netzwerk
Kabel ist Pflicht.
  • 1 GbE reicht für fast alles (≈ 110 MB/s)
  • 2,5 GbE = sinnvolles Future-Proofing
  • Kein WLAN für den Server – immer LAN
Idle-Verbrauch
Die wichtigste Zahl bei 24/7.
  • 1 W Dauerlast ≈ 8,76 kWh/Jahr ≈ 3 €/Jahr (bei 0,35 €/kWh)
  • Alter Gaming-PC (60 W idle) ≈ 180 €/Jahr
  • HDDs: je ca. 3–8 W, Spindown abwägen
USV (unterbrechungsfreie Stromversorgung)
Schutz vor Stromausfall.
  • Sauberes Herunterfahren schützt Dateisystem & Datenbanken
  • Besonders wichtig bei ZFS-Pools und Nextcloud/Immich (DB!)
  • Anbindung per USB + NUT oder apcupsd → Auto-Shutdown

Standort & Aufstellung

  • Kühl, trocken, staubarm, mit Luftzirkulation – nicht im geschlossenen Schrank ohne Lüftung
  • In Router-/Switch-Nähe (LAN-Kabel), Steckdosenleiste mit Überspannungsschutz
  • Lautstärke bedenken: HDDs klackern – Schlafzimmer ist ein schlechter Ort
  • BIOS: „Restore on AC Power Loss“ auf Power On → Server startet nach Stromausfall selbst

Stromkosten-Rechner

03 / 12Betriebssystem

Betriebssystem wählen

SystemTypSchwierigkeitKostenStark beiBedenken
Proxmox VEHypervisor (VMs + LXC)mittelkostenlosFlexibilität, Snapshots, Backups, alles auf einem GerätStorage/NAS-Funktionen nur per VM/Umweg
Debian/Ubuntu Server + DockerPures LinuxmittelkostenlosSchlank, maximale Kontrolle, wenig OverheadAlles selbst bauen (Backup, Monitoring)
TrueNAS ScaleNAS-OS (ZFS-first)mittelkostenlosStorage, ZFS, Freigaben, SnapshotsApps/Container weniger flexibel als pures Docker
UnraidNAS-OSleichtLizenz (ab ~50 $)Gemischte Plattengrößen, einfache UI, große CommunityKostenpflichtig, Parity statt klassischem RAID
OpenMediaVaultNAS-OS (Debian-Basis)leichtkostenlosLeichtes NAS auf schwacher Hardware (auch Pi)Weniger poliert, Docker via Plugin
Synology DSM / QNAP QTSHersteller-OSleichtim NAS enthalten„Einschalten und läuft“, gute AppsGebunden an Hersteller-Hardware, weniger Lerneffekt
Empfehlung: Ein Gerät für alles → Proxmox (unten Docker-VM/LXC, daneben Test-VMs, eingebaute Backups). Nur Container, so einfach wie möglich → Debian + Docker. Storage im Mittelpunkt → TrueNAS Scale oder Unraid.

VM vs. LXC vs. Docker

TechnikIsolationOverheadWofür
VM (virtuelle Maschine)voll (eigener Kernel)hoch (RAM fest reserviert)Fremde OS, Home Assistant OS, unsichere Experimente, Firewall
LXC (System-Container)mittel (teilt Kernel)sehr geringLeichte Linux-Dienste unter Proxmox (Pi-hole, kleine Tools)
Docker (App-Container)App-EbenegeringStandard für Self-Hosting-Apps – fast jede App liefert ein Image
Bewährtes Proxmox-Muster: Eine Debian-VM als „Docker-Host“ für alle App-Container + einzelne LXC/VMs für Sonderfälle. Docker direkt im LXC geht, macht aber gern Probleme bei Updates.

Grund-Setup direkt nach der Installation

  • System-Updates einspielen (apt update && apt full-upgrade)
  • Feste IP vergeben – am besten als DHCP-Reservierung im Router (überlebt Neuinstallationen)
  • Eigenen Admin-User anlegen, sudo statt root-Arbeit
  • SSH-Key hinterlegen, danach Passwort-Login und Root-Login deaktivieren
  • Zeitzone + NTP prüfen (timedatectl) – wichtig für Logs, Zertifikate, Backups
  • Hostname sinnvoll setzen (z. B. server01)
  • Firewall aktivieren (ufw: nur SSH + benötigte Ports erlauben)
  • fail2ban installieren (blockt Brute-Force auf SSH)
  • Automatische Sicherheitsupdates: unattended-upgrades (nur Security-Repo)
  • SMART-Monitoring aktivieren (smartd) + Mail/Push bei Fehlern

04 / 12Storage & RAID

Platten richtig wählen

SSD (NVMe/SATA)
Für OS, Container, Datenbanken, Fotos-Cache.
  • Schnell, lautlos, sparsam
  • Für Dauerbetrieb: auf TBW-Wert achten
  • Proxmox/ZFS schreibt viel → billige QLC-SSDs meiden
HDD (3,5")
Für Massendaten: Medien, Backups, Archiv.
  • NAS-Serien nehmen: WD Red Plus, Seagate IronWolf, Toshiba N300
  • CMR statt SMR – SMR-Platten sind Gift für RAID/ZFS
  • Vor Einsatz Langtest: smartctl -t long
Aufteilung (bewährt)
Trennung von System und Daten.
  • NVMe: OS + Docker + AppData
  • HDDs: Medien, Dateien, Fotos-Originale
  • Externe/2. Platte: Backups

Dateisysteme

DateisystemSnapshotsChecksummen (Bitrot-Schutz)RAID integriertWofür
ext4– (mdadm separat)Einfach & robust; Standard für Einzelplatten und OS
ZFS✓ (Mirror/RAIDZ)Datenintegrität, Pools, Replikation; Proxmox & TrueNAS nativ
Btrfsteilweise (RAID5/6 unreif)Snapshots auf Einzelplatten/Mirror; Synology nutzt es
XFSGroße Dateien/Medien, Unraid-Standard

RAID-Level Überblick

LevelPlatten min.Nutzbare KapazitätVerkraftet AusfallHinweis
Keins (Einzelplatte)1100 %0Völlig ok, wenn Backup existiert
RAID 0 (Stripe)2100 %0 – eine weg, alles wegFür Homeserver praktisch nie sinnvoll
RAID 1 / ZFS Mirror250 %1Einfach, schnell wiederhergestellt – Standard-Tipp
RAID 5 / RAIDZ13(n−1)/n1Bei großen Platten (>8 TB) riskant beim Rebuild
RAID 6 / RAIDZ24(n−2)/n2Guter Kompromiss bei 4+ großen Platten
RAID 10450 %1 je MirrorSchnell, teuer in Kapazität
Unraid Parity2n−1 (bzw. n−2)1–2Gemischte Plattengrößen möglich, Platten einzeln lesbar
RAID ist kein Backup. RAID hält den Betrieb bei Plattenausfall am Laufen – mehr nicht. Gegen versehentliches Löschen, Ransomware, Softwarefehler, Überspannung, Feuer und Diebstahl hilft nur ein Backup (siehe Tab „Backup“).

Laufende Pflege

  • SMART überwachen: smartd oder Scrutiny (Web-UI); auf Reallocated Sectors, Pending Sectors, Temperatur achten
  • ZFS/Btrfs Scrub: monatlich automatisch laufen lassen – findet stille Datenfehler
  • Füllstand: Pools unter 80–85 % halten (Performance + ZFS-Gesundheit)
  • Plattenausfall-Plan: Ersatzplatte-Modell notieren; bei RAID: defekte Platte identifizieren (Seriennummer!), tauschen, Rebuild abwarten, erst dann entwarnen
  • Neue Platten testen bevor Daten drauf gehen: SMART-Langtest + einmal vollschreiben (z. B. badblocks)

05 / 12Backup

Die 3-2-1-Regel

3 Kopien
Original + 2 Sicherungen.
  • Beispiel: Server + Backup-Platte + Cloud
2 Medien/Geräte
Nicht alles auf demselben Gerät.
  • Interne HDD zählt nicht als Backup ihrer Nachbarplatte im selben Pool
1 Kopie außer Haus
Gegen Feuer, Blitz, Diebstahl.
  • Verschlüsselte Cloud (Backblaze B2, Hetzner Storage Box) oder Platte bei Familie/Arbeit

Was sichern? (Prioritäten)

PrioritätDatenBeispieleStrategie
UnersetzlichPersönliche DatenFotos, Dokumente, Passwort-Tresor (Vaultwarden!), Paperless-ArchivVoll 3-2-1, verschlüsselt, täglich/automatisch
AufwendigKonfigurationDocker-Compose, .env, AppData, Home-Assistant-Config, VM-BackupsTäglich automatisch, mind. 2 Ziele
ErsetzbarWiederbeschaffbaresMedien, ISOs, DownloadsOptional; oft reicht 1 Kopie oder gar keine

Snapshots vs. Backup

Snapshot (ZFS/Btrfs/Proxmox)

  • Momentaufnahme in Sekunden, ideal vor Updates/Änderungen
  • Schneller Rollback
  • Liegt auf demselben System → schützt nicht bei Hardware-Defekt

Snapshot allein reicht nicht

  • Kein Schutz bei Plattendefekt, Pool-Verlust, Diebstahl
  • Ransomware mit Root-Zugriff kann Snapshots löschen
  • → Immer zusätzlich echtes Backup auf anderes Gerät

Werkzeuge

ToolTypStärkenTypischer Einsatz
ResticCLI, dedupliziert + verschlüsseltSchnell, viele Backends (lokal, SFTP, S3/B2), restic checkStandard-Tipp für Datei-Backups → Cloud & Platte
Borg / BorgmaticCLI, dedupliziert + verschlüsseltSehr effizient, ausgereiftBackups auf eigenes Ziel (SSH/BorgBase)
Proxmox Backup ServerServer-AnwendungVM/LXC-Backups inkrementell + verifiziertProxmox-Setups, gern auf Zweitgerät
DuplicatiWeb-UIEinfach klickbarEinsteiger; Restore regelmäßig testen
rsyncCLI, 1:1-KopieSimpel, überall vorhandenMedien spiegeln; keine Versionierung!
SyncthingSync (kein Backup!)Geräte-Sync in EchtzeitVerteilen von Daten – löscht auch synchron ⚠️
Sync ≠ Backup: Nextcloud/Syncthing spiegeln auch das Löschen und Verschlüsseln (Ransomware) sofort auf alle Geräte. Backups brauchen Versionierung und am besten ein Ziel, das der Server nicht überschreiben kann (Pull-Backup, Append-only oder Offline-Platte).

Beispiel-Backup-Plan (bewährt)

WannWasWohinWomit
täglich, nachtsAppData + Configs + Dokumente/Fotoszweite interne/USB-PlatteRestic (verschlüsselt, versioniert)
täglich, nachtsUnersetzliches (Fotos, Doks, Tresor)Cloud (B2/Storage Box)Restic, gleicher Job, zweites Repo
wöchentlichVMs/LXC komplettPBS oder NASProxmox-Backup
monatlichRestore-Stichprobe: 1 Datei + 1 Ordner zurückholenHand + Kalender-Erinnerung
  • Benachrichtigung einrichten: Backup-Job meldet Erfolg/Fehler (ntfy, E-Mail, Gotify) – stille Fehler sind der Klassiker
  • Aufbewahrung (Retention): z. B. 7 täglich, 4 wöchentlich, 6 monatlich – schützt auch vor „Fehler erst spät bemerkt“
  • Verschlüsselungs-Passwort des Backups außerhalb des Servers sichern (Passwortmanager + Zettel) – ohne ist alles weg

06 / 12Netzwerk

Grund-Setup im Heimnetz

  • Feste Adresse: DHCP-Reservierung im Router (z. B. FritzBox: „immer die gleiche IP zuweisen“) – besser als statische IP am Gerät
  • Lokale Namen: statt IPs Namen nutzen – Router-DNS (server.fritz.box), eigenes DNS (Pi-hole „Local DNS Records“) oder Tailscale MagicDNS
  • IP-Plan notieren: welche Geräte welche Adresse haben, Bereich für Reservierungen festlegen
  • LAN statt WLAN für Server – stabiler, schneller, geringere Latenz

Ports verstehen

PortDienstBemerkung
22SSHFernwartung; nur mit Key, nie ins Internet forwarden
53DNSPi-hole/AdGuard; Konflikt mit systemd-resolved beachten
80 / 443HTTP / HTTPSGehören dem Reverse Proxy – Apps dahinter
445SMB (Dateifreigabe)Nur im LAN/VPN – niemals ins Internet
51820WireGuard (UDP)Der einzige Port, den man guten Gewissens öffnen kann
8080, 8443, 3000 …App-WebinterfacesTypische Docker-Ports; per Reverse Proxy bündeln
Ein Port = ein Dienst. Belegte Ports checken mit ss -tulpn. Bei Docker Konflikte über die linke Seite des Mappings lösen: 8081:80 statt 8080:80.

Reverse Proxy

Ein Dienst, der vor allen Web-Apps steht: jellyfin.home.example.de → intern Port 8096. Vorteile: ein Einstiegspunkt, überall HTTPS, keine Portnummern merken.

ProxyBedienungStärkenFür wen
Nginx Proxy ManagerWeb-UIKlickbar, Let's-Encrypt integriertEinsteiger-Standard
CaddyConfig-Datei (sehr kurz)Automatisches HTTPS, schlankWer Textconfig mag
TraefikDocker-LabelsErkennt Container automatischFortgeschrittene, viele Container
HTTPS intern ohne offene Ports: eigene Domain + Let's-Encrypt DNS-Challenge (Wildcard-Zertifikat). So gibt es gültige Zertifikate für interne Dienste, ohne dass etwas aus dem Internet erreichbar ist.

Weiterführend

VLAN / Netz-Trennung
Getrennte Netze für IoT, Gäste, Server.
  • Braucht VLAN-fähigen Router/Switch (z. B. OpenWrt, UniFi, OPNsense)
  • IoT-Geräte raus aus dem Hauptnetz = großer Sicherheitsgewinn
  • Nice-to-have, kein Pflichtprogramm am Anfang
DynDNS
Heim-IP wechselt – DynDNS gibt ihr einen festen Namen.
  • Anbieter: deSEC, DuckDNS, Cloudflare-API, Router-integriert
  • Nur nötig für selbst gehostetes VPN/Portfreigaben
IPv6 / CGNAT / DS-Lite
Stolperfalle bei Kabel-/Glasfaser-Anschlüssen.
  • Ohne öffentliche IPv4 (DS-Lite/CGNAT) funktioniert klassisches Port-Forwarding nicht
  • Lösung: Tailscale/ZeroTier (lochen durch NAT) oder Cloudflare Tunnel

07 / 12Fernzugriff

Fernzugriff: die Rangfolge

Grundsatz: So wenig wie möglich öffentlich erreichbar machen. Für privaten Zugriff reicht fast immer ein VPN.

#MethodeSicherheitAufwandOffener Port?Bewertung
1Tailscale / ZeroTier / NetBird (Overlay-VPN)hochminimalneinErste Wahl: App installieren, einloggen, fertig; funktioniert auch hinter CGNAT
2WireGuard selbst gehostet (Server/Router, z. B. FritzBox)hochmittel1× UDPOhne Drittanbieter; braucht öffentliche IP + DynDNS
3Cloudflare TunnelhochgeringneinFür einzelne Web-Apps, die wirklich öffentlich sein sollen; Traffic läuft über Cloudflare, Video-Streaming per ToS unerwünscht
4Port-Forwarding + Reverse Proxynur gehärtethoch80/443Nur wenn öffentlich nötig (z. B. Nextcloud für Familie): 2FA, fail2ban/CrowdSec, Updates strikt, ggf. Geo-Block
Direkt exponierte Dienste (SMB, RDP, SSH-Passwort, Datenbanken, Docker-API)nieNiemals. Werden innerhalb von Minuten gescannt und angegriffen
Standard-Empfehlung: Tailscale auf Server + Handy + Laptop. Damit erreichst du alles von unterwegs, als wärst du zuhause – ohne einen einzigen offenen Port. „Subnet Router“-Funktion aktivieren, dann ist das ganze Heimnetz erreichbar.

Wenn doch etwas öffentlich sein muss

  • Nur über Reverse Proxy mit HTTPS (Let's Encrypt), nie App-Port direkt forwarden
  • 2FA in der App aktivieren – oder Login davor schalten (Authelia/Authentik)
  • fail2ban oder CrowdSec auf die Proxy-Logs ansetzen
  • App aktuell halten – öffentliche Dienste haben Update-Priorität
  • Eigenes Docker-Netz / VLAN: öffentlicher Dienst kommt nicht an interne Dienste
  • Monitoring: Login-Fehlversuche & ungewöhnlichen Traffic im Blick behalten
  • Regelmäßig fragen: „Muss das noch öffentlich sein?“ – sonst zurückbauen
Vaultwarden, Paperless, Home Assistant & Co. enthalten dein digitales Leben. Solche Dienste möglichst nur per VPN erreichbar machen – nicht öffentlich, auch wenn es bequemer wäre.

08 / 12Sicherheit

Die goldenen Sicherheitsregeln

Angriffsfläche klein halten
  • Nur installieren, was genutzt wird; Ungenutztes entfernen
  • Keine offenen Ports „auf Verdacht“
  • Standard: alles nur im LAN/VPN erreichbar
Updates
  • OS: Security-Updates automatisch (unattended-upgrades)
  • Container: regelmäßig, aber bewusst (siehe Docker-Tab)
  • Öffentlich erreichbare Dienste: sofort patchen
Zugänge
  • Passwortmanager, jedes Passwort einmalig & lang
  • 2FA überall, wo möglich (Admin-UIs zuerst)
  • Standard-Passwörter (admin/admin) sofort ändern
SSH härten
  • Nur Key-Login: PasswordAuthentication no
  • PermitRootLogin no, Zugriff per sudo
  • fail2ban; SSH nie ins Internet forwarden
Least Privilege
  • Dienste laufen als eigener User (PUID/PGID), nicht als root
  • Kein privileged: true ohne Grund
  • Freigaben: nur nötige Ordner, nur nötige Rechte
Ransomware-Resilienz
  • Versionierte Backups, die der Server nicht löschen kann (Pull/append-only/offline)
  • Backup-Ziel mit anderen Zugangsdaten
  • Snapshots zusätzlich für schnellen Rollback

Häufige Fehler und was stattdessen

FehlerRisikoBesser so
Port-Forward direkt auf App (Jellyfin:8096, HA:8123)Bots scannen & exploiten bekannte Ports in MinutenVPN; wenn öffentlich: Reverse Proxy + HTTPS + 2FA
SSH mit Passwort erreichbarBrute-Force rund um die UhrSSH-Keys, Passwort-Login aus, fail2ban
Docker-Socket in Container mounten (Watchtower & Co. unbedacht)Socket = Root auf dem HostNur bewusst; Alternativen: manuelle Updates, Socket-Proxy
Passwörter/Keys in compose.yaml in GitSecrets landen öffentlich/kopiert.env-Datei (in .gitignore) oder Docker Secrets
„Später mache ich Backup“Totalverlust bei erstem Defekt/FehlgriffBackup gehört zum Setup, nicht zur Kür
Alles im selben Netz mit Billig-IoTKompromittierte Kamera erreicht den ServerIoT ins Gastnetz/VLAN
UPnP am Router aktivGeräte öffnen selbstständig PortsUPnP deaktivieren, Freigaben nur manuell
Ein Admin-Passwort für allesEin Leak = alles offenPasswortmanager, einmalige Passwörter, 2FA

Update-Strategie (Standard-Vorgehen)

Vorher sichern: Snapshot (Proxmox/ZFS) oder frisches Backup der App-Daten.
Changelog überfliegen: Major-Versionen (z. B. Nextcloud 28→29, Immich) haben oft Breaking Changes.
Update einspielen: OS per apt; Container per docker compose pull && docker compose up -d.
Funktion prüfen: App öffnen, Logs checken (docker compose logs -f).
Bei Problemen: Rollback auf Snapshot bzw. altes Image-Tag – deshalb Versions-Tags statt nur latest.

Sicherheits-Checkliste (regelmäßig durchgehen)

  • Welche Ports sind am Router offen? (Router-UI prüfen – sollte: keiner oder nur VPN)
  • Läuft überall die aktuelle Version? (Dashboard/Release-Feeds)
  • 2FA auf allen Admin-Zugängen aktiv?
  • fail2ban/CrowdSec aktiv und Logs unauffällig?
  • Backups grün + letzter Restore-Test < 3 Monate?
  • Gibt es Dienste/User/Freigaben, die keiner mehr braucht? → entfernen

09 / 12Docker

Konzepte in 30 Sekunden

Image
Bauplan/Vorlage einer App (z. B. jellyfin/jellyfin:10.9). Unveränderlich, wird aus Registry geladen.
Container
Laufende Instanz eines Images. Wegwerfbar – alles Wichtige liegt in Volumes/Mounts.
Volume / Bind Mount
Persistente Daten. Bind Mount (./data:/config) = Ordner auf dem Host, leicht zu sichern – Standard im Homelab.
Netzwerk
Container im selben Docker-Netz erreichen sich per Namen (http://jellyfin:8096) – ohne Port-Freigabe.

Compose als Standard

Jeder Dienst als compose.yaml: deklarativ, versionierbar, selbstdokumentierend. Nie Container per Hand mit langen docker run-Befehlen starten.

Bewährte Ordnerstruktur

/opt/stacks/
├── jellyfin/
│   ├── compose.yaml
│   ├── .env            ← Secrets, nicht in Git
│   └── config/         ← AppData (Bind Mount)
├── immich/
│   ├── compose.yaml
│   └── ...
└── proxy/
    └── compose.yaml

Beispiel compose.yaml

services:
  jellyfin:
    image: jellyfin/jellyfin:10.9.11   # Version pinnen statt :latest
    restart: unless-stopped
    ports:
      - "8096:8096"
    volumes:
      - ./config:/config
      - /srv/medien:/media:ro          # Medien nur lesend
    environment:
      - TZ=Europe/Berlin
    devices:
      - /dev/dri:/dev/dri              # iGPU für Hardware-Transcoding

Wichtige Befehle

BefehlMacht
docker compose up -dStack starten / Änderungen anwenden
docker compose pull && docker compose up -dUpdate: neue Images ziehen + neu erstellen
docker compose logs -f [dienst]Logs live ansehen (erster Schritt bei Problemen)
docker compose downStack stoppen und Container entfernen (Daten bleiben)
docker psLaufende Container + Status/Ports
docker exec -it <name> bashShell im Container öffnen
docker system df / docker image prune -aSpeicherverbrauch anzeigen / alte Images aufräumen
docker statsCPU/RAM-Verbrauch je Container live

Best Practices

  • Versionen pinnen: image: app:1.2 statt :latest → Updates werden bewusst und Rollback ist möglich
  • restart: unless-stopped überall – Container starten nach Reboot automatisch
  • PUID/PGID setzen (linuxserver.io-Images): Container schreibt Dateien als dein User, nicht als root
  • Ports sparsam mappen: nur veröffentlichen, was gebraucht wird; interne Kommunikation über Docker-Netze; hinter Reverse Proxy reicht oft gar kein Port-Mapping
  • Secrets in .env, nicht in die Compose-Datei; Compose-Dateien in Git sichern
  • Auto-Updates (Watchtower) mit Vorsicht: praktisch für Unkritisches, gefährlich für DB-Apps (Immich, Nextcloud) – dort manuell mit Changelog. Sanfte Alternative: Diun (benachrichtigt nur)
  • Verwaltung per UI gefällig? Dockge (compose-treu, empfehlenswert) oder Portainer

10 / 12Dienste

Beliebte Dienste nach Kategorie

Bewährte, aktiv gepflegte Projekte. Empfehlung = guter Standard-Startpunkt der Kategorie.

📊 Monitoring & Dashboard
  • Uptime Kuma Empfehlung – prüft, ob Dienste laufen; alarmiert per Push
  • Homepage / Homarr – Startseite mit allen Diensten
  • Beszel / Netdata – CPU, RAM, Disk, Temperatur
  • Scrutiny – SMART-Werte aller Platten im Blick
  • Dozzle – Container-Logs im Browser
🛡️ DNS & Adblock
  • AdGuard Home Empfehlung – Adblock + DNS, moderne UI
  • Pi-hole – der Klassiker, riesige Community
  • Tipp: als DNS im Router eintragen → wirkt für alle Geräte; zweite Instanz = Ausfallsicherheit
🎬 Medien
  • Jellyfin Empfehlung – Filme/Serien/Musik, komplett frei
  • Plex – polierter, aber Konto/Abo-Modell
  • Navidrome – Musik; Audiobookshelf – Hörbücher/Podcasts
  • iGPU durchreichen für Transcoding (QuickSync)
📷 Fotos
  • Immich Empfehlung – Google-Photos-Ersatz: Auto-Upload, Gesichter, Karte
  • Braucht ordentlich RAM (ML-Features) + diszipliniertes Backup (DB + Originale)
  • PhotoPrism – Alternative ohne Multi-User-Fokus
☁️ Dateien & Sync
  • Nextcloud – Cloud-Komplettpaket (Dateien, Kalender, Kontakte)
  • Syncthing Empfehlung – schlanker Geräte-Sync ohne Server-Konto
  • Samba/SMB – klassische Netzwerkfreigabe für PCs
  • FileBrowser – simples Web-Dateimanagement
📄 Dokumente
  • Paperless-ngx Empfehlung – Dokumente scannen, OCR, verschlagworten, wiederfinden
  • Papierkram-Gamechanger; Export/Backup einplanen
  • Stirling-PDF – PDF-Werkzeugkasten im Browser
🔑 Passwörter
  • Vaultwarden – Bitwarden-Server, alle Bitwarden-Apps kompatibel
  • Kritisch: nur per VPN erreichbar machen, Backups mehrfach + getestet
  • Notfallzugriff bedenken: Export/Notfallblatt im Safe
🏠 Smart Home
  • Home Assistant Empfehlung – Standard für lokale Automatisierung
  • Am rundesten als HAOS-VM (Proxmox) statt Container (Add-ons!)
  • Zigbee/Thread per USB-Stick (in VM durchreichen)
🔧 Sonstiges
  • Gitea/Forgejo – eigener Git-Server (Compose-Dateien!)
  • ntfy / Gotify – Push-Benachrichtigungen vom Server aufs Handy
  • *arr-Stack (Sonarr/Radarr) – Medienverwaltung
  • Frigate – Kamera-NVR mit Objekterkennung

Sinnvolle Startreihenfolge

Uptime Kuma + ntfy: Monitoring zuerst – du merkst sofort, wenn später etwas ausfällt.
AdGuard Home / Pi-hole: sofort spürbarer Nutzen fürs ganze Netz, geringes Risiko.
Jellyfin oder Immich: der „Wow-Effekt“ – Medien bzw. Fotos.
Paperless / Nextcloud / Syncthing: Dokumente und Dateien, sobald Backup-Routine steht.
Vaultwarden / Home Assistant: Kritisches zuletzt – wenn Betrieb, Backup und VPN sicher sitzen.

11 / 12Wartung & Betrieb

Wartungsroutinen

RhythmusAufgabenAufwand
Täglich (automatisch)Backups laufen; Monitoring prüft Dienste; Alerts kommen aufs Handy – du machst: nichts, solange alles grün ist0 min
WöchentlichDashboard/Alerts überfliegen; Backup-Reports grün?; Speicherstand (df -h); OS-Updates einspielen10–15 min
MonatlichContainer-Updates (mit Snapshot davor); SMART-Werte checken; Restore-Stichprobe (1 Datei zurückholen); docker image prune30–60 min
HalbjährlichRestore-Ernstfallprobe (kompletten Dienst wiederherstellen); Zugänge/Dienste aufräumen; offene Ports prüfen; Staub entfernen; Doku aktualisieren1–2 h

Dokumentation führen

Was dokumentieren
  • IP-Plan, Hostnames, Portliste
  • Welcher Dienst, wo liegen die Daten, wie wird gesichert
  • Besonderheiten/Workarounds („Warum ist X so eingestellt?“)
  • Restore-Anleitung: „Server tot – was tun?“ Schritt für Schritt
Wo dokumentieren
  • Zugangsdaten: nur im Passwortmanager
  • Compose/Configs: Git-Repo (ohne Secrets)
  • Notizen: Markdown-Ordner, Wiki oder Notiz-App – Hauptsache außerhalb des Servers verfügbar
Benachrichtigungen
  • Ein Kanal für alles: ntfy (selbst gehostet) oder Gotify/Telegram/E-Mail
  • Anschließen: Uptime Kuma, Backup-Jobs, smartd, fail2ban
  • Regel: Fehler müssen dich erreichen, nicht in Logs versauern

Grundsätze für ruhigen Betrieb

  • Boring is good: ein stabiler Dienst ist mehr wert als drei halbfertige
  • Änderungsfenster: nichts Wichtiges freitags abends oder vor dem Urlaub updaten
  • Vor jeder Änderung: Snapshot/Backup → ändern → testen → dokumentieren
  • Familie bedenken: wenn andere die Dienste nutzen, Ausfälle kommunizieren und Kritisches (DNS!) redundant auslegen oder Fallback konfigurieren
  • Kapazität im Blick: Platten < 80 %, RAM-Auslastung beobachten, bevor es eng wird planen

12 / 12Hilfe & Glossar

Troubleshooting: Standardvorgehen

Was hat sich geändert? 90 % der Probleme folgen auf ein Update, eine Config-Änderung oder volle Platten.
Von unten nach oben prüfen: Strom → Netzwerk (ping) → Host erreichbar (SSH) → Dienst läuft (docker ps) → Logs.
Logs lesen: docker compose logs -f bzw. journalctl -u dienst -e – die Fehlermeldung sagt fast immer, was los ist.
Fehlermeldung wörtlich suchen (GitHub Issues des Projekts zuerst) – jemand hatte das Problem schon.
Eine Änderung pro Versuch, dann testen. Wildes Rumprobieren macht’s schlimmer und undokumentierbar.

Häufige Probleme

SymptomErste ChecksTypische Ursache
Dienst nicht erreichbardocker ps, richtige IP:Port?, ss -tulpnContainer down, Port-Mapping falsch, Firewall, falsche URL
Container startet immer neu (Restart-Loop)docker logs <name>Fehlende Env-Variable, kaputte Config, Rechte auf Volume, Port belegt
„Permission denied“ auf Dateienls -l auf dem Host, PUID/PGID im ComposeContainer-User ≠ Datei-Besitzer
Platte volldf -h, docker system df, ncdu /Alte Images, Log-Wildwuchs, Downloads, Backups aufs falsche Ziel
Alles langsamhtop, docker stats, iostat, SMARTRAM voll (Swap!), ein Container frisst CPU, sterbende Platte
Nach Update kaputtChangelog/Breaking Changes, LogsMajor-Update mit Migrationsschritt → Rollback auf Snapshot/altes Tag, Anleitung lesen
Kein Internet im ganzen NetzLäuft Pi-hole/AdGuard? Router-DNS?DNS-Server down = „Internet kaputt“; Fallback-DNS im Router hinterlegen
Server nach Stromausfall ausBIOS-Einstellung„Restore on AC Power Loss“ nicht auf Power On
Von unterwegs nicht erreichbarVPN verbunden? DynDNS aktuell? CGNAT?DS-Lite/CGNAT ohne öffentliche IPv4 → Tailscale nutzen

Diagnose-Werkzeugkasten

BefehlZeigt
htopCPU, RAM, Prozesse live
df -h / ncdu /pfadPlattenfüllstand / was den Platz frisst
ss -tulpnOffene Ports + welcher Prozess lauscht
journalctl -e / -u sshSystemlogs (Ende) / eines Dienstes
docker compose logs -fContainer-Logs live
ping / dig name / tracerouteErreichbarkeit / DNS-Auflösung / Netzwerkpfad
smartctl -a /dev/sdaGesundheit einer Platte
sensorsTemperaturen
uptime / free -hLast & Laufzeit / RAM-Belegung

Glossar

NAS
Network Attached Storage – Speicher-Server im Netzwerk, Spezialfall des Homeservers.
Headless
Betrieb ohne Monitor/Tastatur – Verwaltung per SSH und Web-UIs.
Hypervisor
Software, die VMs verwaltet (z. B. Proxmox VE).
VM / LXC / Container
Voll virtualisierter Rechner / leichter System-Container / App-Container (Docker).
Reverse Proxy
Vermittler, der Anfragen anhand des Domainnamens an die richtige App weiterleitet und HTTPS übernimmt.
VPN
Verschlüsselter Tunnel ins Heimnetz (WireGuard, Tailscale) – der sichere Weg für Fernzugriff.
VLAN
Virtuell getrennte Netze auf derselben Hardware – z. B. IoT vom Server isolieren.
DNS / DHCP
Namen → IP-Adressen auflösen / automatische IP-Vergabe im Netz.
Port-Forwarding
Router leitet Anfragen aus dem Internet an ein internes Gerät weiter – sparsam einsetzen.
CGNAT / DS-Lite
Anschluss ohne eigene öffentliche IPv4 – klassische Portfreigaben funktionieren nicht.
DynDNS
Dienst, der die wechselnde Heim-IP unter festem Namen erreichbar hält.
ZFS / Pool / Scrub
Dateisystem mit Prüfsummen / Verbund mehrerer Platten / Prüf-Lauf gegen stille Datenfehler.
Snapshot
Eingefrorener Datenstand für schnellen Rollback – ergänzt Backups, ersetzt sie nicht.
SMART
Selbstdiagnose von Festplatten/SSDs – Frühwarnsystem für Ausfälle.
CMR / SMR
Aufzeichnungsverfahren von HDDs – für NAS/RAID immer CMR wählen.
TBW
Total Bytes Written – Schreib-Lebensdauer einer SSD.
ECC-RAM
Arbeitsspeicher mit Fehlerkorrektur – Bonus für Datenintegrität.
USV / UPS
Batterie-Puffer für sauberes Herunterfahren bei Stromausfall.
NUT
Network UPS Tools – verbindet USV mit Server für Auto-Shutdown.
Let's Encrypt / TLS
Kostenlose Zertifikate / Verschlüsselung hinter HTTPS.
2FA
Zweiter Faktor beim Login (App-Code, Passkey) – Pflicht für Admin-Zugänge.
fail2ban / CrowdSec
Sperrt IPs nach wiederholten Fehlversuchen automatisch.
PUID/PGID
User-/Gruppen-ID, unter der ein Container auf Dateien zugreift.
IaC
Infrastructure as Code – Setup als Textdateien (Compose, Ansible) statt Klick-Historie.
Homelab
Der Überbegriff fürs Ganze – Heimserver + Netzwerk + Basteln + Lernen.
Homeserver 101 · Referenz für Planung, Aufbau und Betrieb · Stand 07/2026 · Software-Empfehlungen sind Momentaufnahmen – Prinzipien (Backup, VPN, Updates, Doku) bleiben.