Nextcloud sichern und wiederherstellen: Daten, Datenbank, Config

Ein Nextcloud-Server hält seinen Zustand an drei Stellen: im data-Verzeichnis, in der Datenbank und in /var/www/nextcloud/config/config.php. Sicherst du nur eine oder zwei dieser Ebenen, erhältst du im Ernstfall eine Instanz, die zwar startet, aber Dateien nicht mehr zuordnet oder verschlüsselte Inhalte nicht mehr entschlüsselt. Diese Anleitung zeigt den vollständigen Zyklus aus Sicherung, Wiederherstellung und Prüfung.

Was gehört zu einem vollständigen Nextcloud-Backup?

Ein vollständiges Nextcloud-Backup besteht aus vier Teilen: dem Installationsverzeichnis /var/www/nextcloud, dem data-Verzeichnis mit den Nutzerdateien, einem konsistenten Dump der Datenbank und der Datei config.php mit den Schlüsseln instanceid, passwordsalt und secret.

Das data-Verzeichnis liegt bei sauber aufgesetzten Installationen außerhalb des Webroots. Den tatsächlichen Pfad liest du aus der Konfiguration aus, statt ihn zu raten.

$ sudo grep -E "datadirectory|dbtype|dbname|dbuser" /var/www/nextcloud/config/config.php

Voraussetzungen

• Ein Linux-Host mit laufender Nextcloud-Instanz (Version 27 oder neuer), zum Beispiel eine skalierbare Cloud-VPS von centron
• sudo-Rechte und Kenntnis des Webserver-Benutzers (meist www-data, bei RHEL-Derivaten apache)
• Die Datenbank-Zugangsdaten aus config.php (dbuser, dbpassword, dbname)
• Ein Zielverzeichnis mit freiem Speicherplatz in der Größe von data plus Datenbank, hier /var/backups/nextcloud
• rsync und die Client-Tools der eingesetzten Datenbank (mariadb-client beziehungsweise postgresql-client)

Warum reicht das Kopieren des data-Verzeichnisses nicht?

Das Kopieren des data-Verzeichnisses reicht nicht, weil Nextcloud sämtliche Metadaten in der Datenbanktabelle oc_filecache hält: ohne passenden Datenbankstand sind die Dateien auf der Platte vorhanden, aber in der Weboberfläche unsichtbar.

Dazu kommt die Verschlüsselung. Ist die serverseitige Verschlüsselung aktiv, hängen die Schlüssel unter data/files_encryption an den Werten secret und passwordsalt aus config.php. Eine neu generierte config.php macht diese Dateien dauerhaft unlesbar. Sichere die Konfigurationsdatei deshalb immer im selben Lauf wie Daten und Datenbank.

Maintenance-Mode aktivieren

Setze die Instanz vor dem Backup in den Wartungsmodus. Nextcloud lehnt dann schreibende Zugriffe von Clients ab, sodass Dateisystem und Datenbank denselben Stand abbilden.

$ sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --on
Maintenance mode enabled

Der folgende Ablauf gilt für jeden Backup-Lauf, ob manuell oder per Timer:

graph TD
    A["Backup starten"] --> B["occ maintenance:mode --on"]
    B --> C{"Modus aktiv?"}
    C -- "nein" --> Z["Abbruch, Fehler prüfen"]
    C -- "ja" --> D["rsync: /var/www/nextcloud"]
    D --> E["rsync: data-Verzeichnis"]
    E --> F["Dump der Datenbank"]
    F --> G["config.php zusätzlich ablegen"]
    G --> H["occ maintenance:mode --off"]
    H --> I["Prüfsumme schreiben, Aufbewahrung anwenden"]

Dateien und Konfiguration sichern

Sichere Installations- und Datenverzeichnis mit rsync. Die Option -A überträgt ACLs, -x verhindert, dass rsync in eingehängte Fremd-Dateisysteme läuft.

$ sudo mkdir -p /var/backups/nextcloud/2026-08-17
$ sudo rsync -Aax --delete /var/www/nextcloud/ /var/backups/nextcloud/2026-08-17/app/
$ sudo rsync -Aax --delete /var/nextcloud/data/ /var/backups/nextcloud/2026-08-17/data/
$ sudo cp /var/www/nextcloud/config/config.php /var/backups/nextcloud/2026-08-17/config.php

Die separate Kopie der config.php ist Absicht. Sie liegt zwar bereits im app-Baum, aber als eigenständige Datei kannst du sie im Restore-Fall gezielt zurückspielen, ohne das gesamte Installationsverzeichnis anzufassen.

Bei mehreren Backup-Generationen lohnt --link-dest. Unveränderte Dateien werden dann als Hardlink auf den Vorlauf abgelegt statt erneut kopiert:

$ sudo rsync -Aax --delete --link-dest=/var/backups/nextcloud/2026-08-16/data/ \
    /var/nextcloud/data/ /var/backups/nextcloud/2026-08-17/data/

Backups gehören nicht auf dieselbe Maschine wie die Produktivdaten. Schiebe die fertigen Verzeichnisse anschließend auf einen zweiten Host oder in einen S3-kompatiblen Object Storage, damit ein Ausfall des Servers nicht auch die Sicherung mitnimmt.

Datenbank sichern

Für MariaDB und MySQL erzeugt mysqldump mit --single-transaction einen konsistenten Dump, ohne die Tabellen zu sperren. Das setzt InnoDB voraus, was Nextcloud ohnehin verlangt.

$ sudo mysqldump --single-transaction --default-character-set=utf8mb4 \
    -u nextcloud -p nextcloud > /var/backups/nextcloud/2026-08-17/nextcloud-db.sql

Mit PostgreSQL nutzt du pg_dump. Das Format custom ist komprimiert und lässt sich mit pg_restore selektiv einspielen:

$ sudo -u postgres pg_dump -Fc nextcloud \
    -f /var/backups/nextcloud/2026-08-17/nextcloud-db.dump

Komprimiere den SQL-Dump anschließend und schalte den Wartungsmodus wieder ab:

$ sudo gzip -9 /var/backups/nextcloud/2026-08-17/nextcloud-db.sql
$ sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --off

Backup-Skript automatisieren

Fasse die Schritte in einem Skript zusammen. set -euo pipefail sorgt dafür, dass ein fehlgeschlagener Dump nicht stillschweigend ein leeres Backup hinterlässt.

#!/usr/bin/env bash
# /usr/local/sbin/nextcloud-backup.sh
set -euo pipefail
NC_DIR="/var/www/nextcloud"
DATA_DIR="/var/nextcloud/data"
DEST="/var/backups/nextcloud/$(date +%F)"
OCC="sudo -u www-data php ${NC_DIR}/occ"
mkdir -p "${DEST}"
trap '${OCC} maintenance:mode --off' EXIT
${OCC} maintenance:mode --on
rsync -Aax --delete "${NC_DIR}/" "${DEST}/app/"
rsync -Aax --delete "${DATA_DIR}/" "${DEST}/data/"
cp "${NC_DIR}/config/config.php" "${DEST}/config.php"
mysqldump --single-transaction --default-character-set=utf8mb4 \
  -u nextcloud -p"${NC_DB_PASSWORD}" nextcloud | gzip -9 > "${DEST}/nextcloud-db.sql.gz"
find /var/backups/nextcloud -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +

Das Datenbankpasswort gehört nicht ins Skript. Lege es in einer nur für root lesbaren Datei ab und lade sie über die EnvironmentFile-Direktive der systemd-Unit:

$ sudo install -m 600 /dev/null /etc/nextcloud-backup.env
$ sudo systemctl edit --full --force nextcloud-backup.service

Ein systemd-Timer mit OnCalendar=*-*-* 02:30:00 und Persistent=true holt versäumte Läufe nach einem Reboot nach. Ein klassischer Cron-Eintrag tut es ebenfalls, protokolliert aber schlechter.

Nextcloud wiederherstellen

Stelle beim Restore immer alle drei Ebenen aus demselben Backup-Lauf wieder her. Ein Dateistand von Montag mit einer Datenbank von Dienstag führt zu Einträgen in oc_filecache, denen keine Datei entspricht.

Dateien zurückspielen

$ sudo systemctl stop apache2
$ sudo rm -rf /var/www/nextcloud
$ sudo rsync -Aax /var/backups/nextcloud/2026-08-17/app/ /var/www/nextcloud/
$ sudo rsync -Aax /var/backups/nextcloud/2026-08-17/data/ /var/nextcloud/data/
$ sudo cp /var/backups/nextcloud/2026-08-17/config.php /var/www/nextcloud/config/config.php
$ sudo chown -R www-data:www-data /var/www/nextcloud /var/nextcloud/data

Datenbank zurückspielen

Lege die Datenbank neu an, bevor du den Dump einspielst. Ein Import in eine bestehende Datenbank hinterlässt sonst Reste alter Tabellen.

$ sudo mysql -u root -p -e "DROP DATABASE IF EXISTS nextcloud; CREATE DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;"
$ sudo gunzip -c /var/backups/nextcloud/2026-08-17/nextcloud-db.sql.gz | sudo mysql -u root -p nextcloud

Unter PostgreSQL entspricht das dropdb nextcloud, createdb -O nextcloud nextcloud und anschließend pg_restore -d nextcloud nextcloud-db.dump.

Instanz wieder freigeben

$ sudo systemctl start apache2
$ sudo -u www-data php /var/www/nextcloud/occ maintenance:data-fingerprint
$ sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --off

maintenance:data-fingerprint setzt du nur, wenn du auf einen älteren Stand zurückgehst. Der Befehl signalisiert Desktop- und Mobile-Clients, dass der Serverzustand zurückgesetzt wurde, sodass sie beim nächsten Sync einen Konfliktdialog zeigen statt lokale Löschungen hochzuladen.

Verifikation

Ein Backup gilt erst als brauchbar, wenn ein Restore nachweislich funktioniert hat. Prüfe nach jedem Wiederherstellungstest drei Dinge:

$ sudo -u www-data php /var/www/nextcloud/occ status
  - installed: true
  - version: 29.0.4.1
  - maintenance: false
  - needsDbUpgrade: false
$ sudo -u www-data php /var/www/nextcloud/occ integrity:check-core
$ sudo -u www-data php /var/www/nextcloud/occ files:scan --all

integrity:check-core gibt bei einer intakten Installation keine Ausgabe zurück. files:scan --all gleicht das Dateisystem gegen oc_filecache ab und meldet die Zahl der geprüften Dateien pro Nutzer. Melde dich zusätzlich in der Weboberfläche an und öffne eine verschlüsselte Datei: nur das beweist, dass secret und passwordsalt korrekt zurückgespielt wurden.

Troubleshooting

mysqldump: Access denied; you need PROCESS privilege: Ab MySQL 8.0 sichert mysqldump standardmäßig Tablespace-Informationen. Hänge --no-tablespaces an oder gib dem Backup-Benutzer das Recht PROCESS.

Instanz bleibt nach dem Restore im Wartungsmodus: Setze in /var/www/nextcloud/config/config.php den Wert 'maintenance' => false, direkt und lade die Seite neu. Das ist der Ausweg, wenn occ selbst nicht mehr startet.

Dateien liegen auf der Platte, fehlen aber in der Oberfläche: Der Datenbankstand ist älter als das data-Verzeichnis. Spiele den passenden Dump ein oder lasse ersatzweise occ files:scan --all laufen, um die fehlenden Einträge neu aufzubauen.

Cannot decrypt this file: Die config.php stammt nicht aus demselben Backup wie data/files_encryption. Nur die originale Konfigurationsdatei mit dem ursprünglichen secret stellt die Lesbarkeit wieder her.

Fazit

Die drei Zustandsebenen Dateien, Datenbank und Konfiguration müssen aus einem gemeinsamen, im Wartungsmodus erzeugten Lauf stammen. Automatisiere den Ablauf per systemd-Timer, lege die Sicherung auf einem zweiten System ab und teste den Restore in festen Abständen auf einer separaten Instanz. Ein Backup, das nie zurückgespielt wurde, ist eine Annahme, keine Sicherung.

Weiterlesen

• Nextcloud aktualisieren: Updater, occ und Rollback-Plan
• Nextcloud All-in-One mit Docker installieren
• Nextcloud auf Ubuntu 24.04 mit nginx installieren
• Nextcloud mit Docker Compose betreiben
• Nextcloud Office einrichten: Collabora oder OnlyOffice
• Nextcloud, ownCloud oder Seafile: Welche Lösung wofür?
• Nextcloud per WebDAV einbinden: Linux, Windows, macOS
• Welcher Server für Nextcloud? RAM, CPU und Storage dimensionieren
• Was ist Nextcloud? Funktionsweise, Komponenten und Einsatz