Automatisieren Sie regelmäßige Nextcloud-Backups mit Restic und Cron

Für ein zuverlässiges Nextcloud-Backup pausieren Sie die Benutzeraktivitäten, exportieren Sie die Datenbank und verwenden Sie Restic, um diesen Export zusammen mit den Anwendungs- und Datenverzeichnissen zu sichern. Legen Sie den Vorgang in einem Skript mit Root-Rechten ab und planen Sie die Ausführung per Cronjob. Überprüfen Sie die Snapshots und führen Sie eine Testwiederherstellung durch, bevor Sie sich auf den Zeitplan verlassen.

Dieses Beispiel setzt einen Debian- oder Ubuntu-Server, eine direkte Nextcloud-Installation unter `/usr/local/bin` /var/www/nextcloud, ein separates Datenverzeichnis unter ` /srv/nextcloud-data/usr/local/bin` und MariaDB voraus. Ersetzen Sie diese Werte durch Ihre tatsächlichen Pfade und den Datenbanknamen. Die Schritte wurden im Oktober 2026 anhand des Nextcloud-Administrationshandbuchs (Version 35) und der Restic-Dokumentation (Version 0.19.1) überprüft.

Was muss ein Nextcloud-Backup enthalten?

Die Backup-Anleitung von Nextcloud nennt Konfiguration, Daten, Datenbank, Theme und alle benutzerdefinierten Apps als wichtige Bestandteile, die gesichert werden sollten. Das Sichern des gesamten Anwendungsverzeichnisses umfasst üblicherweise die Konfiguration und die mitgelieferten Apps. Prüfen Sie jedoch, ob sich benutzerdefinierte Apps, Themes oder das Datenverzeichnis an einem anderen Ort auf Ihrem Server befinden. Fügen Sie jeden einzelnen Pfad in den Restic-Befehl ein.

Der Wartungsmodus sperrt bestehende Sitzungen und verhindert neue Anmeldungen während der Datensicherung. Dadurch wird die Wahrscheinlichkeit von Änderungen an Datenbank und Dateien zu unterschiedlichen Zeitpunkten verringert, Nextcloud ist jedoch währenddessen nicht verfügbar. Bei großen Datenmengen empfiehlt es sich, den Auftrag in einem ruhigen Zeitfenster zu planen. Falls auf Ihrem Server externe Prozesse oder Skripte direkt in das Datenverzeichnis schreiben, sollten diese ebenfalls pausiert werden.

Die offizielle Backup-Anleitung von Nextcloud erläutert die Komponenten und die Optionen zum Exportieren der Datenbank. Dieses Verfahren verwendet MariaDB; für PostgreSQL, MySQL oder SQLite verwenden Sie die entsprechenden Befehle zum Sichern und Wiederherstellen im Datenbankabschnitt des Handbuchs .

Bereiten Sie Restic vor und schützen Sie seine Zugangsdaten.

Installieren Sie Restic und den MariaDB-Client über die vertrauenswürdige Paketquelle Ihrer Distribution. Wählen Sie ein Repository auf einer anderen Festplatte oder einem externen Backup-Ziel. Ein Repository, das nur auf dem Nextcloud-Server gespeichert ist, schützt nicht vor dem Verlust des Servers oder seines Speichers. Platzieren Sie das Repository nicht in einem der zu sichernden Verzeichnisse.

Restic verschlüsselt Repository-Daten, aber Sie benötigen das Repository-Passwort, um sie wiederherzustellen. Erstellen Sie eine Passwortdatei und bewahren Sie eine geschützte Kopie außerhalb des Servers auf, beispielsweise in einem sicheren Passwort-Manager. Geht das Passwort verloren, kann das verschlüsselte Repository nicht mehr gelesen werden. Vermeiden Sie es, das Passwort direkt in der Befehlszeile, im Cronjob oder in einem Skript anzugeben.

sudo install -d -m 700 /root/.config/restic
sudo install -m 600 /dev/null /root/.config/restic/nextcloud-password
sudo install -m 600 /dev/null /root/.config/restic/nextcloud.env

Speichern Sie das gewählte Restic-Passwort sicher in der Passwortdatei. Tragen Sie den Speicherort des Repositorys und den Pfad zur Passwortdatei in die Umgebungsvariablen-Datei ein.

RESTIC_REPOSITORY=/mnt/backup/nextcloud
RESTIC_PASSWORD_FILE=/root/.config/restic/nextcloud-password

Verwenden Sie für ein Remote-Backend die dokumentierte Repository-URL und die Zugangsdaten dieses Backends, die mit eingeschränkten Berechtigungen gespeichert sind. Restic dokumentiert die Repository-Einrichtung und die unterstützte Umgebungsvariable für die Passwortdatei in seinem Leitfaden zur Repository-Vorbereitung . Initialisieren Sie ein neues Repository nur einmal, nicht bei jedem Start.

set -a
. /root/.config/restic/nextcloud.env
set +a
restic init

Auch die MariaDB-Zugangsdaten müssen geschützt werden. Konfigurieren Sie eine für Root lesbare Client-Optionsdatei, z. B. /root/.my.cnfmit Datenbankbenutzername, Passwort und Hostnamen, und setzen Sie deren Berechtigungen entsprechend 600. Das folgende Skript übergibt diese Datei an den Prozess mariadb-dump, sodass das Datenbankpasswort nicht in den Prozessargumenten erscheint.

Erstellen Sie ein Backup-Skript, das Nextcloud wieder zum Dienst zurückbringt.

Speichern Sie Folgendes unter dem Namen /usr/local/sbin/nextcloud-restic-backup. Passen Sie die Parameter NC_DATA_DIRentsprechend DB_NAMEan config/config.php. Das Skript aktiviert den Wartungsmodus, exportiert MariaDB, sichert die Anwendung, die Daten und einen temporären SQL-Dump und deaktiviert den Wartungsmodus anschließend wieder, selbst wenn ein späterer Befehl fehlschlägt.

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

NC_DIR=/var/www/nextcloud
NC_DATA_DIR=/srv/nextcloud-data
DB_NAME=nextcloud
RESTIC_ENV=/root/.config/restic/nextcloud.env
DB_CNF=/root/.my.cnf

set -a
source "$RESTIC_ENV"
set +a
exec 9>/run/lock/nextcloud-restic.lock
flock -n 9 || exit 0

mountpoint -q /mnt/backup || {
  echo "Backup target is not mounted" >&2
  exit 1
}

install -d -m 700 /var/backups/nextcloud
STAGE_DIR=$(mktemp -d /var/backups/nextcloud/db.XXXXXX)
maintenance_on=0

cleanup() {
  if [[ "$maintenance_on" -eq 1 ]]; then
    sudo -u www-data php "$NC_DIR/occ" maintenance:mode --off ||
      logger -t nextcloud-restic "Could not disable maintenance mode"
  fi
  rm -rf "$STAGE_DIR"
}
trap cleanup EXIT
trap 'exit 130' INT
trap 'exit 143' TERM

sudo -u www-data php "$NC_DIR/occ" maintenance:mode --on
maintenance_on=1

mariadb-dump --defaults-extra-file="$DB_CNF"   --single-transaction --default-character-set=utf8mb4 "$DB_NAME"   > "$STAGE_DIR/nextcloud.sql"
test -s "$STAGE_DIR/nextcloud.sql"

restic backup "$NC_DIR" "$NC_DATA_DIR" "$STAGE_DIR" --tag nextcloud

Legen Sie Besitzverhältnisse und Berechtigungen so fest, dass nur root das Skript bearbeiten oder ausführen kann. Testen Sie es anschließend manuell während eines Wartungsfensters. Diese mountpointPrüfung verhindert, dass eine fehlende Sicherungsfestplatte unbemerkt ein großes Repository in das lokale Dateisystem des Servers schreibt. Falls sich Ihr Repository auf einem Remote-Server befindet und nicht lokal eingebunden ist, ersetzen Sie diese Prüfung durch eine zuverlässige Prüfung für Ihr Backend.

Überprüfen Sie Ihre Pfade vor dem ersten Start. Befindet sich der Datenordner bereits im Anwendungsverzeichnis /var/www/nextcloud, gehen Sie nicht davon aus, dass der Beispielpfad korrekt ist; verwenden Sie stattdessen das tatsächliche Datenverzeichnis aus der Nextcloud-Konfiguration. Stellen Sie außerdem sicher, dass benutzerdefinierte Apps oder Themes, die außerhalb des Anwendungsverzeichnisses gespeichert sind, explizit eingebunden werden.

Planen Sie den Cronjob und überprüfen Sie das Ergebnis.

Nach einem erfolgreichen manuellen Lauf fügen Sie einen Crontab-Eintrag im Root-Verzeichnis hinzu sudo crontab -e. Dieses Beispiel startet den Job täglich um 2:30 Uhr mit dem vollständigen Pfad des Skripts und protokolliert die Ausgabe zur Fehlerbehebung:

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

Cron bietet nur eine eingeschränkte Umgebung. Daher legt das Skript einen expliziten Ausführungszeitpunkt fest PATHund lädt die Restic-Einstellungen selbst. Stellen Sie sicher, dass Cron in Ihrer Distribution aktiviert ist und dass sich dieser Zeitpunkt nicht mit dem Hintergrundprozess von Nextcloud oder anderen Wartungsaufgaben überschneidet. Das Linux- Handbuch zur Crontab beschreibt das Format des Zeitplans und die von Cron bereitgestellte Umgebung.

Bestätigen Sie die erfolgreiche Ausführung des Jobs, indem Sie /var/log/nextcloud-restic.logauf einen erfolgreichen Abschluss prüfen und die letzten Snapshots auflisten:

sudo bash -lc 'set -a; source /root/.config/restic/nextcloud.env; set +a; restic snapshots'
sudo bash -lc 'set -a; source /root/.config/restic/nextcloud.env; set +a; restic check'

Restic checküberprüft normalerweise die Repository-Struktur. Ein vollständiger Datenlesevorgang dauert länger und kann bei einem Remote-Repository erhebliche Bandbreite beanspruchen. Planen Sie die Überprüfung daher restic check --read-dataregelmäßig oder nutzen Sie sie, um Teile der Daten im Laufe der Zeit zu prüfen. Weitere Informationen finden Sie in der Dokumentation zur Repository-Integrität--read-data-subset von Restic .

Eine Snapshot-Liste ist kein Wiederherstellungstest. Stellen Sie einen aktuellen Snapshot in einem separaten temporären Verzeichnis wieder her restic restore latest --target /tmp/nextcloud-restore-testund überprüfen Sie anschließend, ob die Anwendungsdateien, das Datenverzeichnis und der SQL-Dump vorhanden sind. Führen Sie keine Wiederherstellung auf einer laufenden Installation zu Testzwecken durch. Stellen Sie für eine tatsächliche Wiederherstellung die Dateien und die Datenbank als ein zusammengehöriges Set wieder her. Die Wiederherstellungsanleitung von Nextcloud beschreibt die Neuerstellung der Datenbank und die Anforderungen an die Client-Synchronisierung.

Diese Konfiguration ermöglicht wiederholbare, verschlüsselte Snapshots. Cron überwacht jedoch keine eigenen Fehler, und Restic legt Ihre Aufbewahrungsrichtlinie nicht fest. Überprüfen Sie das Protokoll oder konfigurieren Sie Benachrichtigungen für fehlgeschlagene Ausführungen, bewahren Sie eine separate Kopie der Repository-Zugangsdaten auf und testen Sie die Wiederherstellung regelmäßig. Ist das Wartungsfenster zu lang, verwenden Sie koordinierte Dateisystem-Snapshots und einen datenbankkonsistenten Export, der für Ihre Speicherplattform optimiert ist, anstatt sich ändernde Dateien live zu sichern.