So sichern Sie Nextcloud mit Restic und Cron

Beispielhaftes Szenario (hypothetisch): Jordan administriert einen kleinen Nextcloud-Server unter Ubuntu. Die Anwendungsdateien befinden sich in `/usr/ local /var/www/nextcloud/bin`, die Benutzerdateien in `/usr /srv/nextcloud-data/local/bin`, die Nextcloud-Datenbank wird von MariaDB verwaltet, und ein externer Linux-Host ist per SSH erreichbar. Jordan wünscht sich ein nächtliches Backup, das überprüft und wiederhergestellt werden kann, und nicht nur einen Cronjob, der fehlerfrei ausgeführt wird.

Dieses Beispiel bietet Jordan einen wiederholbaren Restic- und Cron-Workflow. Pfade, Dienstkonten, Datenbanknamen und Zeitplan sind Beispiele; ersetzen Sie diese durch die Werte Ihrer Installation. Die Befehle bedeuten nicht, dass diese Konfiguration auf einem realen Server ausgeführt oder getestet wurde.

Was ein brauchbares Nextcloud-Backup enthalten muss

Das bloße Kopieren eines Ordners kann dazu führen, dass Nextcloud wichtige Informationen zum Wiederherstellen von Dateien, Benutzern, Freigaben und Einstellungen verliert. Das aktuelle Nextcloud-Administrationshandbuch (Version 35) listet fünf Elemente auf, die erhalten bleiben müssen: das Konfigurationsverzeichnis, gegebenenfalls vorhandene benutzerdefinierte Apps, das Datenverzeichnis, das Theme-Verzeichnis und die Datenbank. Laut Wiederherstellungsanleitung sind die Datenbank, das Datenverzeichnis und die Konfigurationsdateien unerlässlich. Lesen Sie das entsprechende Handbuch für Ihre installierte Nextcloud-Version, bevor Sie das Beispiel anpassen.

Jordan sichert das gesamte Anwendungsverzeichnis inklusive Konfiguration, Apps und Themes sowie das separate Datenverzeichnis und einen Datenbank-Dump. Wenn Nextcloud Benutzerinhalte außerhalb des Anwendungsverzeichnisses speichert, ist außerdem eine separate Kopie jedes externen Speicherorts erforderlich /srv/nextcloud-data. Restic kann nur Pfade schützen, auf die der Sicherungsprozess zugreifen kann.

Die offiziellen Backup-Anweisungen von Nextcloud beschreiben den Wartungsmodus und die Datenbanksicherung. Die Wiederherstellungsanweisungen erläutern, warum die Datenbank und die Dateistruktur von einem kompatiblen Wiederherstellungspunkt stammen müssen.

1. Restic und seine Zugangsdaten vorbereiten.

Installieren Sie Restic von einer vertrauenswürdigen Paketquelle und stellen Sie sicher, dass es für das Konto verfügbar ist, unter dem der Auftrag ausgeführt wird. Das Beispiel geht davon aus, dass der Auftrag als Root ausgeführt wird, um die Nextcloud-Dateien und den Datenbank-Dump lesen zu können. Es verwendet ein entferntes SFTP-Repository, sodass ein Ausfall des Anwendungsservers von Jordan nicht auch die einzige Sicherungskopie löscht.

restic version

install -d -m 700 /root/.config/restic
install -d -m 700 /root/.config/nextcloud

Erstellen Sie ein sicheres Restic-Repository-Passwort und speichern Sie es /root/.config/restic/nextcloud-passwordmit Root-Zugriff. Bewahren Sie eine sichere Wiederherstellungskopie dieses Passworts an einem separaten Ort auf, getrennt vom Server und Repository. Restic verschlüsselt die Repository-Daten, aber der Verlust des Passworts kann diese verschlüsselten Backups unbrauchbar machen. Geben Sie das Passwort niemals direkt im Skript oder in der Cron-Zeile an.

Konfigurieren Sie den nicht-interaktiven SSH-Zugriff für das Backup-Konto auf dem Remote-Host und verifizieren Sie dessen Host-Schlüssel über einen vertrauenswürdigen Kanal. Legen Sie den unten angegebenen Speicherort des Repositorys auf ein Verzeichnis fest, in das das Konto schreiben kann:

export RESTIC_REPOSITORY='sftp:backup@vault.example.net:/srv/restic/nextcloud'
export RESTIC_PASSWORD_FILE='/root/.config/restic/nextcloud-password'
restic init

Initialisieren Sie ein Repository nur einmal. Die Restic- Anleitung zur Repository-Vorbereitung beschreibt die unterstützten Speichersysteme und die Initialisierung. Behandeln Sie die Passwortdatei und den SSH-Schlüssel als vertrauliche Zugangsdaten und beschränken Sie den Zugriff darauf.

2. Datenbank und Dateien auf einem kompatiblen Stand halten

Nextcloud empfiehlt den Wartungsmodus für Backups, da dieser neue Anmeldungen blockiert und bestehende Sitzungen sperrt, um Dateninkonsistenzen zu vermeiden. Der Befehl muss als HTTP-Benutzer ausgeführt werden; bei einer typischen Ubuntu-Installation ist dies der Benutzer „json“ www-data. Jordans Wartungsfenster dauert bis zum Abschluss des Datenbank-Dumps und des Restic-Backups, sodass Benutzer währenddessen nicht in Nextcloud arbeiten können.

Für MariaDB verwendet das Nextcloud-Handbuch die Methode ` mariadb-dump --single-transaction.`. Speichern Sie die Datenbankzugangsdaten in einer geschützten Client-Standarddatei, beispielsweise ` /root/.config/nextcloud/mariadb.cnf.`, anstatt ein Passwort in den Befehl einzubetten.

[client]
user=nextcloud_backup
password=REPLACE_WITH_A_SECRET
host=localhost

Beschränken Sie den Zugriff auf die Datei chmod 600 /root/.config/nextcloud/mariadb.cnf. Erstellen Sie ein Datenbankkonto mit nur den für Ihren Server und die Sicherungsprozedur erforderlichen Berechtigungen. Wenn Ihre Nextcloud PostgreSQL oder SQLite verwendet, verwenden Sie die dokumentierte Sicherungsmethode; führen Sie den MariaDB-Befehl nicht unverändert aus.

3. Erstellen Sie ein geschütztes Backup-Skript

Jordan speichert die folgende Datei /usr/local/sbin/nextcloud-restic-backupund macht sie ausführbar. Um überlappende Ausführungen zu vermeiden, verwendet es eine Sperre, aktiviert den Wartungsmodus vor dem Erstellen des Speicherabbilds, sichert das Speicherabbild zusammen mit den Anwendungs- und Datenverzeichnissen und versucht, den Wartungsmodus auch dann zu deaktivieren, wenn ein späterer Befehl fehlschlägt.

#!/usr/bin/env bash
set -Eeuo pipefail
umask 077
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

export RESTIC_REPOSITORY='sftp:backup@vault.example.net:/srv/restic/nextcloud'
export RESTIC_PASSWORD_FILE='/root/.config/restic/nextcloud-password'

NC_DIR='/var/www/nextcloud'
DATA_DIR='/srv/nextcloud-data'
DB_NAME='nextcloud'
DB_CNF='/root/.config/nextcloud/mariadb.cnf'
DUMP_DIR='/var/backups/nextcloud'
LOCK_FILE='/run/lock/nextcloud-restic-backup.lock'
STAMP=$(date -u +%Y%m%dT%H%M%SZ)
DUMP_FILE="$DUMP_DIR/nextcloud-$STAMP.sql"
maintenance_started=0

mkdir -p "$DUMP_DIR"
exec 9>"$LOCK_FILE"
flock -n 9 || { echo 'A Nextcloud backup is already running.' >&2; exit 1; }

finish() {
  result=$?
  trap - EXIT
  if [[ "$maintenance_started" == 1 ]]; then
    sudo -u www-data -- php "$NC_DIR/occ" maintenance:mode --off || result=1
  fi
  rm -f -- "$DUMP_FILE" || result=1
  exit "$result"
}
trap finish EXIT

sudo -u www-data -- php "$NC_DIR/occ" maintenance:mode --on
maintenance_started=1
mariadb-dump --defaults-extra-file="$DB_CNF" --single-transaction \
  --default-character-set=utf8mb4 --databases "$DB_NAME" > "$DUMP_FILE"
restic backup --tag nextcloud "$NC_DIR" "$DATA_DIR" "$DUMP_FILE"

Nach Überprüfung der Pfade erstellen Sie die ausführbare Datei mit Root-Rechten und im Wartungsmodus 700. Das Skript setzt voraus, dass die Installation www-dataMariaDB und die angegebenen Pfade verwendet; überprüfen Sie diese daher config/config.phpvorher anhand Ihrer Webserver-Konfiguration. Es wird außerdem davon ausgegangen, dass kein anderer Administrator den Wartungsmodus bereits aktiviert hat. Falls der Befehl, das Erstellen eines Dumps oder der Restic-Upload fehlschlägt, beendet sich die Shell mit einer Fehlermeldung, und der Trap versucht, den Dienst wiederherzustellen; überprüfen Sie die Protokolle, um dies zu bestätigen. Der Dump wird mit eingeschränkten Berechtigungen gespeichert und nach der Ausführung gelöscht.

Dieses einfache Verfahren sorgt dafür, dass die Website während des gesamten Restic-Scans und -Uploads nicht erreichbar ist. Bei großen Datenverzeichnissen kann dies zu lange dauern. Verwenden Sie stattdessen ein koordiniertes Datenbank-Dump und einen Speicher-Snapshot oder ein anderes anwendungskonsistentes Backup-Verfahren, sofern Ihr Dateisystem oder Ihre Speicherplattform dies unterstützt. Stellen Sie sicher, dass Datenbank- und Datei-Snapshot einen kompatiblen Zeitpunkt darstellen. Das unabhängige Kopieren einer laufenden Datenbank und eines sich ändernden Datenverzeichnisses kann zu einem Backup führen, das sich nur schwer wiederherstellen lässt.

4. Planen Sie den Job mit cron ein.

Nach erfolgreichem manuellem Durchlauf installiert Jordan das Skript und plant dessen Ausführung für einen ruhigen Zeitraum ein. Bearbeiten Sie als Root die Crontab-Datei des Root-Benutzers sudo crontab -eund fügen Sie Folgendes hinzu:

15 2 * * * /usr/local/sbin/nextcloud-restic-backup >> /var/log/nextcloud-restic.log 2>&1

Dieses Beispiel beginnt um 2:15 Uhr morgens gemäß der Cron-Zeitzone des Servers. Wählen Sie einen Zeitpunkt, an dem das Wartungsfenster akzeptabel ist. Da Cron eine kleinere Umgebung als eine interaktive Shell bietet, PATHverwendet das Skript explizite und absolute Pfade. Erstellen Sie die Protokolldatei mit restriktiven Berechtigungen und konfigurieren Sie die Protokollrotation oder leiten Sie die Ausgabe an den regulären Protokollierungsdienst Ihres Systems weiter. Die Cron-Planung startet lediglich den Auftrag; sie bestätigt weder den Abschluss der Sicherung noch die Funktionsfähigkeit einer Wiederherstellung.

5. Aufbewahrungsfrist festlegen und Ergebnis überprüfen

Nach einer erfolgreichen Datensicherung überprüft Jordan, ob ein Snapshot angezeigt wird:

restic snapshots --tag nextcloud
restic check

restic checkÜberprüft die Repository-Struktur. Ein periodischer Vorgang restic check --read-dataliest auch gespeicherte Daten und kann viel Netzwerk- und Festplattenzeit beanspruchen. Planen Sie ihn daher entsprechend der Repository-Größe und den Wiederherstellungsanforderungen. Im Restic- Leitfaden zur Snapshot-Aufbewahrung wird erläutert, dass das Löschen von Snapshots und das Entfernen nicht referenzierter Daten separate Vorgänge sind und dass das Entfernen nicht referenzierter Daten das Repository sperrt. Beginnen Sie mit einem Testlauf und einer Richtlinie, die Ihren Aufbewahrungsanforderungen entspricht.

restic forget --tag nextcloud --keep-daily 7 --keep-weekly 5 \
  --keep-monthly 12 --dry-run

Überprüfen Sie die vorgeschlagenen Snapshots, die gelöscht werden sollen. Wenn Sie zufrieden sind, löschen Sie sie --dry-runund fügen Sie neue hinzu --prune. Führen Sie die Bereinigung durch, sobald keine Konflikte mit der nächtlichen Datensicherung entstehen. Die angegebenen Aufbewahrungsfristen sind beispielhaft und keine allgemeingültige Richtlinie. Berücksichtigen Sie die gesetzlichen Aufbewahrungsfristen, den verfügbaren Speicherplatz und wie weit zurück Sie Daten wiederherstellen müssen.

Der aussagekräftige Test ist eine Wiederherstellungsübung. Stellen Sie einen aktuellen Snapshot in einem temporären Verzeichnis auf einem separaten System wieder her, nicht über Jordans Live-Nextcloud-Pfade:

restic restore latest --tag nextcloud --target /tmp/nextcloud-restore-check

Vergewissern Sie sich, dass der wiederhergestellte Verzeichnisbaum die erwartete Konfiguration, die Daten und den Datenbank-Dump enthält, und prüfen Sie repräsentative Dateien. Führen Sie für eine vollständige Wiederherstellung die Nextcloud-Wiederherstellungsanleitung in einer isolierten Umgebung durch und überprüfen Sie Anmeldung, Dateizugriff und erwartete Freigaben, bevor Sie sich auf das Verfahren verlassen. Die Wiederherstellungsdokumentation von Restic beschreibt die Auswahl von Snapshots und Wiederherstellungszielen.

Woran man erkennt, wann dieser Ansatz geändert werden muss

Jordans Cronjob eignet sich nur, wenn das Wartungsfenster der Backup-Dauer entspricht und alle benötigten Datenpfade lokal und lesbar sind. Ändern Sie das Design, sobald eines der folgenden Anzeichen auftritt:

• Die Website bleibt länger im Wartungsmodus, als es die Benutzer tolerieren können: Planen Sie koordinierte Snapshots oder eine andere anwendungskonsistente Methode.
• Die Protokolle weisen auf fehlende Pfade, Berechtigungsfehler, einen fehlgeschlagenen Datenbank-Dump oder einen Restic-Exit-Code ungleich Null hin: Beheben Sie diese Fehler, bevor Sie den Snapshot als abgeschlossen betrachten.
• Die Daten befinden sich auf einem externen Speicher oder auf einem anderen Server: Integrieren Sie eine regelmäßige Datensicherung in Ihren Wiederherstellungsplan.
• Bei einer Testwiederherstellung fehlen Dateien, Konfigurationen, Datenbankstatus oder erforderlicher App-/Theme-Code: Aktualisieren Sie die Backup-Eingaben und wiederholen Sie den Vorgang.
• Das Restic-Passwort oder die SSH-Zugangsdaten befinden sich nur auf dem Server, der gesichert wird: Bewahren Sie die Wiederherstellungszugangsdaten separat auf und stellen Sie sicher, dass ein autorisierter Administrator darauf zugreifen kann.

Für Jordan ist der Erfolg sichtbar: Das Cron-Log zeigt einen abgeschlossenen Lauf an, restic snapshotslistet einen kürzlich markierten Snapshot auf, Repository-Prüfungen melden keine Fehler, und eine Wiederherstellung stellt eine intakte Nextcloud-Instanz wieder her. Ein geplanter Befehl ist der Beginn einer Backup-Routine; nur ein vollständiger, wiederherstellbarer Satz von Datenbank-, Konfigurations-, Anwendungs- und Benutzerdaten bietet einen praktikablen Wiederherstellungspfad.

Offizielle Referenzen

• Nextcloud 35 Administrationshandbuch: Datensicherung
• Nextcloud 35 Administrationshandbuch: Wiederherstellen eines Backups
• Restic 0.19.1 Dokumentation