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.

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):

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:

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

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

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:

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

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:

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:

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

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

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):

Das Einspielen des Backups geschieht durch folgenden Befehl:

Nun wird der Webserver wieder gestartet:

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:

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

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. Durch die Anmeldung als root-Benutzer werden die Skripte im Home-Verzeichnis von root gespeichert. Dies macht Sinn, da für die Ausführung der Skripts root-Rechte benötigt werden:

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

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:

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:

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: 95

  • Niklas sagt:

    Hallo Jan,

    zunächst mal vielen Dank für deine großartigen Anleitungen :-)

    Leider hatte sich beim Ausführen deines Backup-Scripts bei mir ein Tippfehler eingeschlichen, wodurch das Daten-Verzeichnis lokal auf der viel zu kleinen SSD gesichert wurde. Dadurch sah ich mich dann gezwungen, dass Backup abzubrechen (Ctrl+C). Natürlich sollte anschließend der Maintenance-Modus ausgeschaltet werden, was mir auch als erfolgreich bestätigt wurde.

    Jedoch wurde der Maintenance-Modus wohl nicht nur ausgeschaltet, sondern die Installation gleich in den Installationsmodus geschickt. Offenbar wurde mindestens die config.php aus dem Installationsverzeichnis gelöscht. Zufall oder steckt mehr dahinter?

    Da das Installationsverzeichnis (filedir) bereits vollständig gesichert war, konnte ich dieses manuell wiederherstellen und meine Installation somit „retten“.

    Grüße

    Niklas

    • Jan sagt:

      Hi Niklas,

      das Backup-Skript löscht keine Dateien (außer alte Backups, wenn die Variable maxNrOfBackups ungleich 0 ist).
      Daher kann ich mir das Verhalten nicht so recht erklären. Weißt du zufällig noch, was da Skript zuletzt angezeigt hat, als du das Backup mit STRG+C abgebrochen hast (also bei welchem Schritt es gerade beschäftigt war)?

      Gruß,
      Jan

  • Klaus Baumann sagt:

    Hallo Jan,
    welches Format wähle ich am besten aus, um eine USB-HDD für das Backup zu formatieren. Ich möchte auch, wenn es geht die Daten unter Windows abrufen können. Google sagt NTFS. der andere sagt, es geht nur mit FAT32. Hast Du für mich einen Tipp?

    • Jan sagt:

      Hi Klaus,

      ext (4) geht unter Windows nicht. NTFS kann man zwar auch unter Linux nutzen, allerdings hat man hier und da einige Einschränkungen. V.a. ist das mit dem Setzen der Rechte wohl ein Problem. Mehr Infos dazu hier.
      Wenn du also mit den Einschänkungen von FAT32 leben kannst (z.B. keine Dateien größer 4 GB), dann würde ich für dieses Vorhaben vermutlich FAT32 wählen.

      Ein anderer Ansatz wäre, die Platte nur unter Linux zu nutzen und dementsprechend in ext4 zu formatieren. Anschließend wird dann eine Samba-Freigabe eingerichtet, so dass man auch mit Windows-Systemen Zugriff auf die Inhalte der Platte hat. Ist vielleicht eine gute Alternative.

      Gruß,
      Jan

      • Klaus Baumann sagt:

        Ach…schon Cool, wenn man jemanden kennt, der weiß, wie es geht. Leider bin ich zur Zeit in der Ausbildung und kann mich nur mit Worten für Deine Hilfe bedanken.
        VIELEN DANK

  • Francisco sagt:

    Hallo Jan,

    ich schließe mich an…. Super Anleitung.
    Hat mir schon 2x den Hintern gerettet.
    So nun zu meinem Anliegen,
    die Wiederherstellung!!
    Wie kann ich den Clients nun klar machen, daß es einen Unterschied zwischen ihren Datenstand und die des Servers gibt? In meinem Fall ca. 3 Tage. Gibt es eine solche möglichkeit?

    Gruß
    Francisco

    • Jan sagt:

      Hi Francisco,

      das kann man nicht „von außen“ steuern. Eigentlich sollte dies durch das Datum der letzten Änderung (z.B. einer Datei) zu ermitteln sein.
      Welche Problem hast du nun konkret an den Clients?

      Gruß,
      Jan

      • Francisco sagt:

        Hallo Jan,

        Probleme nur in so weit, dass die Daten auf den Clients aktueller sind als auf dem Server. Durch meine Dummheit sind mir 3 Tage an Daten (Bilder usw.) verloren gegangen. Dank deiner Beschreibung (Sicherung und Wiederherstellung) läuft nun wieder alles. Bis auf den kleinen Datenunterschied. Nun kann ich alle Mitarbeiter bitten ihre Daten manuell noch einmal hoch zu laden, aber wie das nun mal so ist…… :-)

        Gruß
        Francisco

        • Jan sagt:

          Hi Francisco,

          es gibt in den Sync Clients meist eine Option „Synchronisierung erzwingen“. Dann sollte das System eigentlich merken, dass die Dateien auf den Clients neuer sind als die Dateien in der Cloud. Vielleicht ist das ja schon ausreichend und es muss nichts manuell hochgeladen werden.
          Nutzt die Cloud im professionellen Umfeld?

          Gruß,
          Jan

          • Francisco sagt:

            Hallo Jan,
            ich würde sagen semi Professionell. Ca. 12 Mitarbeiter und div Firmenkunden die bei uns zwischenspeichern. Wie wir sagen — wir haben eine gewachsenen Struktur! .-)
            Es begann als ein Test und ist nun ein Teil des Ganzen geworden.
            So nun aber zu deiner Frage: „Das erzwingen“ brachte keinen Erfolg!
            Laut Datenbank sind keine Daten hinzugekommen durch diesen Versuch.
            Aber DANKE für deine Anregungen. Ich denke wir werden noch so ein bis zwei kleine Probleme in den nächsten Monaten bekommen. (liegt wohl in der Natur der Sache)

            Gruß
            Francisco

          • Jan sagt:

            Hi Francisco,

            hier könnte man dann noch mit dem OCC Befehl testen, ob sich etwas an der Situation ändert, siehe hier.
            Ich würde mal mit einem „cleanup“ beginnen und anschließend noch ein „scan“.

            Gruß,
            Jan

          • Francisco sagt:

            Hallo Jan,

            DANKE — werde ich wenn alle Sicherungen abgeschlossen sind, starten!

            Gruß
            Francisco

  • Bernd sagt:

    Hallo Jan,

    Ich habe die Nextcloud komplett neu nach deiner Anleitung aufgesetzt und wollte nun das Backup zurückspielen.

    Die Parameter habe ich alle angepasst und sing richtig.

    Leider gibt mir das Restore Script folgende Fehlermeldung aus:

    tar: ./BLABLA/files/Handy Backup/Bilder u. Videos/Camera/2018_13.jpg: Cannot open: No such file or directory
    tar: ./BLABLA/files/Handy Backup: Cannot mkdir: No space left on device

    Ich kann es mir nicht erklären… den auf der Platte ist noch massig Platz.

    Bei der Installation habe ich einfach 500GB LVM use entire Disk gewählt. (wie immer)

    Hast du evtl eine Ahnung woran das liegen könnte?

    Danke Gruß

    Bernd

  • Bastian sagt:

    Danke für da Script – Ist ein super Einstieg.

    Da ich allerdings meine nextcloud_data Verzeichnisse per smb eingehängt sind und diese schon auf andere weise gesichter werden, habe ich diesen Teil auskommentiert – ich hoffe das gibt auf dauer keine probleme

    • Jan sagt:

      Hi Bastian,

      wichtig ist hier, dass „alles in einem Rutsch“ gesichert wird: Maintenance-Mode an, alles sichern (wie auch immer), Maintenance-Mode aus.
      Wenn beide Sicherungen (NC und Samba) zu unterschiedlichen Zeitpunkten laufen, dann könnten Inkonsistenzen entstehen. Hintergrund ist, dass die Daten im Datenverzeichnis von NC auch noch über die NC-DB referenziert werden. Wenn DB-Backup und Dateisystem-Backup nicht zusammen passen, könnten nach einem Restore Dateien verschwunden sein (also nicht in der Web-UI angezeigt werden) oder „tote“ Einträge in der DB übrig bleiben.
      Eine Überlegung: Könntest du aus der Samba-Sicherung nicht das NC-Datenverzeichnis ausschließen und dies dann nur über das NC-Backup-Skript sichern?

      Gruß,
      Jan

      • Bastian sagt:

        Ich habe Freenas im Einsatz – auf diesem laufen die shares und die Sicherungen.
        Meine Nextcloud läuft ebendfalls auf dem Freenas in einer VM.

        Die Sicherung so umbiegen das Sie über NC gesichert wird wäre bestimmt möglich – nur warscheinlich sehr umfangreich.

        Wenn du möchtest kann ich dir mal mein aktuelles Backup script zusenden.

        Dieses sichert immer nur die differenz zum letzten Backup.

        —-

        Könntest du noch erläutern mit welchem Syntax ich den crontab -e füttern muss.

        Denn mit
        0 3 * * * ./NextcloudBackup.sh >/dev/null 2>&1
        klappts nicht

        • Jan sagt:

          Hi Bastian,

          kannst mir gern mal das Backup-Skript per Mail schicken, kann dir aber nicht versprechen, dass ich da eine zündende Idee habe. ;-)

          Wegen crontab: Ich denke mal, dass hier die Pfadangabe fehlt. Sachen wie „./dir/…“ funktionieren hier nicht, da muss der absolute Pfad rein, also z.B. „/home/user/scripts/NextcloudBackup.sh“.

          Gruß,
          Jan

          • Bastian sagt:

            Moin Jan,

            also leider funktioniert das auch nicht:
            0 3 * * * „/home/user/scripts/NextcloudBackup.sh“
            sowohl mit als auch ohne “ „

          • Jan sagt:

            Hi Bastian,

            seltsam, dann muss es wohl an etwas anderem liegen. Schau mal nach, zu welchem Fehler es beim Ausführen des Cronjobs kommt: grep CRON /var/log/syslog

            Gruß,
            Jan

  • Marvin sagt:

    Danke Jan für das Skript.
    Wenn ich bei {maxNrOfBackups} was anderes als 0 eingebe werden immer alle Backups inkl des aktuellen gelöscht.
    Schade.

    • Jan sagt:

      Hi Marvin,

      eigentlich sollte das schon funktionieren. Ich werd’s mir die Tage mal ansehen.
      Du kannst bei solchen Problemen/Fehlern auch übrigens einen Issue direkt auf GitHub anlegen.

      Gruß,
      Jan

      • Jan sagt:

        Hi Marvin,

        ich habe mir das nun nochmal genauer angesehen, aber konnte hier keinen Fehler feststellen.
        Was du mal ausprobieren könntest: geb die einzelnen Zeilen deines Scripts mal einzeln in die Kommandozeile ein. Es wäre wichtig zu wissen, bei welchem Schritt genau sämtliche Backups gelöscht werden.

        Gruß,
        Jan

  • Jürgen Fuchs sagt:

    Hallo Jan,

    die aktuelle NC-Dokumentation empfiehlt rsync als Bcakup-Tool, wohingegen du mit tar arbeitest.

    Gibt es dafür Gründe? Ich denke mit tar kann man immer nur vollständige Backups machen, was Zeit, Strom und Plattenplatz beansprucht.

    Gibt es Sicherheitsbedenken gegen ein differentielles Backup mit rsync? Ich denke, dass die Vereinshistorie, die NC von jeder Datei anlegt eine Wiederherstellung auch dann ermöglicht, wenn z.B. ein Verschlüsselungstrojaner meinen PC lahmgelegt hat. Oder?

    Vielen Dank und viele Grüße

    Jürgen

    • Jan sagt:

      Hi Jürgen,

      mit was du Kopien der Dateien anlegst, ist erst einmal egal, man könnte auch einfach nur cp verwenden. Ich nehme tar, damit die Dateien komprimiert werden.
      Das Differentielle mache ich dann noch über Bog Backup: Ich mache immer eine Komplettsicherung mit diesen Skripts und diese landen dann in einem Borg Repo. Borg dedupliziert sehr effizient, da brauche ich keine differentiellen Backups mittels rsync.

      Gruß,
      Jan

      • Jürgen Fuchs sagt:

        Hallo Jan, das klingt interessant, jedoch verstehe ich als Neuling nur Bahnhof. Gibt es irgendwo nähere Informationen zu dem Borg-Backup?

        Vielen Dank und viele Grüße

        Jürgen

        • Jan sagt:

          Hi Jürgen,

          ja, generelle Infos zu Borg gibt es hier.

          Die Lösung, die ich bevorzuge, ist jedoch „mehrschichtig“. Lokale Backups mittels Skripts (Nextcloud, FHEM, etc.) und Sichern dieser Backups mittels Borg.

          Vielleicht lohnt es sich hier, mal einen Blog-Artikel zu planen. ;-)

          Gruß,
          Jan

  • juergen sagt:

    Hallo Jan,

    habe leider Probleme oder eine Verständnisproblem beim backup. Backup vom We-Verzeichnis und Daten-Verzeichnis war kein Problem. Beim Backup der Datenbank erhalte ich immer folgende Fehlermeldung:

    juergen@owncloud:/var/www/nextcloud$ mysqldump –single-transaction -h localhost -u nextcloud_db_user -p nextcloud_db > /mnt/NextcloudBackup/NextcloudBackup_DB_date +"%Y%m%d".sql
    -bash: /mnt/NextcloudBackup/NextcloudBackup_DB_date +"%Y%m%d".sql: Keine Berechtigung

    • Jan sagt:

      Hi,

      hast du hier den richtigen User/Passwort eingegeben? Das muss der DB-User und das Passwort des Nextcloud-DB-Users angeben, welches du auch beim Setup von Nextcloud eingegeben hast.

      Gruß,
      Jan

      • juergen sagt:

        Hi Jan,

        bin kein Datenbamk-Experte ;-) Wenn ich das richtig sehe sind die beiden Optionen Benuter und Passwort: -u nextcloud_db_user -p nextcloud_db, nextcloud_db_user = user und nextcloud_db = passwort. D.h. beides ersetze ich durch die Namen die ich vergeben habe. Allerdings habe ich im Passwort Sonderzeichen, muss ich die irgendwie in Hochkommata etc. setzen?

        • Jan sagt:

          Hi,

          nicht ganz. „nextcloud_db“ ist der Name der NC-Datenbank.
          Das „-p“ sorgt dafür, dass er dich nach dem Absetzen des Befehls nach dem Passwort des DB-Benutzers („nextcloud_db_user“) fragt.

          Gruß,
          Jan

  • Stefan sagt:

    Danke für die Anleitung bzw das skript… Soweit würde es bei mir auch laufen. Nur hat die Sicherung nur um die 500MB – Die NC hat aber aktuell eine Auslastung von knapp 3TB. Wenn ich tar bzw gzip viel zutraue – aber da hakt es noch… Hast du eine Idee wo ich schauen könnte…

    Beim Database Backup hab ich mal mit ‚–all-databases‘ gespielt. Ha aber nichts am Ergebnis geändert…?!?!?!?!?!?!?!

    cu
    Stefan

1 2

Schreibe einen Kommentar

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