Dieses Projekt beschreibt die Konzeption und Umsetzung einer produktiven Backup-Lösung für mehrere Docker-Compose-Anwendungen auf einem KVM-Server.
Die Backup-Workloads laufen containerisiert in einem Kubernetes-Cluster und sichern Daten über eine SSH-Verbindung von einem externen Host in ein verschlüsseltes restic-Repository.
Entwicklungsphase (Testcluster)
Die initiale Umsetzung erfolgte eigenständig auf einem Testcluster.
Dabei wurde:
- ein kleines Persistent Volume direkt im Cluster zu Testzwecken erstellt
- die restic-Repository-Initialisierung implementiert
- SSH-Authentifizierung über Key-Handling konfiguriert
- CronJobs zur Backup-Automatisierung aufgebaut
- Test-Backups durchgeführt und validiert
Die Implementierung erfolgte eigenständig mit technischer Unterstützung durch KI.
Die entsprechenden Manifeste des Testsetups sind im öffentlichen GitHub-Repository einsehbar.
Produktivsetzung
Die Produktivsetzung erfolgte im Sparring.
Dabei wurde:
- ein produktives Persistent Volume über ein NFS-Share auf einer NAS angebunden
- das Backup-Setup in das interne GitLab-Repository integriert
- Deployment via GitOps mit ArgoCD durchgeführt
- Debugging über ArgoCD-Statusmeldungen und Pod-Logs vorgenommen
Während der Inbetriebnahme wurden u. a. folgende Probleme identifiziert und behoben:
- fehlender NFS-Zielordner
- nicht ersetzte Platzhalterwerte aus anonymisierten Templates
- StorageClass-Mismatch zwischen PV und PVC
Architektur (Produktiv)
- Kubernetes CronJobs führen getrennte Backups pro Compose-Verzeichnis aus
- Zugriff auf den KVM-Server erfolgt read-only via SSH-Key
- Speicherung im verschlüsselten restic-Repository
- Repository liegt auf NFS-basiertem Persistent Volume (NAS)
- Retention-Policy über restic (
forget --prune) - Deployment via ArgoCD (GitOps)
Besonderheit
Das öffentliche Repository enthält ausschließlich anonymisierte Manifeste und Vorlagen.
Produktive Zugangsdaten, Hostnamen und Infrastrukturdetails sind nicht enthalten.
- Daten remote per SSH sichert
- inkrementell über mehrere Tage/Wochen arbeitet
- automatisiert in einem Kubernetes-Umfeld läuft
- Fehler sichtbar macht, statt still zu scheitern
Geplante Weiterentwicklung
Nach mehreren Tests stellte sich heraus, dass das Backup zwar funktioniert, aber das Bash Skript optimiert werden muss:
Das aktuelle Setup streamt die zu sichernden Verzeichnisse als tar-Archiv in das restic-Repository.
Diese Lösung ist funktional und stabil, bringt jedoch einen Nachteil mit sich:
Da restic nur ein einzelnes Archiv sieht, führt bereits eine kleine Änderung (z. B. im Datenbankdump) dazu, dass das gesamte Archiv erneut als vollständiges Backup gespeichert wird.
Geplant ist daher eine Umstellung auf eine direkte Übergabe der Dateien an restic, sodass:
- file-level Deduplizierung genutzt werden kann
- inkrementelle Backups effizienter erfolgen
- einzelne Dateien gezielt wiederhergestellt werden können
- die Speicher- und Netzwerkbelastung reduziert wird
Diese Optimierung erhöht die Effizienz der Backup-Strategie und nutzt die eigentlichen Stärken von restic besser aus.
Repository
Im Repository finden sich Kubernetes-Manifeste, Test-Pods und Infrastruktur-Definitionen für die Backup-Automatisierung nach aktuellem Stand.