# 🏠 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/`). ```text ## 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: ```Bash 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: >```Bash >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).