🏠 Homeserver Setup

Zentrale Dokumentation der Infrastruktur, Docker-Container und persistenten Daten meines Debian-basierten Homeservers.

---

🗺️ Projektstruktur

Das Setup trennt strikt zwischen persistenten Anwendungsdaten (data/) und den Docker-Konfigurationsdateien (homeserver/).

## Tree
├── data
│   ├── backup_emmc
│   │   └── sys_ssh
│   ├── dyndns
│   │   └── ddns-data
│   ├── excalidraw
│   ├── forgejo
│   │   └── forgejo
│   ├── gantt
│   │   ├── dist
│   │   ├── env.d.ts
│   │   ├── gantt_dockerfolder
│   │   ├── index.html
│   │   ├── node_modules
│   │   ├── package.json
│   │   ├── package-lock.json
│   │   ├── public
│   │   ├── README.md
│   │   ├── src
│   │   ├── tsconfig.app.json
│   │   ├── tsconfig.json
│   │   ├── tsconfig.node.json
│   │   └── vite.config.ts
│   ├── jellyfin
│   │   ├── cache
│   │   ├── config
│   │   └── media
│   ├── kitchenowl
│   │   └── db_data
│   ├── letsencrypt
│   ├── matrix
│   │   └── data
│   ├── n8n
│   │   └── local-files
│   ├── openProject
│   ├── passbolt
│   │   ├── db-data
│   │   ├── gpg-keys
│   │   └── jwt-keys
│   ├── sure
│   │   ├── db
│   │   ├── enable_banking.pem
│   │   └── storage
│   ├── test
│   │   └── dns-check.sh
│   ├── traefik
│   │   ├── acme.json
│   │   └── letsencrypt
│   ├── wartungsskripte
│   │   ├── update_befehl.sh
│   │   └── update_docker.sh
│   └── xWiki
│       ├── postgres_data
│       └── xwiki_data
└──  homeserver
    │   └── docker-compose.yml
    ├── excalidraw
    │   └── docker-compose.yml
    ├── forgejo
    │   └── docker-compose.yml
    ├── gantt_dockerfolder
    │   └── docker-compose.yml
    ├── jellyfin
    │   └── docker-compose.yml
    ├── kitchenowl
    │   └── docker-compose.yml
    ├── letsencrypt
    ├── matrix
    │   └── docker-compose.yml
    ├── n8n
    │   └── docker-compose.yml
    ├── openProject
    │   └── docker-compose.yml
    ├── passbolt
    │   └── docker-compose.yml
    ├── readme.md
    ├── sure
    │   └── docker-compose.yml
    ├── test
    │   └── dns-check.sh
    ├── traefik
    │   └── docker-compose.yml
    ├── wartungsskripte
    │   ├── update_befehl.sh
    │   └── update_docker.sh
    └── xWiki
        └── docker-compose.yml

🚀 Infrastruktur & Netzwerk

Als zentraler Reverse Proxy wird Traefik eingesetzt. Er fängt alle Anfragen auf Port 80/443 ab, verteilt sie an die jeweiligen Docker-Container und erstellt automatisch SSL-Zertifikate via Let's Encrypt.

Wichtige URLs im Netzwerk:

🌐 Git-Server (Forgejo): https://git.bybenji.de (SSH-Port: 222) 🌐 Passwortmanager: https://passbolt.bybenji.de 🌐 Streaming: https://jellyfin.bybenji.de

🛠️ Betrieb & Wartung

Container starten / stoppen Um einen bestimmten Dienst zu starten, in den entsprechenden Ordner unter homeserver/ wechseln und ausführen:

cd homeserver/jellyfin
docker compose up -d

Updates

Unter homeserver/wartungsskripte/ befinden sich Skripte zur Serverpflege. update_docker.sh: Aktualisiert alle laufenden Docker-Container auf das neueste Image und räumt alte Images auf (docker system prune). Aktuell ist ein Manuelles Wartungsfenster jeden Samstag um 21 Uhr gesetzt.

[!NOTE] Automatisierung Einrichtung als Cronjob für automatische Updates jeden Sonntag um 03:00 Uhr:

0 3 * * 0 /bin/bash /mnt/PB960/data/gantt/homeserver/wartungsskripte/update_docker.>sh

📦 Backup-Strategie

Um maximale Datensicherheit zu gewährleisten, werden alle Produktivdaten (data/) nach dem 3-2-1-Prinzip gesichert.

1. Datenbasis & Lokales Backup (Kopie 1 & 2 - Medium 1)

• Produktivdaten: Befinden sich live auf dem Produktivsystem.
• Lokales Backup: Täglich inkrementelle und monatlich vollständige Backups werden auf einem dedizierten NAS gesichert, das sich physisch im selben Serverrack befindet.

2. Offsite & Standby-Server (Kopie 3 - Standort extern)

• Backup-Server: Eine vollständige Kopie wird an einen geografisch getrennten Standort gesichert.
• Hot-Standby: Da dieser Server denselben Techstack besitzt, kann er bei Wartungsarbeiten oder Ausfällen des Hauptservers direkt als temporäres Produktivsystem zugeschaltet werden.

Note

Offene Baustelle: Das 2. Speichermedium Für die vollständige Erfüllung des 3-2-1-Prinzips fehlt noch das zweite, alternative Speichermedium (z. B. eine rotierende externe USB-Festplatte (Air-Gapped) oder ein verschlüsselter S3-Cloud-Speicher wie Hetzner Storage Box).

🖥️ System-Backup

• Unabhängig von den Anwendungsdaten werden Abbilder des eMMC-Speichers sowie die systemrelevanten SSH-Schlüssel unter data/backup_emmc/sys_ssh/ vorgehalten.

💾 Speicher-Architektur & NAS

Sowohl das lokale Produktiv-NAS als auch das Offsite-NAS sind speicherseitig identisch aufgebaut, um maximale Redundanz und volle Kompatibilität im Failover-Fall zu gewährleisten.

📍 Phase 1: Start-Setup (Aktueller Stand)

• Main-Server: 1x 14 TB Seagate Exos (Single Drive – 14 TB Netto-Nutzdaten)
• Offsite-Server: 1x 14 TB Seagate Exos (Single Drive – 14 TB Backup-Ziel)
• Sicherheit: Die Datenkomponente wird per täglichem Skript/Replikation auf den Offsite-Server gesichert. Es besteht in dieser Phase noch keine lokale Festplatten-Redundanz (RAID) beim Ausfall einer Platte vor Ort.

🚀 Phase 2: RAID 5 Erweiterung (Zukunft)

Sobald zusätzlicher Speicher oder lokale Ausfallsicherheit benötigt wird, wird jedes System um 2 weitere 14 TB Platten ergänzt:

• Konfiguration: Migration auf ein 3-Platten-RAID-5 pro Server.
• Neuer Speicher: 28 TB Netto-Nutzdaten pro Server bei einer Fehlertoleranz von 1 ausfallenden Festplatte pro System.

🖥️ Offsite-Server & Techstack

Der Offsite-Server dient primär als geografisch getrenntes Backup-Ziel, ist jedoch hardware- und softwareseitig als Hot-Standby konzipiert. Bei einem Totalausfall oder Wartungsarbeiten am Hauptstandort kann er die primären Dienste temporär übernehmen.

🌐 Virtualisierungs-Plattform (Proxmox VE)

Als Betriebssystem-Unterbau wird Proxmox VE (Virtual Environment) eingesetzt. Dies ermöglicht eine strikte Kapselung und einfache Verwaltung der Ressourcen:

• Hypervisor: Typ-1-Bare-Metal-Hypervisor auf Debian-Basis.
• LXC (Linux Containers): Für ressourcensparende Anwendungen (wie den Docker-Host).
• VMs (Virtuelle Maschinen): Für isolierte Systeme, die einen eigenen Kernel oder ein anderes OS benötigen.

📦 Container-Architektur (Der "Bauchtanz")

Um den exakt gleichen Techstack wie auf dem Main-Server zu spiegeln, läuft innerhalb von Proxmox ein dedizierter LXC-Container (oder eine VM), der als Docker-Host fungiert.

• Docker & Compose: Innerhalb dieser Instanz wird die identische homeserver/-Struktur per Git synchronisiert gehalten.
• Dienste-Status: Die Docker-Container (Nextcloud, Immich, Jellyfin etc.) sind im Normalbetrieb gestoppt oder laufen im reinen Standby-Modus, um Ressourcen zu schonen, stehen aber für ein sofortiges Failover bereit.

🔄 Replikation & Backup-Infrastruktur (Phase 1)

In der aktuellen Phase (Single-Drive) sieht das Zusammenspiel wie folgt aus:

1. ZFS / Local Storage: Proxmox verwaltet die einzelne 14 TB Seagate Exos Festplatte als lokalen Speicherpool.
2. Pull-/Push-Backups: Der Hauptserver schiebt seine Daten (z. B. via rsync, rclone oder BorgBackup) verschlüsselt über das Netzwerk auf den Offsite-Proxmox-Speicher.

---

Visualisierung

├── für einen Ordner oder eine Datei, wenn danach noch weitere Elemente auf derselben Ebene folgen. └── für das letzte Element auf einer Ebene (das „Eckstück“). │ für Linien, die an Unterordnern vorbeiführen (wichtig für die richtige Einrückung).