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
  • 02.12.2021:
    • Update des Fingerprints erst nach Deaktivierung des Maintenance Modes.
  • 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

Nun wird Nextcloud wieder aus dem Maintenance-Mode geholt.

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

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

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

188 Kommentare zu „Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript“

  1. Wolfgang Schädler

    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

    1. 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

      1. Wolfgang Schädler

        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

  2. Wolfgang Schädler

    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.?

    1. 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

  3. Wolfgang Schädler

    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

    1. 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

  4. 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

    1. 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

  5. Hallo Jan,

    ich hatte heute ein komisches Problem mit dem Backup-Skript. Ich habe eine externe HDD und lasse am Wochenende abends mal das Skript laufen. Heute war die HDD aber nicht gemountet, also die backupdir sozusagen leer. Die Sicherung ging dann einfach auf die Systemplatte, welche ziemlich schnell voll war und der Vorgang mit Fehlermeldungen beendet wurde.
    Dabei wurde die nextcloud config.php irgenddwie entfernt/überschrieben, sodass die Nextcloud nicht mehr installiert ẃar (Fehlermeldung: Es sieht so aus, als ob Du Nextcloud erneut installieren möchtest. Es fehlt jedoch die Datei CAN_INSTALL in Deinem Konfigurationsordner. Bitte erstelle die Datei CAN_INSTALL im Konfigurationsordner um fortzufahren.“).

    Ich verstehe nicht wie das passieren konnte. Ich habe mit dem Restore Skript ein älteres Backup des Nextcloud Verzeichnisses wiederherstellen können und jetzt geht wieder alles.

    Wie kann ich denn die Option im Skript ergänzen, dass das Backup nur starten soll, wenn im BackupDir auch die HDD gemountet ist?

    LG
    Samuel

    1. Hi Samuel,

      ja, wenn das Ziel des Backups nicht permanent verfügbar ist, dann sollte man vor dem eigentlichen Backup eine Prüfung einbauen, ob das Backup-Ziel überhaupt da ist.
      In deinem Fall kannst du ja einfach auf der externen HDD eine einfache Datei anlegen (test.txt). Vor der Ausführung des Backups kann das Skript dann prüfen, ob diese Datei vorhanden ist. Wenn das Laufwerk nicht gemountet ist, ist die Datei ja auf jeden Fall nicht da.

      Gruß,
      Jan

      1. Super Jan, vielen Dank, das ist es. Im Skript ist jetzt eingebaut, dass das Ziellaufwerk gemountet wird und dann noch geprüft wird ob die Testdatei da ist, also ob sie wirklich gemountet ist. Funktioniert!
        Am Ende des Skripts habe ich noch einen Befehl umount eingebaut.

        Warum es mir meine config.php zerschossen hat als das Skript ohne Ziellaufwerk HDD ausgeführt wurde habe ich iwie nicht verstanden.

        Danke Dir!
        Samuel

        1. Hi Samuel,

          perfekt!
          Warum er die config.php zerschossen hat, kann ich dir leider auch nicht sagen. Aber diese konntest du ja aus dem Backup wiederherstellen.

          Gruß,
          Jan

        2. Hallo Samuel,
          hallo Jan,

          herzlichen Dank für eure Lösung. Ich hatte gestern das gleiche Problem wie Samuel. Mein Backup hätte auf die externe USB-Platte per Cron-Job geschrieben werden sollen. Ich hatte die Platte aber nicht angesteckt und somit wurde meine interne Sytemplatte komplett vollgeschrieben: Verfügbar 0 Byte.
          Es war die gleiche Fehlermeldung und auch hier die config.php zerschossen/?umgeschrieben?.
          Aus dem Backup konnte auch ich die config.php wieder rüberkopieren, Mainzenance Mode off setzen und alles lief wieder.

          Aus vorherigen Problemen hatte ich hier schon gelernt. Bei mir ist immer ein Verzeichnis /platzhalter vorhanden in dem mehrere Dateien mit jeweils ein paar 100 MB liegen die ich sofort und ungefragt löschen kann, damit das System wenigstens wieder ein bischen „Arbeitplatz“ hat. Meist hat man vor solchen Fehlern ja gerade den Cache, Papierkorb etc geleert und sucht vergeblich etwas zum löschen, um dann auf Fehlersuche gehen zu können.

          @Samuel: mich würde interessieren wie du die Überprüfung, ob die USB-Platte drann ist, gelöst hast. Und auch wie du das mit dem Mount und Unmount eingebaut hast. – Magst du dein Script posten?

          Gruß
          Guido

          1. Hi Guido,

            ich mache das in diesen Fällen immer wie folgt. Ich lege auf der ext. HDD irgendwo einen beliebigen Ordner an, der dann nicht mehr gelöscht werden darf, z.B. /mnt/ext-hdd/mounted (wenn die HDD unter /mnt/ext-hdd gemountet wird). Seitens des Servers verhält es sich dann wie folgt: Platte gemountet – Ordner ist da; Platte nicht gemountet – Ordner fehlt.
            Das kann man dann ganz einfach anfragen:
            if [ ! -d "/mnt/ext-hdd/mounted" ]
            then
            echo "ERROR: External HDD not mounted
            exit 1
            fi

            In diesem Fall wird das Backup nicht ausgeführt, wenn die Platte nicht gemountet ist.

            Gruß,
            Jan

          2. Hi Guido,

            warum dabei die config.php beeinflusst wird weiß ich nicht.
            Ich habe folgenden Teil in das Backup Skript eingefügt:

            # Test ob Backup Ziel gemountet ist

            echo „Check availability of WD My Book“
            if [ -f /mnt/backup/backuptest.txt ]
            then
            echo „WD My Book is available“
            else
            errorecho „Error: You have to mount WD My Book“
            exit 1
            fi

            Hier ist wichtig, dass die Datei (backuptest.txt) nicht gelöscht werden kann, wie Jan schreibt. Das wars schon :)

            LG
            Samuel

    1. Hi,

      yes, the license is mentioned in the Codeberg repo. It’s an MIT license, so you can do what ever you want with these scripts.

      Best regards,
      Jan

  6. Hallo Jan,
    vielen Dank für die beiden Skripte. Ich habe sie für meine Ansprüche noch etwas angepasst.

    Im Restore Skript habe ich aber 2 Fehler gefunden.

    1. Der CompressionCommand zum entpacken ist falsch. In beiden Skripten (Backup/Restore) ist der Befehl: compressionCommand=“tar -I pigz -cpf“
    Im Restoreskript muss der Befehl: compressionCommand=“tar -I pigz -xvf“ heißen.

    2. Die Backtics (`) im Command des Restores für FileDir, DataDir & ExternalDataDir müssen rausgelöscht werden. Sonst kommt es beim Entpacken zu der Fehlermeldung „Is a directory“

    BSP:
    `$compressionCommand „${currentRestoreDir}/${fileNameBackupFileDir}“ -C „${nextcloudFileDir}“`

    Sonst gute Arbeit. Hat mir einiges an Nerven erspart.

    LG Marco

    1. Hi Marco,

      danke für den Hinweis. Das war tatsächlich ein Fehler im Script.
      Ich habe es korrigiert und auf Codeberg eine neue Version veröffentlicht.

      Allerdings kann ich nun deinen zweiten Punkt nicht (mehr) nachvollziehen. Die Backticks sind notwendig, da der eigentliche Command ja aus einer Variable kommen.
      Kannst du nochmal testen, ob es mit der neuen Version immer noch zu dem Fehler kommt?

      Gruß,
      Jan

    2. Entweder deute ich das falsch oder hier wird bei 1. etwas durcheinander gebracht.
      Im Restore Script gibt es kein compressionCommand, da hier doch nur extrahiert wird, folglich gibt es ein extractCommand. Aber auch dieser Aufruf steht nicht im Script sondern in der CONF:

      # TOOD: The bare tar command for using compression while backup.
      # Use ‚tar -cpzf‘ if you want to use gzip compression.
      compressionCommand=’tar -I pigz -cpf‘

      # TOOD: The bare tar command for using compression while restoring.
      # Use ‚tar -xmpzf‘ if you want to use gzip compression.
      extractCommand=’tar -I pigz -xmpf‘

  7. Hallo Jan
    Ich habe heute auf der Grundlage des aktuellen Skripts ein Backup durchgeführt. Dabei hat das Script folgende Meldung ausgespuckt:

    Updating the system data-fingerprint…
    Nextcloud is in maintenance mode, hence the database isn’t accessible.
    Cannot perform any command except ‚maintenance:mode –off‘

    Das Backup scheint trotzdem vollständig zu sein.
    Müsste ich mich sorgen?
    Danke für deine Rückmeldung und Arbeit!
    Grüsse Kurt

    1. Hallo Kurt,

      danke für den Hinweis. Habe eine neue Version der Scripts veröffentlicht, nun wird der Fingerprint erst nach der Deaktivierung des Maintenance-Modes upgedatet.

      Gruß,
      Jan

  8. Hi,

    habe folgendes Problem seit dem ich das neue Backup / Restore nutze incl. NextcloudBackupRestore.conf
    bekomme ich folgende Fehler beim Restore aber wie es ausieht wird der Restore trotzdem durchgeführt.

    15:05:59: Dropping old Nextcloud DB…
    could not change directory to „/root“: Permission denied
    DROP DATABASE
    Done

    15:05:59: Creating new DB for Nextcloud…
    could not change directory to „/root“: Permission denied
    CREATE DATABASE
    Done

    15:05:59: Restoring backup DB…
    could not change directory to „/root“: Permission denied

    Hat jemand eine Idee.

    Gruß

    Thomas

    1. Hi Thomas,

      woher dieser Fehler kommt (habe ich auch schon beobachten können), kann ich dir leider auch nicht beantworten, aber der Restore funktioniert.
      Daher kannst du diese Meldungen denke ich einfach ignorieren.

      Gruß,
      Jan

      1. Hallo Jan,

        vielen Dank für die Rückmeldung und hätte doch noch eine Frage, wäre es nicht Sinvoll auch Deine Beschreibung zu ändern. Da wie ich festgestellt habe kann man die jeweiligen Änderungen nur noch in der Config machen und nicht mehr direkt in den jeweiligen .sh Scripten.
        Hatte mich gewundert als ich nur die 2 Scripte wie beschrieben NextcloudBackup.sh / Nextcloudrestore.sh heruntergeladen habe und dort nur die Variablen gefunden habe. :-)

        1. Hi Thomas,

          das Problem dabei ist, dass die Skripte häufiger angepasst werden, da Open Source. Hier möchte ich eigentlich nicht immer auch den Artikel anpassen.
          Aber danke für den Hinweis, ich schau mal, ob ich da nicht noch was allgemeingültiges formulieren kann.

          Gruß,
          Jan

  9. Hallo Jan,
    ist vielleicht eine dumme Frage, aber schaffe ich es mit deinem script, eine komplette nextcloud 20 von einem ubuntu 20.04 wegzusichern und dann auf einen anderen ubuntu-server auf eine nextcloud 23 zu restoren?
    Ohne, dass alle clients wieder komplett neu synchronisieren müssen usw wenn der neue server die selbe IP/ dyndns hat?
    Danke und VG
    Martin

    1. Hi Martin,

      beim Backup und beim Restore muss es sich um die gleiche NC-Version handeln. Es wird ja immer die komplette Cloud gesichert, hier ist es nicht möglich, zwei unterschiedliche Clouds miteinander „zu verheiraten“.
      Hier muss also auf dem einen Server erst einmal das Update auf NC 23 durchgeführt werden, dann Backup und erst anschließend Restore auf dem neuen Server. Die Cloud auf dem neuen Server ist dann aber faktisch verschwunden und wurde durch die andere Cloud ersetzt.

      Gruß,
      Jan

  10. Hallo zusammen,

    bin gerade dran meine Nextcloud auf einem neuen Server mit bereits Stock installierter Nextcloud zu restoren, jedoch scheitert das Restore Script, hat jemand eine Idee?

    21:21:57: Restoring Nextcloud file directory…
    tar (child): pigz: Cannot exec: No such file or directory
    tar (child): Error is not recoverable: exiting now
    tar: Child returned status 2
    tar: Error is not recoverable: exiting now

    Verzeichnisse sind vorhanden und pigz installiert.
    Danke.

    1. Hi Max,

      das klingt für mich so, als wenn ein Verzeichnis „in der Kette“ nicht vorhanden ist. Also wenn du z.B. nach /var/www/nextcloud enpacken willst, aber /var/www ist (noch) nicht vorhanden.
      Zur Not kannst du auch alle Schritte des Scripts manuell nacheinander ausführen, das gibt meist bessere Hinweise, wo genau etwas nicht passt.

      Gruß,
      Jan

      1. Danke für die schnelle Antwort, das war auch erst meine Vermutung aber das Script per SSH auf dem Server direkt ausgeführt, Rechte passen auch. Manuell passiert das gleiche bei folgendem Befehl:
        tar -xpzf /var/www/backup/20220306_XXXX/nextcloud_FileDir.tar.gz -C /var/www/nextcloud/

        Stimmt der tar -xpzf Befehl an der stelle vielleicht nicht? Weiter oben schreibt jemand etwas dazu. Oder ist evtl. mein Backup inkonsistent?

        1. Hi Max,

          zum Extrahieren ist dies hier korrekt, wenn pigz eingesetzt wird: 'tar -I pigz -xmpf
          Anderweitig ist das: tar -xmpzf

          Versuch aber mal, den letzten Slash beim Pfad bei -C zu entfernen.

          Gruß,
          Jan

          1. Hi Max,

            also dieses tar (child): pigz: Cannot exec: No such file or directory weißt schon sehr stark darauf hin, dass er pigz nicht ausführen kann. Was gibt der Befehl which pigz bei dir aus?

            Gruß,
            Jan

          2. Mit deinem Kommentar konnte ich feststellen das etwas nicht mit dem pigz stimmt. Habe es neu installiert und dann hat es funktioniert.

            Vielen Dank für die sehr schnelle Hilfe und das super funktionierende Script.

  11. Hallo Jan,

    vielen Dank für das Backup-Script. Es läuft (mit kleinen Anpassungen an meine Situation) seit Jahren problemlos.

    Seit neuerem nutze ich die Kalender und Kontakt-Funktion unter Nextcloud. Anders als bei den synchronisierten Dateien gibt es jedoch für Kalender und Kontakte keine History. D.h. wenn ich einen Kontakt (irrtümlich) gelöscht habe, ist dieser für immer verloren. Es sei denn, ich stelle die gesamte Datenbank aus dem Backup-Scrip wieder her.

    Um Kontakte und Kalender im .vcf bzw. .ics Format zu sichern, hat Bernie O auf Codeberg

    https://codeberg.org/BernieO/calcardbackup/src/branch/stable/README_GER.md

    ein gut funktionierendes Script hinterlegt. Es ließ sich problemlos herunterladen und installieren. Die .vcf bzw. .ics Dateien lassen sich bei Bedarf ganz einfach wieder in der Nextcloud Kontakte- bzw. Kalender-App importieren.

    Ich denke, Berni hat hier ein gutes Stück Arbeit geleistet.

    Viele Grüße

    Jürgen

    1. Hi Jürgen,

      ja, das mit den Kontakten/Kalendern in der DB ist etwas blöd, wenn man mal was versehentlich gelöscht hat. Da macht sich sicher niemand die Mühe, die einzelnen DB-Einträge manuell wiederherzustellen.
      Das von dir erwähnte Tool kannte ich bereits, habe es aber noch nie aktiv genutzt.

      Auf jeden Fall danke für den Hinweis!

      Gruß,
      Jan

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht.