So richten Sie automatisierte Datenbank-Backups für den ownCloud-Server ein

Sie entdecken die Schwachstelle Ihres Backup-Plans im denkbar ungünstigsten Moment: Ein Upgrade schlägt fehl, eine Datenbanktabelle wird beschädigt oder ein Server fällt aus, und das einzige „Backup“ ist eine Kopie der Benutzerdateien. Das reicht für ownCloud Server nicht aus. Die Datenbank enthält kritische Anwendungsdaten wie Benutzer, Freigaben, Dateimetadaten und Konfigurationsdaten. Ein zuverlässiger Wiederherstellungsplan benötigt daher sowohl die Datenbank als auch die Dateien und Konfigurationen, die dem gleichen Zeitpunkt entsprechen.

Diese Anleitung zeigt eine praktische Methode zur Automatisierung von ownCloud-Datenbanksicherungen unter Linux. Sie beginnt mit einem manuellen Backup und endet mit einem geplanten, verifizierten Backup-Job. Die Beispiele konzentrieren sich auf MySQL/MariaDB, da ownCloud diese Datenbanken empfiehlt. Eine Variante für PostgreSQL ist ebenfalls enthalten. Die Befehle orientieren sich an der aktuellen Administrationsdokumentation von ownCloud Server 11.0 und berücksichtigen gleichzeitig die Unterschiede bei herkömmlichen Installationen ohne Docker.

Zunächst sollte man verstehen, was eine Datenbanksicherung nicht abdeckt.

Ein Datenbank-Dump ist nur ein Teil eines ownCloud-Backups. Die Backup-Dokumentation für ownCloud Server 11.0 listet die Datenbank zusammen mit dem Konfigurationsverzeichnis, dem Datenverzeichnis, gegebenenfalls Anwendungsverzeichnissen und benutzerdefinierten Designdateien auf. Das Datenverzeichnis kann auch Verschlüsselungsschlüssel enthalten, daher kann ein reines Datenbank-Backup nach einem vollständigen Speicherverlust keinen kompletten Server wiederherstellen.

Nutzen Sie die unten beschriebene Automatisierung zum Schutz Ihrer Datenbank, ergänzen Sie diese jedoch mit einer Dateisicherung oder einem Snapshot für die übrige ownCloud-Installation. Wenn Sie einen vollständig konsistenten Wiederherstellungspunkt benötigen, sollten Sie die Datenbanksicherung und die Dateisicherung im selben Wartungsfenster durchführen.

Schritt 1: Bestätigen Sie, welche Datenbank ownCloud verwendet.

Bevor Sie einen Backup-Befehl schreiben, ermitteln Sie Datenbanktyp, Host, Datenbankname und Benutzer. Bei einer klassischen ownCloud-Installation finden Sie diese Werte normalerweise in der Datei `/etc/local/bin/` config/config.php. Sie können die Systemkonfiguration auch mit dem ownCloud-Befehlszeilentool überprüfen. Zum Beispiel im ownCloud-Verzeichnis:

sudo -u www-data ./occ config:list system

Bei einer Docker Compose-Bereitstellung verwendet die aktuelle Dokumentation Befehle wie die folgenden:

docker compose exec owncloud occ config:list system

Achten Sie auf Werte wie dbtype, dbhost, dbname, und dbuser. ownCloud Server 11.0 unterstützt offiziell MySQL/MariaDB und PostgreSQL, wobei MySQL oder MariaDB für normale Bereitstellungen empfohlen werden.

Schritt 2: Erstellen Sie einen geschützten Sicherungsort

Erstellen Sie ein separates Verzeichnis, das nicht über das Web zugänglich ist. Die Root-Berechtigung ist eine sinnvolle Standardeinstellung, wenn der geplante Task über die Crontab des Root-Benutzers ausgeführt wird:

sudo mkdir -p /var/backups/owncloud-db
sudo chown root:root /var/backups/owncloud-db
sudo chmod 700 /var/backups/owncloud-db

Prüfen Sie den freien Speicherplatz mit df -h /var/backups/owncloud-db. Ein Backup-Job, der die Systemfestplatte unbemerkt füllt, kann einen zweiten Ausfall verursachen, während er versucht, den ersten zu verhindern.

Schritt 3: Datenbankzugangsdaten nicht in den Cron-Befehl einfügen

Tragen Sie das Datenbankpasswort nicht direkt in die Crontab-Zeile ein. Für MySQL oder MariaDB ist eine für Root lesbare Client-Optionsdatei einfach und funktioniert gut mit unbeaufsichtigten Jobs. Erstellen /etc/owncloud/db-backup.cnf:

[client]
user=ownclouduser
password=REPLACE_WITH_DATABASE_PASSWORD
host=localhost

Dann beschränke es:

sudo chown root:root /etc/owncloud/db-backup.cnf
sudo chmod 600 /etc/owncloud/db-backup.cnf

Verwenden Sie die tatsächlichen Werte aus Ihrer ownCloud-Konfiguration. Wenn sich Ihre Datenbank auf einem Remote-Server befindet, geben Sie den entsprechenden Host an. Das MySQL-Handbuch beschreibt Optionsdateien für Clientprogramme. Durch diese Vorgehensweise wird vermieden, dass das Passwort direkt in einem geplanten Befehl offengelegt wird.

Schritt 4: Führen Sie eine manuelle Datensicherung im Wartungsmodus durch.

Die offizielle Backup-Prozedur von ownCloud empfiehlt, den normalen Zugriff zu unterbinden und die Instanz vor dem Sichern der Datenbank in den Wartungsmodus zu versetzen. Für eine Docker Compose-Bereitstellung:

docker compose exec owncloud occ maintenance:mode --on

Für eine herkömmliche Installation aus dem ownCloud-Verzeichnis:

sudo -u www-data ./occ maintenance:mode --on

Der Wartungsmodus blockiert die normale Benutzeraktivität, während der Wiederherstellungspunkt erstellt wird. Daher sollte ein automatisierter Auftrag während einer Zeit mit geringem Datenverkehr ausgeführt werden und den Wartungsmodus immer deaktivieren, selbst wenn die Sicherung fehlschlägt.

Testen Sie bei MySQL oder MariaDB einen manuellen Dump:

sudo mysqldump   --defaults-extra-file=/etc/owncloud/db-backup.cnf   --single-transaction   --quick   owncloud   | gzip -c > /var/backups/owncloud-db/owncloud-db-$(date +%Y%m%d-%H%M%S).sql.gz

Die ownCloud-Dokumentation verwendet die Option `--stream` mysqldump --single-transaction. Die MySQL-eigene Referenz zu `mysqldump` erklärt, dass diese --single-transactionOption einen konsistenten Snapshot für transaktionale Tabellen wie InnoDB erstellt, ohne während des Dumps Tabellensperren zu halten. Die --quickOption `--stream` streamt Zeilen, anstatt eine große Tabelle im Speicher zu puffern.

Wenn die manuelle Datensicherung abgeschlossen ist, schalten Sie den Wartungsmodus mit dem entsprechenden Befehl aus:

docker compose exec owncloud occ maintenance:mode --off

oder:

sudo -u www-data ./occ maintenance:mode --off

Schritt 5: Implementieren Sie die Backup-Logik in einem ausfallsicheren Skript.

Das Skript soll bei Fehlern anhalten, einen Zeitstempel speichern, den Wartungsmodus aktivieren, einen Dump erstellen, die komprimierte Datei überprüfen, die Aufbewahrungsfristen anwenden und sicherstellen, dass der Wartungsmodus beim Beenden deaktiviert wird. Das folgende Beispiel geht von einer klassischen Installation /var/www/owncloudund einer MySQL/MariaDB-Datenbank mit dem Namen „“ aus owncloud.

#!/bin/bash
set -Eeuo pipefail

OC_ROOT="/var/www/owncloud"
BACKUP_DIR="/var/backups/owncloud-db"
DB_NAME="owncloud"
MYSQL_CNF="/etc/owncloud/db-backup.cnf"
STAMP="$(date +%Y%m%d-%H%M%S)"
OUT="$BACKUP_DIR/owncloud-db-$STAMP.sql.gz"

cleanup() {
  cd "$OC_ROOT"
  sudo -u www-data ./occ maintenance:mode --off || true
}
trap cleanup EXIT

mkdir -p "$BACKUP_DIR"
cd "$OC_ROOT"
sudo -u www-data ./occ maintenance:mode --on

mysqldump   --defaults-extra-file="$MYSQL_CNF"   --single-transaction   --quick   "$DB_NAME" | gzip -c > "$OUT"

test -s "$OUT"
gzip -t "$OUT"

find "$BACKUP_DIR"   -type f   -name 'owncloud-db-*.sql.gz'   -mtime +14   -delete

Speichern Sie die Datei /usr/local/sbin/owncloud-db-backup.sh, machen Sie sie mit `docker compose` ausführbar chmod 700und führen Sie sie anschließend manuell aus. Falls Ihre ownCloud in einem Container läuft, ersetzen Sie die beiden occZeilen durch die Docker Compose-Befehle für den Wartungsmodus, die zu Ihrer Bereitstellung passen.

Schritt 6: Mit cron planen

Nach erfolgreicher manueller Ausführung sollte das Skript eingeplant werden. Öffnen Sie die Crontab-Datei von root:

sudo crontab -e

Für einen täglichen Lauf um 2:15 Uhr:

15 2 * * * /usr/local/sbin/owncloud-db-backup.sh >> /var/log/owncloud-db-backup.log 2>&1

Wählen Sie einen Zeitpunkt, der Ihrem tatsächlichen Nutzungsverhalten entspricht. Bei großen Datenbanken sollten Sie zunächst die Dauer des manuellen Laufs messen, da der Wartungsmodus eine sichtbare Serviceunterbrechung verursacht. Stellen Sie außerdem sicher, dass Cron eine vorhersehbare Umgebung hat: Verwenden Sie absolute Pfade im Skript, falls die benötigten Befehle nicht in den Standardeinstellungen von Cron enthalten sind PATH.

Schritt 7: Überprüfen Sie jedes Backup, anstatt sich auf den Zeitstempel zu verlassen.

Eine Datei mit dem heutigen Datum ist kein Beweis für eine wiederherstellbare Sicherung. Überprüfen Sie mindestens, ob die Datei nicht leer ist, ob gzip keine Beschädigungen meldet und ob das Jobprotokoll keine Dump-Fehler enthält.

ls -lh /var/backups/owncloud-db/
gzip -t /var/backups/owncloud-db/owncloud-db-YYYYMMDD-HHMMSS.sql.gz
tail -n 100 /var/log/owncloud-db-backup.log

Für einen aussagekräftigeren Test stellen Sie ein aktuelles Datenbank-Dump in einer temporären Datenbank auf einem Nicht-Produktionssystem wieder her. Testen Sie die Wiederherstellung nicht, indem Sie Ihre Produktivdatenbank überschreiben. Eine realistische Wiederherstellungsübung prüft mehr als nur die Dateiintegrität: Sie bestätigt Anmeldeinformationen, Datenbankberechtigungen, die Kompatibilität des Dumps und das Wiederherstellungsverfahren, das Ihr Team tatsächlich anwenden würde.

Schritt 8: Bestätigen Sie, dass ownCloud wieder normal funktioniert.

Nach Abschluss des Skripts sollte der Wartungsmodus deaktiviert sein und Benutzer sich normal anmelden können. Überprüfen Sie die Weboberfläche und das Sicherungsprotokoll. Eine robuste Automatisierung erstellt nicht nur einen Speicherabbild, sondern verhält sich auch im Fehlerfall sicher und verhindert, dass der Dienst im Wartungsmodus blockiert wird.

Was ändert sich, wenn Sie PostgreSQL verwenden?

Die Backup-Dokumentation von ownCloud verwendet pg_dumpein Archivformat für PostgreSQL. Laut der offiziellen Dokumentation zu pg_dump von PostgreSQL wird dadurch pg_dumpein konsistenter Export erstellt, selbst während die Datenbank verwendet wird. Das Kapitel zu Backup und Wiederherstellung in PostgreSQL unterscheidet außerdem zwischen logischen Dumps, Dateisystem-Backups und kontinuierlicher Archivierung.

Ein einfacher, auf ownCloud ausgerichteter Befehl lautet:

PGPASSWORD="REPLACE_WITH_PASSWORD" pg_dump owncloud   -h localhost   -U ownclouduser   -F tar   -f /var/backups/owncloud-db/owncloud-db-$(date +%Y%m%d-%H%M%S).tar

Für die Automatisierung empfiehlt sich der von PostgreSQL unterstützte Passwortdateimechanismus anstelle der Einbettung PGPASSWORDin das Skript. Die Prinzipien für Wartungsmodus, Aufbewahrung, Protokollierung und Wiederherstellungstests bleiben unverändert.

Wie viele Backups sollten Sie aufbewahren?

Es gibt keine allgemeingültige Aufbewahrungsfrist für alle ownCloud-Server. Die Aufbewahrungsdauer sollte sich danach richten, wie schnell sich die Daten ändern, wie viel Speicherplatz verfügbar ist und wie weit zurück Sie Daten wiederherstellen müssen. Vierzehn tägliche Datenbank-Dumps sind ein sinnvolles Beispiel für einen kleinen Server, aber keine allgemeingültige Anforderung.

Abschließende Selbstprüfung

Ihre automatische Datenbanksicherung ist erst dann bereit, wenn alle folgenden Aussagen zutreffen:

• Sie wissen, ob der Server MySQL/MariaDB oder PostgreSQL verwendet und haben den korrekten Datenbanknamen und Host verifiziert.
• Das Backup-Verzeichnis ist geschützt und verfügt über ausreichend freien Speicherplatz.
• Die Anmeldeinformationen werden im Crontab-Befehl nicht offengelegt.
• Eine manuelle Datensicherung wird erfolgreich abgeschlossen, bevor die Zeitplanung aktiviert wird.
• Das Skript beendet den Wartungsmodus immer, auch nach einem fehlgeschlagenen Speicherabbild.
• Der geplante Job schreibt rechtzeitig ein Protokoll und erstellt ein nicht leeres Backup.
• Alte Mülldeponien werden gemäß einer festgelegten Aufbewahrungsrichtlinie entfernt.
• Ein kürzlich erstelltes Backup wurde erfolgreich in einer Nicht-Produktionsdatenbank wiederhergestellt.
• Die Datenbanksicherung wird mit Sicherungen der ownCloud-Daten, der Konfiguration und anderer erforderlicher Verzeichnisse kombiniert.

Wenn eine dieser Prüfungen fehlschlägt, beheben Sie den Fehler, bevor Sie sich auf die Automatisierung verlassen. Ein Backup-System ist nur dann sinnvoll, wenn der Wiederherstellungspfad getestet wurde.