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.
🏠 Smart Home
Zentrale für Automatisierung, lokal statt Hersteller-Cloud.
💾 Backup-Ziel
Zentrale Sicherung aller PCs, Handys und Dokumente.
- Restic, Paperless-ngx, PBS
🧪 Lernen & Basteln
Linux, Docker, Netzwerke, Virtualisierung in echt lernen.
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
| Option | Preis (ca.) | Idle-Verbrauch | Leistung | Erweiterbar | Geeignet für |
| Raspberry Pi 5 | 80–130 € | 3–6 W | niedrig | kaum (USB/NVMe-HAT) | Pi-hole, Home Assistant, kleine Dienste |
| Mini-PC (Intel N100/N150) | 150–250 € | 6–12 W | mittel | begrenzt (1× NVMe, 1× SATA) | Allround-Einstieg, Docker, Jellyfin |
| Gebrauchter Office-Mini (Dell/Lenovo/HP „1L“) | 80–200 € | 8–15 W | mittel–hoch | begrenzt | Preis-Leistungs-Tipp, Proxmox-Einstieg |
| Fertig-NAS (Synology/QNAP/Ugreen) | 300–800 € + Platten | 15–40 W | mittel | Platten ja, sonst wenig | „Soll einfach laufen“, viel Storage |
| Eigenbau (ITX/ATX) | 400–1000 € | 20–60 W | frei wählbar | voll (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
| System | Typ | Schwierigkeit | Kosten | Stark bei | Bedenken |
| Proxmox VE | Hypervisor (VMs + LXC) | mittel | kostenlos | Flexibilität, Snapshots, Backups, alles auf einem Gerät | Storage/NAS-Funktionen nur per VM/Umweg |
| Debian/Ubuntu Server + Docker | Pures Linux | mittel | kostenlos | Schlank, maximale Kontrolle, wenig Overhead | Alles selbst bauen (Backup, Monitoring) |
| TrueNAS Scale | NAS-OS (ZFS-first) | mittel | kostenlos | Storage, ZFS, Freigaben, Snapshots | Apps/Container weniger flexibel als pures Docker |
| Unraid | NAS-OS | leicht | Lizenz (ab ~50 $) | Gemischte Plattengrößen, einfache UI, große Community | Kostenpflichtig, Parity statt klassischem RAID |
| OpenMediaVault | NAS-OS (Debian-Basis) | leicht | kostenlos | Leichtes NAS auf schwacher Hardware (auch Pi) | Weniger poliert, Docker via Plugin |
| Synology DSM / QNAP QTS | Hersteller-OS | leicht | im NAS enthalten | „Einschalten und läuft“, gute Apps | Gebunden 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
| Technik | Isolation | Overhead | Wofü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 gering | Leichte Linux-Dienste unter Proxmox (Pi-hole, kleine Tools) |
| Docker (App-Container) | App-Ebene | gering | Standard 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
| Dateisystem | Snapshots | Checksummen (Bitrot-Schutz) | RAID integriert | Wofür |
| ext4 | – | – | – (mdadm separat) | Einfach & robust; Standard für Einzelplatten und OS |
| ZFS | ✓ | ✓ | ✓ (Mirror/RAIDZ) | Datenintegrität, Pools, Replikation; Proxmox & TrueNAS nativ |
| Btrfs | ✓ | ✓ | teilweise (RAID5/6 unreif) | Snapshots auf Einzelplatten/Mirror; Synology nutzt es |
| XFS | – | – | – | Große Dateien/Medien, Unraid-Standard |
RAID-Level Überblick
| Level | Platten min. | Nutzbare Kapazität | Verkraftet Ausfall | Hinweis |
| Keins (Einzelplatte) | 1 | 100 % | 0 | Völlig ok, wenn Backup existiert |
| RAID 0 (Stripe) | 2 | 100 % | 0 – eine weg, alles weg | Für Homeserver praktisch nie sinnvoll |
| RAID 1 / ZFS Mirror | 2 | 50 % | 1 | Einfach, schnell wiederhergestellt – Standard-Tipp |
| RAID 5 / RAIDZ1 | 3 | (n−1)/n | 1 | Bei großen Platten (>8 TB) riskant beim Rebuild |
| RAID 6 / RAIDZ2 | 4 | (n−2)/n | 2 | Guter Kompromiss bei 4+ großen Platten |
| RAID 10 | 4 | 50 % | 1 je Mirror | Schnell, teuer in Kapazität |
| Unraid Parity | 2 | n−1 (bzw. n−2) | 1–2 | Gemischte 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ät | Daten | Beispiele | Strategie |
| Unersetzlich | Persönliche Daten | Fotos, Dokumente, Passwort-Tresor (Vaultwarden!), Paperless-Archiv | Voll 3-2-1, verschlüsselt, täglich/automatisch |
| Aufwendig | Konfiguration | Docker-Compose, .env, AppData, Home-Assistant-Config, VM-Backups | Täglich automatisch, mind. 2 Ziele |
| Ersetzbar | Wiederbeschaffbares | Medien, ISOs, Downloads | Optional; 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
| Tool | Typ | Stärken | Typischer Einsatz |
| Restic | CLI, dedupliziert + verschlüsselt | Schnell, viele Backends (lokal, SFTP, S3/B2), restic check | Standard-Tipp für Datei-Backups → Cloud & Platte |
| Borg / Borgmatic | CLI, dedupliziert + verschlüsselt | Sehr effizient, ausgereift | Backups auf eigenes Ziel (SSH/BorgBase) |
| Proxmox Backup Server | Server-Anwendung | VM/LXC-Backups inkrementell + verifiziert | Proxmox-Setups, gern auf Zweitgerät |
| Duplicati | Web-UI | Einfach klickbar | Einsteiger; Restore regelmäßig testen |
| rsync | CLI, 1:1-Kopie | Simpel, überall vorhanden | Medien spiegeln; keine Versionierung! |
| Syncthing | Sync (kein Backup!) | Geräte-Sync in Echtzeit | Verteilen 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)
| Wann | Was | Wohin | Womit |
| täglich, nachts | AppData + Configs + Dokumente/Fotos | zweite interne/USB-Platte | Restic (verschlüsselt, versioniert) |
| täglich, nachts | Unersetzliches (Fotos, Doks, Tresor) | Cloud (B2/Storage Box) | Restic, gleicher Job, zweites Repo |
| wöchentlich | VMs/LXC komplett | PBS oder NAS | Proxmox-Backup |
| monatlich | Restore-Stichprobe: 1 Datei + 1 Ordner zurückholen | — | Hand + 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
| Port | Dienst | Bemerkung |
| 22 | SSH | Fernwartung; nur mit Key, nie ins Internet forwarden |
| 53 | DNS | Pi-hole/AdGuard; Konflikt mit systemd-resolved beachten |
| 80 / 443 | HTTP / HTTPS | Gehören dem Reverse Proxy – Apps dahinter |
| 445 | SMB (Dateifreigabe) | Nur im LAN/VPN – niemals ins Internet |
| 51820 | WireGuard (UDP) | Der einzige Port, den man guten Gewissens öffnen kann |
| 8080, 8443, 3000 … | App-Webinterfaces | Typische 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.
| Proxy | Bedienung | Stärken | Für wen |
| Nginx Proxy Manager | Web-UI | Klickbar, Let's-Encrypt integriert | Einsteiger-Standard |
| Caddy | Config-Datei (sehr kurz) | Automatisches HTTPS, schlank | Wer Textconfig mag |
| Traefik | Docker-Labels | Erkennt Container automatisch | Fortgeschrittene, 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.
| # | Methode | Sicherheit | Aufwand | Offener Port? | Bewertung |
| 1 | Tailscale / ZeroTier / NetBird (Overlay-VPN) | hoch | minimal | nein | Erste Wahl: App installieren, einloggen, fertig; funktioniert auch hinter CGNAT |
| 2 | WireGuard selbst gehostet (Server/Router, z. B. FritzBox) | hoch | mittel | 1× UDP | Ohne Drittanbieter; braucht öffentliche IP + DynDNS |
| 3 | Cloudflare Tunnel | hoch | gering | nein | Für einzelne Web-Apps, die wirklich öffentlich sein sollen; Traffic läuft über Cloudflare, Video-Streaming per ToS unerwünscht |
| 4 | Port-Forwarding + Reverse Proxy | nur gehärtet | hoch | 80/443 | Nur 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) | nie | — | — | Niemals. 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
| Fehler | Risiko | Besser so |
| Port-Forward direkt auf App (Jellyfin:8096, HA:8123) | Bots scannen & exploiten bekannte Ports in Minuten | VPN; wenn öffentlich: Reverse Proxy + HTTPS + 2FA |
| SSH mit Passwort erreichbar | Brute-Force rund um die Uhr | SSH-Keys, Passwort-Login aus, fail2ban |
| Docker-Socket in Container mounten (Watchtower & Co. unbedacht) | Socket = Root auf dem Host | Nur bewusst; Alternativen: manuelle Updates, Socket-Proxy |
Passwörter/Keys in compose.yaml in Git | Secrets landen öffentlich/kopiert | .env-Datei (in .gitignore) oder Docker Secrets |
| „Später mache ich Backup“ | Totalverlust bei erstem Defekt/Fehlgriff | Backup gehört zum Setup, nicht zur Kür |
| Alles im selben Netz mit Billig-IoT | Kompromittierte Kamera erreicht den Server | IoT ins Gastnetz/VLAN |
| UPnP am Router aktiv | Geräte öffnen selbstständig Ports | UPnP deaktivieren, Freigaben nur manuell |
| Ein Admin-Passwort für alles | Ein Leak = alles offen | Passwortmanager, 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
| Befehl | Macht |
docker compose up -d | Stack starten / Änderungen anwenden |
docker compose pull && docker compose up -d | Update: neue Images ziehen + neu erstellen |
docker compose logs -f [dienst] | Logs live ansehen (erster Schritt bei Problemen) |
docker compose down | Stack stoppen und Container entfernen (Daten bleiben) |
docker ps | Laufende Container + Status/Ports |
docker exec -it <name> bash | Shell im Container öffnen |
docker system df / docker image prune -a | Speicherverbrauch anzeigen / alte Images aufräumen |
docker stats | CPU/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
| Rhythmus | Aufgaben | Aufwand |
| Täglich (automatisch) | Backups laufen; Monitoring prüft Dienste; Alerts kommen aufs Handy – du machst: nichts, solange alles grün ist | 0 min |
| Wöchentlich | Dashboard/Alerts überfliegen; Backup-Reports grün?; Speicherstand (df -h); OS-Updates einspielen | 10–15 min |
| Monatlich | Container-Updates (mit Snapshot davor); SMART-Werte checken; Restore-Stichprobe (1 Datei zurückholen); docker image prune | 30–60 min |
| Halbjährlich | Restore-Ernstfallprobe (kompletten Dienst wiederherstellen); Zugänge/Dienste aufräumen; offene Ports prüfen; Staub entfernen; Doku aktualisieren | 1–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
| Symptom | Erste Checks | Typische Ursache |
| Dienst nicht erreichbar | docker ps, richtige IP:Port?, ss -tulpn | Container 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 Dateien | ls -l auf dem Host, PUID/PGID im Compose | Container-User ≠ Datei-Besitzer |
| Platte voll | df -h, docker system df, ncdu / | Alte Images, Log-Wildwuchs, Downloads, Backups aufs falsche Ziel |
| Alles langsam | htop, docker stats, iostat, SMART | RAM voll (Swap!), ein Container frisst CPU, sterbende Platte |
| Nach Update kaputt | Changelog/Breaking Changes, Logs | Major-Update mit Migrationsschritt → Rollback auf Snapshot/altes Tag, Anleitung lesen |
| Kein Internet im ganzen Netz | Läuft Pi-hole/AdGuard? Router-DNS? | DNS-Server down = „Internet kaputt“; Fallback-DNS im Router hinterlegen |
| Server nach Stromausfall aus | BIOS-Einstellung | „Restore on AC Power Loss“ nicht auf Power On |
| Von unterwegs nicht erreichbar | VPN verbunden? DynDNS aktuell? CGNAT? | DS-Lite/CGNAT ohne öffentliche IPv4 → Tailscale nutzen |
Diagnose-Werkzeugkasten
| Befehl | Zeigt |
htop | CPU, RAM, Prozesse live |
df -h / ncdu /pfad | Plattenfüllstand / was den Platz frisst |
ss -tulpn | Offene Ports + welcher Prozess lauscht |
journalctl -e / -u ssh | Systemlogs (Ende) / eines Dienstes |
docker compose logs -f | Container-Logs live |
ping / dig name / traceroute | Erreichbarkeit / DNS-Auflösung / Netzwerkpfad |
smartctl -a /dev/sda | Gesundheit einer Platte |
sensors | Temperaturen |
uptime / free -h | Last & 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.