YunoHost – Complete Backup Strategy & Restore Runbook
Dieses Runbook beschreibt den vollständigen Backup-Prozess für einen produktiven
YunoHost-Server mit Nextcloud, WordPress, SOGo, MariaDB, nginx und Netdata.
Es umfasst manuelle Sicherungen, automatisierte tägliche Backups, Offsite-Kopien,
Integritätsprüfungen, Restore-Tests und die migrationssichere Wiederherstellung.
Scope & Zielbild
Zielbild: Konsistente, nachvollziehbare und regelmäßig getestete Sicherung des gesamten Systems.
- Apps: Nextcloud, WordPress, SOGo, Netdata und weitere YunoHost-Apps
- System: YunoHost-Konfiguration, Domains, SSL, nginx, Benutzer, Firewall
- Daten: MariaDB-Dumps, App-Daten, Webdaten, Konfigurationsdateien
- Betrieb: tägliche Automatisierung, Offsite-Kopie, Monitoring, Restore-Test
Grundsatz: Ein erfolgreich erzeugtes Archiv ist noch kein belastbarer Backup-Nachweis.
Erst Integritätsprüfung, Download und Restore-Test machen das Backup betriebssicher.
Empfohlenes Ziel: 3-2-1-Strategie mit lokalem Backup, externem Offsite-Speicher und dokumentiertem Restore.
Backup-Architektur
| Backup-Typ | Inhalt | Rhythmus |
|---|---|---|
| YunoHost Backup | System + Apps + DB + App-Daten | täglich |
| System-Archiv | /etc, /home, /var/www | täglich oder vor Changes |
| Offsite-Kopie | Transfer auf Storage Box / NAS / zweiten Server | täglich |
| Restore-Test | Wiederherstellung auf Testsystem | monatlich |
Empfohlene Reihenfolge: YunoHost Backup → Prüfung → System-Archiv → Offsite → Test
Besonders relevant für deine Umgebung:
Nextcloud-Datenbestand, MariaDB-Inhalte, WordPress-Webroot, SOGo-Mail-/Groupware-Daten, nginx-Konfiguration, TLS-Zertifikate und Netdata-Konfiguration.
Nextcloud-Datenbestand, MariaDB-Inhalte, WordPress-Webroot, SOGo-Mail-/Groupware-Daten, nginx-Konfiguration, TLS-Zertifikate und Netdata-Konfiguration.
Phase 0: Voraussetzungen
Vor jedem Backup sicherstellen:
- ausreichend freier Speicherplatz vorhanden
- keine kritischen laufenden Änderungen oder Wartungsarbeiten
- SSH-Zugang funktionsfähig
- YunoHost und Apps nicht in fehlerhaftem Zustand
df -h sudo yunohost app list sudo yunohost service status sudo yunohost diagnosis run --issues
Phase 1: Manuelles YunoHost-Backup
Primärsicherung: Das integrierte YunoHost-Backup ist die zentrale migrationsfähige Sicherung.
sudo yunohost backup create --system --apps --name migration-backup-$(date +%F)
Standardpfad der erzeugten Archive:
/home/yunohost.backup/archives/
Enthaltene Bestandteile:
- YunoHost-Systemkonfiguration
- Domains und TLS-Zertifikate
- nginx-Konfigurationen
- MariaDB-Datenbanken
- Nextcloud, WordPress, SOGo, Netdata und weitere Apps
- zugehörige App-Daten und Restore-Metadaten
Phase 2: Integritätsprüfung des YunoHost-Backups
sudo yunohost backup list sudo yunohost backup info migration-backup-$(date +%F)
tar -tf /home/yunohost.backup/archives/migration-backup-$(date +%F).tar | head
| Prüfung | Erwartung |
|---|---|
| Backup vorhanden | Name in backup list sichtbar |
| Status | keine Fehlermeldung / vollständiger Lauf |
| Archiv lesbar | tar -tf liefert Einträge |
| Größe plausibel | abhängig von Nextcloud- und Webdatenbestand |
Hinweis: Bei bestehenden Backupnamen immer einen datumsbasierten Namen verwenden, um Konflikte zu vermeiden.
Nextcloud gezielt im Archiv prüfen
tar -tf /home/yunohost.backup/archives/migration-backup-$(date +%F).tar | grep "apps/nextcloud" | head
Allgemeine Archivgröße prüfen
du -h /home/yunohost.backup/archives/*.tar
Phase 3: Zusätzliches System-Backup
Zweitsicherung: Zusätzlich zum YunoHost-Archiv wird ein vollständiges Datei-Archiv wichtiger Serverpfade erstellt.
sudo tar -czf /home/mayadm/server-full-backup-$(date +%F).tar.gz \ /etc \ /home \ /var/www
Diese Ablage im Home-Verzeichnis vereinfacht den späteren Download per SCP.
| Pfad | Zweck |
|---|---|
| /etc | System- und Dienstkonfigurationen |
| /home | Benutzerdaten, App-Daten, zusätzliche Dateien |
| /var/www | Webroots von Nextcloud, WordPress und weiteren Apps |
Hinweis: Die Meldung Removing leading ‘/’ von tar ist normal und kein Fehler.
Phase 4: Download / Offsite-Kopie
Download des YunoHost-Backups
scp mayadm@SERVER-IP:/home/yunohost.backup/archives/migration-backup-YYYY-MM-DD.tar .
Download des System-Archivs
scp mayadm@SERVER-IP:/home/mayadm/server-full-backup-YYYY-MM-DD.tar.gz .
Offsite-Kopie per rsync
rsync -avz /home/yunohost.backup/archives/ user@backupserver:/backup/yunohost/ rsync -avz /home/mayadm/server-full-backup-*.tar.gz user@backupserver:/backup/system/
Mögliche Ziele:
Netcup Storage Box, zweiter Linux-Server, NAS über VPN, Objektstorage über zusätzlichen Sync-Mechanismus.
Netcup Storage Box, zweiter Linux-Server, NAS über VPN, Objektstorage über zusätzlichen Sync-Mechanismus.
Phase 5: Automatisiertes Backup
Empfohlen: tägliche vollautomatische Sicherung mit Logging und Offsite-Kopie.
sudo nano /usr/local/bin/yunohost-backup.sh
#!/bin/bash set -euo pipefail DATE=$(date +%F) LOGFILE="/var/log/yunohost-backup.log" YH_BACKUP="migration-backup-$DATE" SYS_BACKUP="/home/mayadm/server-full-backup-$DATE.tar.gz" echo "[$(date '+%F %T')] START backup" >> "$LOGFILE" yunohost backup create --system --apps --name "$YH_BACKUP" >> "$LOGFILE" 2>&1 tar -czf "$SYS_BACKUP" /etc /home /var/www >> "$LOGFILE" 2>&1 # Optional: Offsite Sync # rsync -avz /home/yunohost.backup/archives/ user@backupserver:/backup/yunohost/ >> "$LOGFILE" 2>&1 # rsync -avz "$SYS_BACKUP" user@backupserver:/backup/system/ >> "$LOGFILE" 2>&1 echo "[$(date '+%F %T')] END backup" >> "$LOGFILE"
Skript berechtigen
sudo chmod +x /usr/local/bin/yunohost-backup.sh
Cronjob einrichten
sudo crontab -e
0 2 * * * /usr/local/bin/yunohost-backup.sh
Ausführung: Täglich um 02:00 Uhr. Zeitpunkt an Wartungsfenster, IO-Last und Nutzeraktivität anpassen.
Phase 6: Monitoring & Alarmierung
| Alert | Trigger | Priorität |
|---|---|---|
| Backup fehlgeschlagen | kein neuer Logabschluss / Fehler im Skript | P1 |
| Backup älter als 48h | kein aktuelles Archiv vorhanden | P1 |
| Archivgröße unplausibel | starker Größenabfall gegenüber Vortag | P2 |
| Offsite-Sync fehlgeschlagen | rsync Exit-Code ≠ 0 | P1 |
| Disk fast voll | Speicherplatz > 85% | P1 |
sudo tail -n 100 /var/log/yunohost-backup.log sudo yunohost backup list du -h /home/yunohost.backup/archives/ df -h
Empfehlung: Netdata oder externes Monitoring auf Backupalter, Logfehler und Archivgröße ausrichten.
Phase 7: Restore-Test
Restore-Simulation auf Testsystem
| Schritt | Aktion | Ziel |
|---|---|---|
| 1 | neuen Debian-12-Testserver bereitstellen | saubere Zielplattform |
| 2 | YunoHost installieren | kompatible Basis |
| 3 | Backup übertragen | Archiv lokal verfügbar |
| 4 | Restore ausführen | vollständige Wiederherstellung |
| 5 | Funktionstests durchführen | Login, Upload, WebDAV, Mails, Webseiten |
scp migration-backup-YYYY-MM-DD.tar mayadm@TESTSERVER:/home/yunohost.backup/archives/ sudo yunohost backup restore migration-backup-YYYY-MM-DD --system --apps
sudo yunohost service status sudo yunohost app list sudo yunohost app shell nextcloud php occ status
Phase 8: Migration / Serverwechsel
Standardablauf für einen VPS-Wechsel:
- aktuelles YunoHost-Backup erstellen
- zusätzliches System-Archiv erzeugen
- beide Archive lokal und Offsite sichern
- neuen Debian-12-Server bereitstellen
- YunoHost installieren
- YunoHost-Backup restoren
- Dienste und DNS validieren
sudo yunohost backup restore migration-backup-YYYY-MM-DD --system --apps
Vor Cutover prüfen: Domains, TLS, nginx, Nextcloud-Login, WordPress-Frontend,
SOGo-Erreichbarkeit, Netdata-Funktion und Mailfluss.
Disaster Recovery (DR)
| Szenario | Recovery-Ansatz | Bemerkung |
|---|---|---|
| VPS-Ausfall | Restore auf neuem Server | Offsite-Kopie entscheidend |
| Datenkorruption | Rollback auf sauberes Backup | Version des Archivs wählen |
| Fehlkonfiguration | System-Archiv prüfen / selektiv wiederherstellen | besonders bei nginx, /etc |
| Provider-Ausfall | Offsite-Restore bei anderem Hoster | 3-2-1-Strategie erforderlich |
DR-Grundsatz: Ohne getestete Restore-Kette ist selbst ein vorhandenes Backup kein belastbares Recovery-Konzept.
date uptime free -h df -h sudo yunohost backup list sudo yunohost service status
Checklisten
Täglich / vor Changes
- freier Speicherplatz ausreichend
- letztes Backup erfolgreich
- Archivgröße plausibel
- Offsite-Kopie vorhanden
Monatlich
- Restore-Test auf Testsystem
- Backupskript und Cronjob validieren
- Offsite-Ziel prüfen
- RTO/RPO mit realem Test abgleichen
Anhang: Logpfade & Quick Commands
| Komponente | Pfade / Commands |
|---|---|
| YunoHost Backups | /home/yunohost.backup/archives/ • sudo yunohost backup list |
| System-Archiv | /home/mayadm/server-full-backup-*.tar.gz |
| Backup-Log | /var/log/yunohost-backup.log |
| Nextcloud Check | sudo yunohost app shell nextcloud • php occ status |
| Services | sudo yunohost service status |
| Speicherplatz | df -h • du -h /home/yunohost.backup/archives/ |
Autor: MayIT – YunoHost Backup & Restore Runbook