Backup Nextcloud & Datenbank Grundinformationen

Änderungsstand: 2022-01-03

Grundinformationen Nextcloud-Backup

Ich stelle (vereinfacht) eine Backuplösung für Nextcloud und die dazugehörige Datenbank vor. Es wird erläutert, was alles für ein Nextcloud-Backup benötigt wird. Die Endlösung ist das nicht! Für ein Backup zwischendurch allerdings gut geeignet, falls man keine andere Möglichkeit verwenden möchte.

Ich verwende für meinen Test ein linuxserver/nextcloud und eine postgresql14 Datenbank. Die folgenden Befehle werden manuell gestartet. Verwendet man nicht linuxserver/nextcloud sondern nextcloud, werden einige Befehle, wie hier vorgestellt, nicht funktionieren (wie z.B. das Aktivieren und Beenden des Maintenance-Mode)! Des Weiteren verwende ich für meine „appdata“ eine Direktzuweisung (/mnt/cache/appdata) und nicht /mnt/user/appdata! Wer daraufhin keine Änderungen im Unraid vornahm, muss die Befehle auf /mnt/user/appdata anpassen!

Was sollte man zusätzlich beachten?

Hat man ein Backup verfügbar, ist man fürs Erste schon einmal relativ gut abgesichert. Aber es gibt Fallstricke, die es zu beachten gibt. Besonders bei einem Restore auf einem anderen System. Man sollte nach einem Restore immer die nextcloud-config-php im Auge behalten. Besonders, wenn auf einem Fremdsystem eine andere Server-IP-Adresse verwendet wird (manche verwenden Nextcloud nur für den internen Betrieb). Diese gilt es in diesem Fall anzupassen. Das gilt dann natürlich auch für die Dockererstellung. Das Restore auf einem Fremdsystem verkompliziert das Ganze etwas, wenn eine andere Server-IP-Adresse verwendet wird.
Es ist immer ratsam, ein komplettes Backup, von allen hier vorgestellten Sachen, zu haben. Es bringt nicht viel, wenn man nur die Datenbank sichert ohne die dazugehörigen Nextclouddaten oder Nextcloudinstallationsdateien. Wobei man das auch relativieren kann und es Restore-Möglichkeiten gibt. Aber darauf gehe ich vorerst nicht ein.

Welche Daten werden gesichert?

Eigentlich alles, was mit Nextcloud und Datenbank zu tun hat. In meinem einfachen Fall wären das:

Datenbank Dump-Befehl
Postgresql-Verzeichnis
Nextcloud-Konfigurationsverzeichnis
Nextcloud-Datenverzeichnis

Den verwendeten Dump-Befehl benötigte ich z.B., bei Verwendung von Docker, bisher noch nicht. Aber ich fühle mich durchaus besser, wenn ich diesen mit angelegt habe. Diesen Dump-Befehl könnte man sogar im laufenden Betrieb absolvieren. In meinem Beispiel mache ich das allerdings nicht.

Verwendet man Elsticsearch, sollte man dieses Verzeichnis auch mit sichern. Bei der Verwendung von Collabora und/oder Redis, ist eine Sicherung der Verzeichnisse nicht möglich. Da muss man allerdings beachten, dass bei einem Restore auch die Docker mit gestartet werden und die internen Nextcloud-Zuweisungen passen.

Zuerst erstelle ich das Backup-Verzeichnis:

Wie immer gilt, eigene Verzeichnisse zu verwenden.

sudo mkdir -p /mnt/user/backups/nc-backup

Ist dieses Verzeichnis schon vorhanden, wird der Befehl automatisch ignoriert (-p).

Backup Datenbank, per Dump-Befehl:

Maintenance-Mode AN (mein Docker heißt nextcloud-test):

sudo docker exec --user abc nextcloud-test php /config/www/nextcloud/occ maintenance:mode --on

Alle beinhalteten Datenbanken im postgresql14-Docker werden gesichert. Datenbank-Docker: postgresql14-test | Benutzer (root): nc

docker exec -t postgresql14-test pg_dumpall -c -U nc | gzip > /mnt/user/backups/nc-backup/dump_$(date +"%Y-%m-%d_%H_%M_%S").gz

Wurde der Befehl abgesetzt und erledigt, ist der Dump auch erstellt.

Nun sichere ich die restlichen Verzeichnisse. Dafür verwende ich rsync.

Datenbankverzeichnis sichern:

sudo rsync -aAxv --delete /mnt/cache/appdata/postgresql14-test/ /mnt/user/backups/nc-backup/postgresql14-test/

Quell-Verzeichnis, welches gesichert werden soll: /mnt/cache/appdata/postgresql14-test/
Ziel-Verzeichnis des anzulegenden Backups: /mnt/user/backups/nc-backup/postgresql14-test/

Nextcloud-Installationsverzeichnis sichern:

sudo rsync -aAxv --delete /mnt/cache/appdata/nextcloud-test/ /mnt/user/backups/nc-backup/nextcloud-test/

Nextcloud-Datenverzeichnis sichern:

sudo rsync -aAxv --delete /mnt/user/data/nextcloud-test-data/ /mnt/user/backups/nc-backup/nextcloud-test-data/

Maintenance-Mode AUS:

sudo docker exec --user abc nextcloud-test php /config/www/nextcloud/occ maintenance:mode --off

Die Backups wurden erstellt. Dank rsync werden bei wiederholtem Aufruf der einzelnen Befehle, die zu sicherten Dateien inkrementell gesichert. Das heißt, dass das erste Backup ziemlich lang dauern kann. Bei weiteren Backups werden nur die Daten geschrieben/geändert, die auch auf dem Quell-System eine Änderung bekamen. Der Abgleich des Datenbestandes dauert allerdings auch eine gewisse Zeit.

Nun das Ganze als Script verpackt und unter User Scripts hinzugefügt. Automatisieren werde ich das natürlich nicht. Das dient nur für den manuellen Start. Ich teste sehr viel mit Nextcloud. Warum eine andere Möglichkeit besser geeignet ist, erwähne ich am Ende.

#!/bin/bash
#############################
# Anzahl der erstellten Dumps festlegen:
BACKUP_ANZAHL="4"
#############################
## Wartungsmodus einschalten
# Dieser Befehl gilt nur für /linuxserver/nextcloud)
sudo docker exec --user abc nextcloud-test php /config/www/nextcloud/occ maintenance:mode --on
wait
echo "########################################"
echo "Nextcloud wurde gesperrt"
echo "########################################"
echo "Nextcloud-Backup wird erstellt"
## Backup-Verzeichnisse anlegen
# Wenn schon vorhanden, wird der Befehl automatisch ignoriert (-p)
sudo mkdir -p /mnt/user/backups/nc-backup
## Verzeichnisse sichern
# Nextcloud Datenverzeichnis
sudo rsync -aAx --delete /mnt/user/data/nextcloud-test-data/ /mnt/user/backups/nc-backup/nextcloud-test-data/
wait
echo "########################################"
echo "Backup Nextcloud-Datenverzeichnis erledigt"
echo "########################################"
echo "Backup Nextcloud-Installationsverzeichnis wird erstellt"
# Nextcloud Installationsverzeichnis
sudo rsync -aAx --delete /mnt/cache/appdata/nextcloud-test/ /mnt/user/backups/nc-backup/nextcloud-test/
wait
echo "########################################"
echo "Backup Nextcloud-Installationsverzeichnis erledigt"
echo "########################################"
echo "Backup Datenbank wird erstellt"
# Postgresql14 Installationsverzeichnis
sudo rsync -aAx --delete /mnt/cache/appdata/postgresql14-test/ /mnt/user/backups/nc-backup/postgresql14-test/
wait
echo "########################################"
echo "Backup Datenbank erledigt"
echo "########################################"
echo "Es wird zusätzlich ein >Dump< erstellt"
## Folgende Variablen ändern:
## Docker: postgresql14-test
## User: nc
docker exec -t postgresql14-test pg_dumpall -c -U nc | gzip > /mnt/user/backups/nc-backup/dump_$(date +"%Y-%m-%d_%H_%M_%S").gz
wait
echo "########################################"
echo ">Dump< erledigt"
echo "########################################"
## Unnötige Backups LÖSCHEN:
echo "Unnötige Backups werden entfernt"
echo "Die Anzahl der behaltenen Dumps wurde im Script hinterlegt"
#
pushd /mnt/user/backups/nc-backup &> /dev/null; ls -tr /mnt/user/backups/nc-backup/dump* | head -n -${BACKUP_ANZAHL} | xargs rm -f; popd &> /dev/null
#
echo "########################################"
echo "Unnötige Backups gelöscht"
echo "########################################"
## Wartungsmodus beenden
sudo docker exec --user abc nextcloud-test php /config/www/nextcloud/occ maintenance:mode --off
wait
echo "########################################"
echo "Nextcloud ist wieder verfügbar"

Nun habe ich ein Backup erstellt. Doch ganz so einfach, wie hier beschrieben, ist die Realität dann doch nicht 🙂 .

Das gilt ganz speziell für Nextcloud und die Datenbank. Ich stellte mir vor, wenn meine Datenbank, warum auch immer, abschmiert, dass ich dann im ungünstigen Fall, wenn ich das nicht gleich bemerke, eine defekte Datenbank als Sicherung habe. Das gilt natürlich auch für die Nextcloud-Konfigurationsdateien. Dann ist das ganze Backup soweit fast sinnlos. Eine andere Lösung musste her. Besser wären Backups, die z.B. Zeitbezogen (wie bei meinem verwendeten Dump-Befehl) erstellt werden. Am besten noch mit versehen Hardlinks im Backup, damit das Backup, im laufe der Zeit, nicht übermäßig groß wird. Ich habe ein Script gefunden, welches genau das erledigt. Hier gehts zum Guide.