DecaTec

Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie

Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript

Nextcloud Logo

Mit dem Betreiben der eigenen Nextcloud gehen natürlich auch einige administrativen Pflichten einher. So sollte sowohl das Betriebssystem, als auch die Cloud-Software auf dem aktuellsten Stand gehalten werden.

Ein weiterer wichtiger Punkt, den man nicht außer Acht lassen sollte, sind Backups der eigenen Cloud. Leider gibt es hier kein fertiges Skript oder Plugin, welches alles automatisch erledigt – hier ist also etwas Handarbeit gefragt.

Der folgende Artikel zeigt Schritt für Schritt, wie sowohl Backups angefertigt, als auch wieder zurückgespielt werden können. Die Nextcloud-Dokumentation liefert bereits eine recht detaillierte Anleitung für das Anfertigen von Backups, als auch für die Wiederherstellung. Dennoch lässt sich das Vorgehen hier und da noch etwas optimieren und v.a. auch (per Skript) automatisieren.

Ausgangspunkt ist wie immer die im Tutorial Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban gezeigte Konfiguration.

Update-Historie
  • 23.09.2017:
    • Hinweis auf Anpassung der Verzeichnis-Berechtigungen entfernt. Dies wird seitens der Nextcloud-Dokumentation nicht mehr empfohlen (siehe hier).
  • 26.03.2018:
    • Hinweis für Debian, wenn sudo -u www-data nicht klappt.

Grundsätzliches Vorgehen

Eine komplette Nextcloud-Instanz besteht immer aus drei Teilen:

  • Das Web-Verzeichnis von Nextcloud (z.B. /var/www/nextcloud)
  • Das Daten-Verzeichnis (z.B. /var/nextcloud_data)
  • Die Nextcloud-Datenbank

Wenn Backups der eigenen Cloud angefertigt werden sollen, dann sind immer diese drei Teile zu berücksichtigen.

Mit welchen Mitteln das Backup angefertigt wird, ist dabei zunächst einmal egal. Im Rahmen des Artikels werden aber nur Programme verwendet, die auf einer normalen Installation eines Ubuntu Servers verfügbar sind.

Man sollte sich im Vorfeld nur Gedanken über den Speicherort des Backups machen. Hier macht es wenig Sinn, das Backup auf der gleichen Festplatte zu speichern, auf der auch Nextcloud installiert ist. Im Falle eines Festplatten-Ausfalls ist sowohl die Nextcloud-Instanz, als auch das Backup verloren.

Besser ist hier die Verwendung einer externen Festplatte oder eines Netzlaufwerks (z.B. auf einem NAS). Im Rahmen des Artikels gehe ich davon aus, dass das Verzeichnis der Backups /mnt/Share/NextcloudBackup lautet.

Hinweis für Debian: Wenn bei Befehlen die unter einem anderen User ausgeführt werden sollen (Webserver-User, www-data), könnte unter Debian das Problem auftauchen, dass dies mit sudo -u www-data <Befehl> nicht funktioniert. Hier erscheint dann eine Meldung wie „www-data ist unavailable“. In diesem Fall wurde bei der Installation von Debian ein Passwort für den Benutzer root vergeben und in Folge dessen das Programm sudo gar nicht installiert. Wenn man daher sudo nicht verwenden kann oder will, dann kann man einen Befehl aber auch auf andere Weise unter einem anderen User ausführen. In diesem Fall verwendet man anstatt sudo -u www-data <Befehl> einfach folgendes: su -s /bin/sh www-data -c „<Befehl>“

Backup erstellen

Um ein Backup zu erstellen, sollte die Nextcloud-Instanz zunächst in dem Maintenance-Mode versetzt werden. Das sorgt dafür, dass kein Benutzer aktiv auf der Cloud arbeiten kann.

cd /var/www/nextcloud 
sudo -u www-data php occ maintenance:mode --on

Als nächstes müssen das Hauptverzeichnis von Nextcloud gesichert werden. Dies ist im Normalfall unter /var/www/nextcloud zu finden (bitte den Punkt am Ende der Zeile beachten):

tar -cpzf /mnt/Share/Backups/Nextcloud/NextcloudBackup_FileDir_`date +"%Y%m%d"`.tar.gz -C /var/www/nextcloud .

Neben dem Nextcloud-Verzeichnis muss auch das Datenverzeichnis von Nextcloud mit in das Backup einfließen. Dieses sollte idealerweise außerhalb des Web-Verzeichnisses liegen (z.B. unter /var/nextcloud_data). Auch hist wieder ein Punkt am Ende des Befehls:

tar -cpzf /mnt/Share/Backups/Nextcloud/NextcloudBackup_DataDir_`date +"%Y%m%d"`.tar.gz -C /var/nextcloud_data .

Nun muss nur noch die Datenbank der Nextcloud-Installation gesichert werden. Dies geschieht mit folgendem Befehl:

mysqldump --single-transaction -h localhost -u nextcloud_db_user -p nextcloud_db > /mnt/Share/Backups/Nextcloud/NextcloudBackup_DB_`date +"%Y%m%d"`.sql

Nun ist das Backup komplett, so dass Benutzer wieder mit der Cloud arbeiten können. Daher wird der Maintenance-Modus wieder beendet:

cd /var/www/nextcloud 
sudo -u www-data php occ maintenance:mode --off

Backup zurückspielen

Ein Backup anzufertigen ist natürlich nur eine Seite der Medaille. Im Falle des Falles muss das Backup auch zurückgespielt werden können.

Vor der Wiederherstellung versetzen wir Nextcloud wie gewohnt in den Maintenance-Mode:

cd /var/www/nextcloud 
sudo -u www-data php occ maintenance:mode --on

Da wir hier ein komplettes Backup wieder einspielen, sollte der Webserver zunächst ein mal gestoppt werden:

service nginx stop

Vor der Wiederherstellung der Dateien der Cloud werden als erstes die entsprechenden Verzeichnisse gelöscht und neu angelegt. Dies sorgt dafür, dass keine Dateien aus dem Zustand vor dem Backup übrigleiben:

rm -r /var/www/nextcloud/
rm -r /var/nextcloud_data/

mkdir -p /var/www/nextcloud/
mkdir -p /var/nextcloud_data/

Nun gilt es zunächst das Nextcloud-Verzeichnis aus dem Backup wiederherzustellen. Da das Datum als Zeitstempel für das Backup diente, muss bei den folgenden Befehlen immer das korrekte Datum verwendet werden:

tar -xpzf /mnt/Share/Backups/Nextcloud/NextcloudBackup_FileDir_20170912.tar.gz -C /var/www/nextcloud/

Das gleiche wird mit dem Datenverzeichnis von Nextcloud durchgeführt:

tar -xpzf /mnt/Share/Backups/Nextcloud/NextcloudBackup_DataDir_20170912.tar.gz -C /var/nextcloud_data/

Anschließend werden die Verzeichnis-Berechtigungen noch einmal explizit gesetzt:

chown -R www-data:www-data /var/www/nextcloud 
chown -R www-data:www-data /var/nextcloud_data

Zum Schluss wird noch die Datenbank wiederhergestellt. Dazu wird zunächst die Datenbank entfernt und neu angelegt (für die Ausführung der Befehle muss das Passwort des Nextcloud-Datenbankusers angegeben werden):

mysql -h localhost -u nextcloud_db_user -p -e "DROP DATABASE nextcloud_db" 
mysql -h localhost -u nextcloud_db_user -p -e "CREATE DATABASE nextcloud_db"

Das Einspielen des Backups geschieht durch folgenden Befehl:

mysql -h localhost -u nextcloud_db_user -p nextcloud_db < /mnt/Share/Backups/Nextcloud/NextcloudBackup_DB_20170912.sql

Nun wird der Webserver wieder gestartet:

service nginx start

Zum Schluss muss noch ein Befehl abgesetzt werden, damit Nextcloud-Clients mitbekommen können, dass sich hier etwas durch das Wiederherstellen eines Backups verändert hat:

cd /var/www/nextcloud 
sudo -u www-data php occ maintenance:data-fingerprint

Zum Schluss wird Nextcloud wieder aus dem Maintenance-Mode geholt.

cd /var/www/nextcloud 
sudo -u www-data php occ maintenance:mode --off

Nach diesen Schritten wurde ein Backup von Nextcloud wiederhergestellt und es kann wieder mit der Cloud gearbeitet werden.

Backup/Restore mit Bash-Skript

Ein Backup kann mit diesen Schritten jederzeit manuell ausgeführt oder wiederhergestellt werden. Mehr Komfort erhält man jedoch, wenn man die auszuführenden Befehle in einem Skript zusammenfasst.

Auf diese Weise können Backups mit nur einem Befehl automatisiert angefertigt oder wiederhergestellt werden.

Zu diesem Zweck habe ich ein Codeberg Repository erstellt, welches die notwendigen Bash-Skripte enthält: 

Nextcloud-Backup-Restore @ Codeberg

Hinweis: Ich habe die Skript-Dateien als Open Source auf Codeberg zur Verfügung gestellt. Damit sind diese frei verfügbar und können auch von jedermann angepasst und verbessert werden. Ich übernehme allerdings keinerlei Haftung für den Einsatz dieser Skripte. Diese sollen lediglich als Basis für die Erstellung eigener Backup-Skripte für eure Nextcloud-Instanz dienen.

Zunächst werden die Skript-Dateien heruntergeladen. Dies passiert am besten als root-Benutzer in das entsprechende Home-Verzeichnis, da für die Ausführung der Skripte root-Rechte benötigt werden:

sudo -s
cd ~
wget https://codeberg.org/DecaTec/Nextcloud-Backup-Restore/raw/branch/master/NextcloudBackup.sh
wget https://codeberg.org/DecaTec/Nextcloud-Backup-Restore/raw/branch/master/NextcloudRestore.sh

Mit folgenden Befehlen werden die Dateirechte angepasst, so dass nur der Benutzer root Zugriff auf diese Dateien hat und diese auch ausführen kann:

chown root NextcloudBackup.sh
chown root NextcloudRestore.sh
chmod 700 NextcloudBackup.sh
chmod 700 NextcloudRestore.sh

Wichtig: Die Skripte sind nicht direkt ausführbar, sondern erfordern noch Anpassungen an die konkrete Server-Umgebung (Pfade, Benutzernamen, etc.)! Hinweise dazu sind auch in den Skript-Dateien hinterlegt.

Bitte führt diese Skripte nicht „blind“ auf eurem System aus, sondern versucht, die ausgeführten Befehle zu verstehen und entsprechend eurer Nextcloud-Installation anzupassen.

Wenn die Skripte angepasst wurden, können diese direkt ausgeführt werden:

./NextcloudBackup.sh

Das Backup wird automatisch im entsprechenden Verzeichnis, welches im Backup-Skript angegeben wurde, gespeichert (z.B. /mnt/Share/NextcloudBackups/20170912_073953).

Wiederhergestellt werden kann ein Backup durch das Restore-Skript. Dieses erwartet den Zeitstempel eines vorhandenen Backups als Parameter:

./NextcloudRestore.sh 20170912_073953

Die Skripts sind so konzipiert, dass diese keine Benutzereingaben erfordern. Dadurch kann die Ausführung von Backups auch einfach automatisiert werden. Per Cronjob ist es beispielsweise denkbar, dass täglich nachts um 03:00 automatisch ein Backup der Nextcloud-Instanz auf einem NAS gespeichert wird.

Fazit

Auf den ersten Blick ist das Anfertigen von Backups und ggf. die Wiederherstellung nicht weiter kompliziert. Trotzdem ist es wichtig, alle auszuführenden Schritte zu verstehen und genau zu befolgen.

Am Ende noch der wichtigste Tipp: Nichts ist ärgerlicher, als regelmäßig angefertigte Backups, die aber im Ernstfall nicht wiederhergestellt werden können! Daher sollte das ganze Vorgehen (Backups anfertigen und auch wieder zurückspielen) mindestens einmal durchgespielt werden – und das Ganze am besten, bevor eure private Cloud in den produktiven Betrieb übergeht.

Der Aufwand lohnt sicher aber: Wenn ihr sichergehen könnt, dass euer Vorgehen zum Erstellen und Wiederherstellen von Nextcloud-Backups im Ernstfall funktioniert, könnt ihr auch ruhigen Gewissens weitere Benutzer auf eure Cloud loslassen.

Weiterführende Artikel

Links

, , , , ,

Kommentare: 158

  • Wolfgang Schädler sagt:

    Hallo Jan,

    super Anleitung – meine Hochachtung.

    Ich hab dein Skript entsprechend meiner Umgebung angepasst.
    Backup funktioniert und wird auf einen gemounten Windows Laufwerk abgelegt.

    Beim Restore scheitere ich aber. Da bekomme ich die Fehlermeldung:

    ERROR: No Backup name to restore given, or wrong number of parameters! Usage: NextCloudRestore.sh ‚BackupDate‘ [‚BackupDirectory‘]

    Die Sicherung landet im /media/Backup/nextcloud Ordner.
    Ordner mit Datum/Uhrzeit wird angelegt.
    Was muss ich in der NextcloudRestore.sh angeben, damit er auf den richtigen Ordner zugreift?

    Vielen Dank schon mal.

    Gruß Wolle

    • Jan sagt:

      Hi Wolle,

      du musst eigentlich nur den Zeitstempel (=Ordner-Name des Backups) als Parameter an das Restore-Script übergeben, also z.B. ./NextcloudRestore.sh 20170912_073953
      Dazu muss dann im Restore-Script aber auch der Pfad angegeben werden, in dem alle Backups enthalten sind (Variable backupMainDir), so dass er mit dem Haupt-Backup-Verzeichnis plus dem Zeitstempel das konkrete Backup finden kann, welches wiederherzustellen ist.

      Gruß,
      Jan

      • Wolfgang Schädler sagt:

        Hallo Jan,

        super – hat gleich geklappt.
        Noch eine Frage zu deinem Skript. Inkrementel zu Sicherung geht hiermit wahrscheinlich nicht. Oder?
        So könnte man noch Speicherplatz einsparen und die Hardware geschont.

        Gruß Wolle

  • Wolfgang Schädler sagt:

    Ah, Nachtrag.

    Beim Restore kommt noch die Meldung:
    Deleting old Nextcloud data directory…
    rm: das Entfernen von ‚/media/myCloudDrive‘ ist nicht möglich: Das Gerät oder die Ressource ist belegt
    Done

    Wie kann ich das verstehen. Keine Zugriffsberechtigung evtl.?

    • Jan sagt:

      Hi,

      die Meldung besagt zunächst, dass das Verzeichnis noch in Verwendung ist. Ist das reine Nextcloud-Datenverzeichnis bei dir wirklich „/media/myCloudDrive“? Nicht, dass da noch eine Ordner-Ebene fehlt und er das ganze übergeordnete Verzeichnis löschen will. Das kann u.U. fatal sein.

      Gruß,
      Jan

  • Wolfgang Schädler sagt:

    Hey.

    ja das /media/myCloudDrive passt schon.
    Ist eine externe USB Festplatte auf der liegen die User Daten.

    Wenn jetzt bloss noch das automatischen mounten von einer Windows Freigabe funktionieren würde, dann wäre alles bestens soweit.

    Gruß Wolle

    • Jan sagt:

      Hi Wolle,

      die Skripte sind ja nur ein Anhaltspunkt und müssen auf jeden Fall an die jeweilige Umgebung angepasst werden. Hier ist es ja auch kein Problem, einen Samba-Share mittels mount -t cifs ... am Anfang des Skripts zu mounten und nach Erstellung des Backups mit umount ... wieder unzumounten.

      Gruß,
      Jan

  • Sven sagt:

    Hallo Jan,

    vielen Dank für die super Beschreibung.

    Habe gerade das Problem ein Auszug der Datenbank zu machen, wie Du beschrieben hast und erhalte dabei folgenden Fehler:

    „mysqldump: Error: ‚Access denied; you need (at least one of) the PROCESS privilege(s) for this operation‘ when trying to dump tablespaces“

    Hast Du diesen Fehler auch schon mal zu Gesicht bekommen?

    Ich habe zwar eine Lösung dieses Fehlers gefunden, aber bin mir nicht sicher ob dieser beim Zurückspielen des Backups Probleme machen wird. Folgende Lösung habe ich verwendet:
    „mysqldump –single-transaction –no-tablesspaces -h localhost -u nextcloud_db_user -p nextcloud_db > /mnt/Share/Backups/Nextcloud/NextcloudBackup_DB_`date +“%Y%m%d“`.sql

    Weitere Lösung den mysqldump durchzuführen wäre mit root als user .

    Viele Grüße
    Sven

    • Jan sagt:

      Hi Sven,

      nein, diesen Fehler hatte ich noch nie.
      Hat der entsprechende User „grant all“ Rechte auf die DB?
      Ansonsten spricht denke ich auch nichts dagegen, das mit root zu machen. Die Rechte an der DB müssen eben nach dem Zurückspielen wieder passen.

      Gruß,
      Jan

1 2 3

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.