192 lines
No EOL
8.5 KiB
Markdown
192 lines
No EOL
8.5 KiB
Markdown
# 🏠 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). |