App‑Backup vs. Server‑Backup
App‑Backup
Einige Apps bieten eigene Export‑ oder Backup‑Funktionen (z.B. Export von Kalendern, Kontakten oder einzelnen Datenbereichen).
Diese Sicherungen sind hilfreich für Teilbereiche, ersetzen aber niemals ein vollständiges System‑Backup, da sie nur App‑Daten betreffen und oft keine Konfiguration oder Berechtigungen vollständig abbilden.
Server‑Backup
Ein echtes Nextcloud‑Backup erfolgt immer auf Ebene des Servers bzw. der VM/Container: Dateisystem, Datenbank, Konfiguration und ggf. externe Mounts.
Nur so lässt sich die gesamte Instanz nach Hardware‑ oder Systemfehlern konsistent wiederherstellen.
Was gesichert werden muss: Files + DB + Config
Für eine vollständige Sicherung sind im Wesentlichen drei Bereiche entscheidend:
Dateien (Data‑Verzeichnis)
Das Nextcloud‑Datenverzeichnis enthält Benutzerdateien, App‑Daten und teilweise generierte Inhalte. Ohne dieses Verzeichnis fehlen später faktisch alle Nutzdaten.
Datenbank (MariaDB/MySQL/PostgreSQL)
Hier liegen Metadaten: Benutzer, Shares, App‑Einstellungen, Dateipfade, Versionen etc. Ohne die DB ist das Data‑Verzeichnis kaum sinnvoll nutzbar.
Konfiguration (config.php, Webserver/SSL)
Die zentrale Nextcloud‑Konfiguration (z.B. config/config.php) sowie Webserver‑ und Zertifikatseinstellungen sichern, damit Hostname, Trusted Domains, Pfade und externe Dienste nach einem Restore wieder korrekt funktionieren.
Im Idealfall werden alle drei Teile konsistent in einem Backup‑Lauf gesichert (z.B. Wartungsmodus, dann Files + DB‑Dump + Config).
Snapshot‑Strategien
Snapshots (z.B. auf VM‑ oder Storage‑Ebene) sind eine starke Ergänzung – nicht als alleinige Lösung.
Kurzfristige Snapshots
Vor größeren Updates (Nextcloud‑Version, Apps, Systempakete) einen Snapshot anlegen, um bei Problemen schnell auf den vorherigen Zustand zurückspringen zu können.
Kombination mit regulären Backups
Snapshots sind i.d.R. nur auf demselben Storage verfügbar und kein Ersatz für Offsite‑Backups. Sie dienen vor allem als schnelle Rollback‑Option, nicht als Langzeitarchiv.
Konsistenz beachten
Gerade bei Datenbanken sollte der Snapshot möglichst in einem definierten Zustand erstellt werden (z.B. kurz Wartungsmodus, DB‑Flush), damit keine inkonsistenten Stände entstehen.
Externe Speicher und Offsite‑Backups
Ein Backup, das auf demselben Host oder Storage liegt, schützt nicht vor Diebstahl, Brand oder Totalausfall.
Externe Speicherziele
Backups auf ein getrenntes Storage, NAS oder Backup‑System schreiben, das nicht dauerhaft beschreibbar gemountet ist (Stichwort Ransomware‑Schutz).
Offsite‑Backups
Mindestens eine Kopie regelmäßig an einen zweiten Standort (Rechenzentrum, andere Filiale, verschlüsselte Cloud‑Backup‑Lösung) übertragen.
Aufbewahrungsstrategie
Typisch ist eine Mischung aus täglichen, wöchentlichen und monatlichen Ständen (z.B. 7/4/12‑Schema), um auch ältere Zustände wiederherstellen zu können.
Restore‑Test als Pflichtpunkt
Backups sind nur so gut wie der letzte erfolgreiche Restore‑Test.
Regelmäßige Test‑Wiederherstellungen
In einer separaten Test‑Umgebung (andere VM, abgetrenntes Netzwerk) mindestens 1–2 Mal pro Jahr eine vollständige Wiederherstellung üben: Files + DB + Config.
Plausibilitätsprüfung
Nach dem Test‑Restore: Anmeldung prüfen, Dateien stichprobenartig öffnen, Shares testen, kritische Apps (Kalender, Deck, Tasks, Mail etc.) überprüfen.
Dokumentation
Den Ablauf und besondere Stolperfallen dokumentieren, damit im Ernstfall klar ist, welche Schritte nötig sind und wo Fallstricke liegen. Ein dokumentiertes, geübtes Restore‑Szenario ist letztlich das wichtigste Element der gesamten Backup‑Strategie – ohne diesen Test bleibt jede Sicherung ein ungedecktes Versprechen.