Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript

12. September 2017 / Home-Server / 243 Kommentare

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

20.03.2023:
- Hinweis hinzugefügt, dass die Skripte sich mit der Zeit ändern können und die aktuellste Version unter Codeberg zu finden ist.
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.
Ebenfalls können sich die Skripte mit der Zeit verändern, da diese ja weiterentwickelt werden. Daher ist das hier im Blog nur eine Momentaufnahme der Skripte. Die aktuellste Version inkl. Dokumentation ist immer nur auf Codeberg zu finden.

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

Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban

Links

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

Wolfgang Schädler
3. Februar 2021 um 6:12 Uhr

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

Antworten
1. Jan
  3. Februar 2021 um 8:20 Uhr
  
  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
  
  Antworten
  1. Wolfgang Schädler
    3. Februar 2021 um 13:16 Uhr
    
    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
    
    Antworten
    1. Jan
      3. Februar 2021 um 13:29 Uhr
      
      Hi,
      
      du könntest für einen Delta-Abgleich z.B. ähnlich wie her vorgehen und den Script-Aufruf nochmal in Borg Backup „verpacken“.
      
      Gruß,
      Jan
      
      Antworten
Wolfgang Schädler
3. Februar 2021 um 13:19 Uhr

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

Antworten
1. Jan
  3. Februar 2021 um 13:31 Uhr
  
  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
  
  Antworten
Wolfgang Schädler
3. Februar 2021 um 20:01 Uhr

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

Antworten
1. Jan
  4. Februar 2021 um 7:41 Uhr
  
  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
  
  Antworten
Sven
10. Februar 2021 um 22:59 Uhr

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

Antworten
1. Jan
  11. Februar 2021 um 6:24 Uhr
  
  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
  
  Antworten
Samuel
25. April 2021 um 1:06 Uhr

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

Antworten
1. Jan
  25. April 2021 um 9:39 Uhr
  
  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
  
  Antworten
  1. Samuel
    25. April 2021 um 14:04 Uhr
    
    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
    
    Antworten
    1. Jan
      26. April 2021 um 7:44 Uhr
      
      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
      
      Antworten
    2. Guido
      30. Dezember 2021 um 2:06 Uhr
      
      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
      
      Antworten
      1. Jan
        30. Dezember 2021 um 5:48 Uhr
        
        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. Samuel
        8. Januar 2022 um 16:33 Uhr
        
        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
prk0ghy
21. Juni 2021 um 12:28 Uhr

Vielen Dank für das Script, darf ich es denn verwenden? Aktuell hat es keine Lizenz.
Gruß
prk0ghy

Antworten
prk0ghy
21. Juni 2021 um 12:36 Uhr

Never mind, I found the license sometimes I wonder if I am blind.

Antworten
1. Jan
  21. Juni 2021 um 13:21 Uhr
  
  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
  
  Antworten
Marco
5. November 2021 um 21:29 Uhr

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

Antworten
1. Jan
  6. November 2021 um 9:14 Uhr
  
  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
  
  Antworten
2. Max
  7. März 2022 um 21:27 Uhr
  
  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‘
  
  Antworten
Kurt
1. Dezember 2021 um 16:11 Uhr

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

Antworten
1. Jan
  2. Dezember 2021 um 6:37 Uhr
  
  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
  
  Antworten
Thomas
11. Februar 2022 um 15:10 Uhr

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

Antworten
1. Jan
  11. Februar 2022 um 16:22 Uhr
  
  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
  
  Antworten
  1. Thomas
    14. Februar 2022 um 11:30 Uhr
    
    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. :-)
    
    Antworten
    1. Jan
      15. Februar 2022 um 8:14 Uhr
      
      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
      
      Antworten
Martin
1. März 2022 um 22:22 Uhr

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

Antworten
1. Jan
  2. März 2022 um 7:50 Uhr
  
  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
  
  Antworten
Max
7. März 2022 um 21:23 Uhr

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.

Antworten
1. Jan
  7. März 2022 um 22:05 Uhr
  
  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
  
  Antworten
  1. Max
    8. März 2022 um 15:58 Uhr
    
    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?
    
    Antworten
    1. Jan
      9. März 2022 um 17:28 Uhr
      
      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
      
      Antworten
      1. Max
        25. März 2022 um 16:41 Uhr
        
        Hm, daran lags leider nicht. :/
      2. Jan
        25. März 2022 um 18:54 Uhr
        
        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
      3. Max
        29. März 2022 um 21:46 Uhr
        
        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.
Jürgen
14. April 2022 um 8:27 Uhr

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

Antworten
1. Jan
  15. April 2022 um 10:39 Uhr
  
  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
  
  Antworten
gopher
26. Juli 2022 um 9:08 Uhr

Salue, super Anleitung, mir fehlt nur eines:
Konfigurationdes Nextcloud High Performance Backend für Dateien (App in Nextcloud)

Antworten
Marco
17. September 2022 um 11:37 Uhr

Hallo,
erst einmal vielen Dank für die super Anleitung(en).
Bei Problemen mit Nextcloud usw. bin ich meist zuerst auf deiner Seite.
Mach weiter so.
Ich habe die Skripte bei mir eingerichtet und funktionieren bisher ohne Probleme, zumindest die Backups. Restoren musste ich zum Glück bisher noch nicht.

Nun wollte ich gerne eine Information, ob das Backup erfolgreich erstellt oder wiederhergestellt worden ist. Oder auch wenn das nicht der Fall ist, also wenn es nicht erfolgreich war.
Dazu dachte ich an eine Information per Email.
Hast Du da evtl. schonmal was in der Richtung geschrieben oder dein Skript mit dieser Funktion erweitert?

Wird eigentlich bei deinem Skript eine Logdatei geschrieben?

Grüße Marco

Antworten
1. Jan
  18. September 2022 um 14:12 Uhr
  
  Hi Marco,
  
  Logdateien werden nicht geschrieben, das wäre evtl. mal eine Erweiterung.
  Im Prinzip aber ganz einfach, du definierst dir eine Logdatei (oben, wo die Variablen definiert werden):
  logFile="/pfad/zum/log/logfile.log"
  
  Dann leitest du den kompletten Output in das Logfile um (am besten direkt nach der Definition der Funktion errorecho):
  exec > >(tee -i "${logFile}") exec 2>&1
  
  Ganz am Ende kannst du dir die Inhalte des Logs per Mail schicken lassen:
  mail -s "NC backup finished" meine@email.de < "${logFile}"
  Dazu muss dann nur ein MTA auf dem System installiert sein, so dass die Mail auch geschickt werden kann, siehe dazu hier.
  
  Ich hoffe, dass dir das erst einmal weiter hilft.
  
  Gruß,
  Jan
  
  Antworten
Joachim
29. November 2022 um 17:00 Uhr

Moin!

Zunächst mal danke für das super Script. Einrichtung hat funktioniert, Backups werden auch erstellt. Restore habe ich jetzt noch nicht am Live System getestet. Aber mal eine Verständnisfrage. Wenn ich das Script NextcloudBackup.sh ausführe wir zunächst der Maintenance Modus aktiviert, danach der Webserver gestoppt. Stoppe aber der Webserver, dann wir auch die Wartungsseite der Nextcloud nicht angezeigt, wenn jemand den Server aufruft. Der bekommt die Fehlermeldung das die Seite nicht verfügbar ist. Sehe ich das richtig, oder habe ich einen Fehler in der Installation? Es handelt sich um eine frische Install mit Nextcloud 25 auf einer Ubuntu VM unter TrueNAS.

Antworten
1. Jan
  29. November 2022 um 18:47 Uhr
  
  Hi Joachim,
  
  das Verhalten ist ganz normal. Das Abstellen des Webservers ist zwar nicht zwingend erforderlich, aber so wird zu 100% sicher gestellt, dass niemand mehr auf der Cloud arbeitet. Daher baue ich diesen Schritt immer mit ein.
  
  Gruß,
  Jan
  
  Antworten
  1. Joachim
    30. November 2022 um 13:25 Uhr
    
    Moin Jan,
    
    danke für die schnelle Rückmeldung. Das heißt theoretisch kann ich im Script das Abschalten des Webservers deaktivieren in dem ich die folgenden Zeilen im Script auskommentiere
    echo „$(date +“%H:%M:%S“): Stopping web server…“
    systemctl stop „${webserverServiceName}“
    echo „Done“
    
    Was soweit auch funktioniert, der Webserver läuft weiter, allerdings wird scheinbar der Wartungsmodus nicht aktiviert, obwohl ich eine Meldung erhalte, das dieser jetzt aktiv ist. Die Login Seite der Cloud ist aber weiterhin erreichbar. Das sollte so nicht sein.
    
    Antworten
    1. Jan
      30. November 2022 um 16:46 Uhr
      
      Hi Joachim,
      
      ja, der Wartungsmodus scheint meistens nicht direkt umgesetzt zu werden, wenn man diesen ändert. Mir ist das z.B. schon nach NC-Updates aufgefallen: Hier wird man ja auch gefragt, ob man den Wartungsmodus beibehalten möchte. Wenn man hier „nein“ wählt und dann die Cloud öffnet, ist der Wartungsmodus meistens noch eine Zeit lang aktiv.
      
      Ich würde hier mal einen Neustart des Webservers nach dem Setzen des Wartungsmodus ausprobieren.
      
      Gruß,
      Jan
      
      Antworten
      1. Joachim
        3. Februar 2023 um 10:54 Uhr
        
        Moin Jan,
        
        nachdem ich nun meinen Umbau von TrueNAS abgeschlossen hatte, habe ich eine Ubuntu 22.04 VM auf einem eigenen Festplatte Pool neu installiert.
        In der VM läuft jetzt eine neu installierte Nextcloud Version, mit der Backup Funktion aus der alten die Daten übernommen, was super funktioniert hat. Habe mich dann noch mal mit dem Maintenance Mode beschäftigt. Im Script habe ich den Stop des Webservers angeschaltet und dann die Sicherung gestartet. Siehe da beim Aufruf der Website ist der Wartungsmodus aktiv.
        
        Entweder wurde da bei einem Update seitens Nextcloud was verändert oder es lag tatsächlich an der vorhandenen Installation.
        
        Sicherung auf eine SMB Freigabe im zweiten Platten Pool funktioniert auch super, jetzt muss ich nur noch den CronJob ans Laufen bringen, dann bin ich zufrieden mit dem System.
      2. Jan
        3. Februar 2023 um 17:27 Uhr
        
        Hi Joachim,
        
        das klingt alles super.
        Aber Stoppen des Webservers und Maintenance-Mode sind zwei getrennte Schritte. Der Maintenance-Mode sollte bei einem Backup auf jeden Fall an sein.
        
        Gruß,
        Jan
      3. Joachim
        4. Februar 2023 um 18:57 Uhr
        
        Der Wartungsmodus ist jetzt an, das war eben vorher das Problem. Der Webserver Dienst wurde ja im Script gestoppt, beim Aufruf ist dann die Seite nicht mehr erreichbar.
        Beim ersten Mal habe ich nur den Stop des Webservers aus dem Script entfernt, aber der Wartungsmodus war nicht aktiv. Man konnte sich normal anmelden und arbeiten. Das ist jetzt nicht mehr. Der Wartungsmodus ist aktiv, so wie es sein soll.
        Kannst du mir aber einen Tipp geben, warum mein Cronjob nicht funktioniert?
        Ich habe die Scripte im root home unter Nextcloud-Backup-Restore abgelegt. Den Cronjob mit cronjob -e angelegt und folgendem Befehlszeilen
        0 2 * * * /home/root/Nextcloud-Backup-Restore/NextcloudBackup.sh > /mnt/ncbackup/logs/Nextcloud-Backup-$(date +\%Y\%m\%d\%H\%M\%S).log 2>&1
        
        Sollte eigentlich so passen, aber leider wird der Job nicht ausgeführt.
      4. Jan
        5. Februar 2023 um 13:45 Uhr
        
        Hi Joachim,
        
        der Crontab sieht eigentlich gut aus. Was passiert, wenn du kompletten Befehl (/home/root/Nextcloud-Backup-Restore/NextcloudBackup.sh > /mnt/ncbackup/logs/Nextcloud-Backup-$(date +\%Y\%m\%d\%H\%M\%S).log) manuell auf der Kommandozeile ausführst?
        
        Gruß,
        Jan
      5. Joachim
        6. Februar 2023 um 9:04 Uhr
        
        Hi Jan,
        
        führe ich den Befehl wie folgt manuell aus, wird jetzt ein Backup angelegt, Wartungsmodus ist aktiv.
        
        Nextcloud-Backup-Restore/NextcloudBackup.sh > /mnt/ncbackup/logs/Nextcloud-Backup-$(date +\%Y\%m\%d\%H\%M\%S).log
        
        Werde jetzt den Cronjob noch mal so anpassen und schauen ob er heute Nacht Sicherung erstellt.
      6. Joachim
        7. Februar 2023 um 7:03 Uhr
        
        Tadaaaaaa…
        
        kaum macht man es richtig, klappt es auch!
        
        Backup directory: /mnt/ncbackup
        02:00:01: Set maintenance mode for Nextcloud…
        Maintenance mode enabled
        Done
        
        02:00:03: Creating backup of Nextcloud file directory…
        Done
        
        02:01:18: Creating backup of Nextcloud data directory…
        Ignoring Nextcloud updater backup directory
        Done
        
        02:13:28: Backup Nextcloud database (MySQL/MariaDB)…
        Done
        
        02:13:29: Switching off maintenance mode…
        Maintenance mode disabled
        Done
        
        DONE!
        02:13:31: Backup created: /mnt/ncbackup/20230207_020001
      7. Jan
        8. Februar 2023 um 18:19 Uhr
        
        Hi Joachim,
        
        ok, dann war es doch irgendwie ein Fehler im Skript oder so?
        Freut mich auch jeden Fall, dass es nun bei dir funktioniert.
        
        Gruß,
        Jan
      8. Joachim
        13. Februar 2023 um 12:32 Uhr
        
        Der Fehler lag in der Pfadangabe vom Cronjob
        
        ich hatte zunächst die folgende Pfadangabe drin:
        /Nextcloud-Backup-Restore/NextcloudBackup.sh > /mnt/ncbackup/logs/Nextcloud-Backup-$(date +\%Y\%m\%d\%H\%M\%S).log
        
        richtig muss es aber lauten:
        Nextcloud-Backup-Restore/NextcloudBackup.sh > /mnt/ncbackup/logs/Nextcloud-Backup-$(date +\%Y\%m\%d\%H\%M\%S).log
        
        Damit klappt es dann ohne Probleme.
      9. Jan
        15. Februar 2023 um 19:33 Uhr
        
        Hi Joachim,
        
        echt, der weggelassene Slash am Anfang ist dafür verantwortlich?
        Pfadangaben in der Crontab müssen immer „voll qualifiziert“ angegeben werden, daher hätte ich da einen Slash am Anfang erwartet, z.B. sowas wie /root/scripts/Nextcloud-Backup-Restore/....
        
        Aber super, dass es nun bei dir klappt.
        
        Gruß,
        Jan
Markus
27. Dezember 2022 um 12:40 Uhr

Guten Morgen Jan,

kann es sein wenn ich von MariaDB auf PostgreSQL gewechselt bin das die Befehle zum sichern und wiederherstellen der Datenbank Sicherung so nicht mehr gehen? Ich hab das ganze immer Händisch und nicht per Script gemacht.

Gruß

Markus

Antworten
1. Jan
  27. Dezember 2022 um 12:45 Uhr
  
  Hallo Markus,
  
  ja, PostgreSQL bedient sich hier anders als MariaDB/MySQL. Dieser Artikel bezieht sich nur auf MariaDB, aber du kannst mal einen Blick in die Update-/Restore-Scripte werfen, hier wird leicht ersichtlich, wie dies mit PostgreSQL machbar ist.
  
  Gruß,
  Jan
  
  Antworten
  1. Markus
    27. Dezember 2022 um 14:24 Uhr
    
    Ich werde mich mal durch wurschteln ;)
    
    Antworten
Stefan
19. März 2023 um 22:59 Uhr

Hallo Jan,

ist dieses Vorgehen – manuell oder mit Skript – noch aktuell mit den versionen 23-25 so durchführbaar, oder würdest Du es mittlerweile anders machen?

Werden mit dem Restore die ursprünglichen Zeitstempel wieder hergestellt? Hintergrund: Der NC Desktop Client löscht sonst unter Umständen die Dateien von der lokalen Festplatte

Antworten
1. Jan
  19. März 2023 um 23:33 Uhr
  
  Hi Stefan,
  
  ich machen das immer noch genau so, am Vorgehen hat sich nichts geändert.
  Beim Restore wird die Cloud auf genau den Zustand wiederhergestellt, wie sie zum Zeitpunkt des Backups war. Der Client sollte aber merken, wenn er neuere Dateien parat hat und diese dann wieder in die wiederhergestellte Cloud hochladen.
  
  Gruß,
  Jan
  
  Antworten
  1. Stefan
    20. März 2023 um 8:26 Uhr
    
    Hallo Jan,
    
    vielen Dank.
    Mir geht es beim Client weniger um den Upload. Der Client sieht ja immer Nextcloud als Master an, und hat mir schon paar mal Dateien lokal gelöscht. Ich werde sicherheitshalber mal von allem eine Kopie machen:)
    
    VG
    
    Stefan
    
    Antworten
  2. Stefan
    20. März 2023 um 11:54 Uhr
    
    Hi Jan,
    
    wenn man Dein Script verwendet, dann fehlt in der Anlietung oben der Hinweis, dass man auch die conf Datei benötigt und nicht nur die beiden Backup / Restore Skripte…
    
    Viele Grüße
    
    Stefan
    
    Antworten
    1. Jan
      20. März 2023 um 16:18 Uhr
      
      Hi Stefan,
      
      die Skripte werden mit der Zeit weiter entwickelt und der Blogbeitrag stellt nur einen kurzen Überblick zu dem Zeitpunkt der Skripte dar. Da ich den Blogbeitrag nicht immer „tagesaktuell“ mit den Skripten halten kann, ist der „Master“ immer im entsprechenden Codeberg-Repo zu finden (inkl. Dokumentation).
      Diesbzgl. habe ich noch einen Hinweis im Artikel hinzugefügt.
      
      Gruß,
      Jan
      
      Antworten
Thomas
26. März 2023 um 16:15 Uhr

Hallo Jan,

im Sicherungsscript kann man die Anzahl der aufzubewarenden Backups einstellen. O steht nehme ich an für „unendlich“.
Bedeutet 1 tatsächlich nur 1 Backup, oder 1 und das, was gerade erstellt wird? Bei mir wurden mit Einstellung 1 nämlich 2 Backups gespeicht, was die Festplatte überfüllt hat…

Wie könnte man das Backup auch auf einen externen, rysnc fähigen Speicher auslagern, z.B. Hetzner Storage Box?

Danke Thomas

Antworten
1. Jan
  26. März 2023 um 19:38 Uhr
  
  Hi Thomas,
  
  er hebt eigentlich nur ein Backup auf, wenn du nur eines angegeben hast. Allerdings löscht er ein altes Backup erst nach einem weiteren Durchlauf. Das ist insofern sinnvoll, da man ja ansonsten für eine gewisse Zeit ganz ohne Backup unterwegs wäre bzw. Probleme hätte, wenn bei der Erstellung des aktuellen Backups Probleme auftreten sollten.
  Das Backup kannst du auf einem beliebigen Speicher lagern, das irgendwie auf deinem Server gemountet werden kann (z.B StorageBox/Samba). Sobald du aber die Backups „extern“ lagerst, sollten diese auf jeden Fall verschlüsselt werden.
  Hier würde sich dann eher ein Backup mittels BorgBackup anbieten, denn dieses ist dann nicht nur verschlüsselt, sondern es wird auch komprimiert/dedupliziert gespeichert. Letzteres sorgt dann dafür, dass nur das „Delta“ gesichert wird, was dann meistens nur sehr wenig Speicher auf dem Backup-Ziel verbraucht.
  Das Ganze habe ich schon mal in diesem Artikel hier genauer beschrieben.
  
  Gruß,
  Jan
  
  Antworten
  1. Thomas
    26. März 2023 um 23:15 Uhr
    
    Danke, schaue ich mir an.
    Er hat 2 Backups gespeichert, weil das 2. aufgrund der vollen Platte nicht zu Ende gelaufen ist und somit am Ende das 1. Backup nicht löschen konnte.
    
    Antworten
Andi
4. April 2023 um 20:47 Uhr

Lieber Jan,

deine Artikel sind ja immer grandios. Ich habe vor 3 Jahren deinen Nextcloudartikel genutzt, um die eigene Wolke zu hosten. das backend ist auch noch stand vor 3 jahren.
Ich möchte jetzt das system komplett frisch neu aufsetzen…
Linuxsystem auf 22.04 LTS Updaten, php von 7.4.9 auf 8 etc. – natürlich mit wieder mit deinem artikel
nach dem aufsetzen der frischen nextcloud instant würde ich dann die datenbank, datenverzeichnis und webverzeichnis aus dem backupwiederherstellen wollen. die derzeitige instanz hat leider durch das letzte update ein paar datenbankfehler, die ich mit den handelsüblichen methoden nicht gelöst bekomme.
hole ich mir durch das backup der datenbank und des webverzeichnisses die fehler wieder in die frisch aufgesetzte instanz?
auf das einspielen des backups möchte ich ungerne verzichten, weil dann ja alle infos zu useraccounts etc verloren gehen…
LG und danke im voraus

Antworten
1. Jan
  5. April 2023 um 22:09 Uhr
  
  Hi Andi,
  
  prinzipiell kann man sagen, dass du mit einer Migration auch die „Altlasten“ mitnehmen wirst (diese sind ja irgendwie in der Datenbank persistiert, so wie es aussieht).
  
  Um „halb-neu“ anzufangen könnte man auch überlegen, ob man sich das Datenverzeichnis wegsichert und alle User der Cloud dazu auffordert, Möglichkeiten des Exports zu nutzen (z.B. für Kalender und Kontakte, diese werden ja nur in der DB gespeichert). Danach könnte man die Cloud neu aufsetzen, die entsprechenden User anlegen und dann die Dateien wiederherstellen (kopieren in die entsprechenden Verzeichnisse im Datenverzeichnis und anschließender File-Scan mittels OCC). Die User müssten dann nur die Daten manuell wiederherstellen, die zuvor in der alten DB gespeichert warten (z.B. Import der zuvor exportieren Kontakte/Kalender).
  Funktioniert erfahrungsgemäß aber nur dann gut, wenn die Cloud hauptsächlich als Datei-Ablage dient.
  
  Eine andere Möglichkeit wäre natürlich, die Fehler in der DB vor der Migration zu beheben. Mit einem vorher angefertigtem Backup kann man sich hier ja erst einmal austoben.
  
  Letzteres würde ich vermutlich zuerst ausprobieren. Erst wenn man merkt, dass die Fehler nicht mehr ohne weiteres behebbar sind, würde ich nach anderen Lösungen suchen.
  
  Gruß,
  Jan
  
  Antworten
  1. Andi
    5. April 2023 um 23:11 Uhr
    
    Hallo Jan,
    
    tatsächlich ist es eine reine Datenablage. Keine Kontakte/Kalender etc.
    Durch eine Migration des Backups wollte ich den Einfluss auf die User minimieren, sodass nicht alles wieder neu gesynct werden muss.
    
    Meine Angst:
    Alles ist neu, neue DB, neue user (mit alten namen), ich kopiere die Daten aus dem Backup direkt wieder auf den Server. die ordner struktur ist ja auch in der db gespeichert. das würde ja hier fehlen. clients verbinden sich wieder und beim sync vertüddelt er sich…
    
    groupfolder zum bsp liegen als ordner 01,02 auf dem server im webinterface und auf den clients liegen sie ja mit namen order abc, ordner xyz. erkennt der client dann, das alles beim alten ist ?
    bzw. verhindert der file scan, der dann die datein wieder in meine db spielt ein vertüdeln zwischen dem erst sync server client?
    danke und lg
    
    Antworten
    1. Jan
      6. April 2023 um 21:46 Uhr
      
      Hi Andi,
      
      also wie der Client auf solche Dinge reagiert, kann ich dir leider nicht genau sagen, beispielsweise, ob nun der (technische) Name der Groupfolders eine Rolle spielt, oder nur Ordner- und Dateinamen.
      Aber wenn du vorher ein Backup der Dateien Server-seitig anlegst (was du für die Migration ja dann eh benötigst), dann würde ich es einfach mal auf einen Versuch ankommen lassen. Wenn dann doch was durcheinander kommen sollte, dann kannst du immer noch den Sync der Clients deaktivieren, die Dateien (aus dem Backup) Server-seitig wiederherstellen und Client-seitig einen komplett neuen Sync aufsetzen.
      
      Würde mich echt mal interessieren, die sich das dann verhält, wenn die Cloud quasi „neu“ ist, die Dateien den Clients aber bekannt sind. Falls du das versuchen solltest, kannst du dann hier mal Rückmeldung geben? Das wäre super!
      
      Gruß,
      Jan
      
      Antworten
      1. Andi
        7. April 2023 um 15:15 Uhr
        
        Hey Jan,
        gerne.
        Das Problem ist gerade nur, dass ich die groupfolder, die ich aus dem backup wieder auf den server mittels winscp verschoben habe, nicht wieder in die datenbank bekomme. der odner 19 liegt in __groupfolders . besitzer ist www-data, rechte etc sind vergeben.
        beim ausführenvon sudo -u www-data php /var/www/nextcloud/occ groupfolders:scan 19 kommt: Folder not found: 19
        auf dem server liegt der ordner aber.
        im webgui wird er somit auch nicht angezeigt, bedeutet also der scan befehl schreibt ihn nicht in die neue datenbank….
      2. Jan
        7. April 2023 um 23:36 Uhr
        
        Hi Andi,
        
        ja, das ist das Problem, dass die Verzeichnisse auch in der DB bekannt sein müssen. D.h. ich würde hier anders herum vorgehen: Du legst über die Web-UI deine Groupfolders an. Über sudo -u www-data php occ groupfolder:list auf der Kommandozeile bekommst du dann heraus, welche IDs die entsprechenden Groupfolders haben. In diese kopierst du dann auf der Kommandozeile oder mittels WinSCP o.ä. die Dateien und wirfst dann nochmal einen Filescan an.
        Dieser Weg ist denke ich einfacher, als die IDs direkt in der DB zu korrigieren.
        
        Gruß,
        Jan
      3. Andi
        8. April 2023 um 14:19 Uhr
        
        Hallo Jan,
        
        genau so habe ich es dann gemacht.
        alle Benutzer neu erstellt in der NC (exakt gleiche Schreibweise)
        alle Groupfolder in der NC neu erstellt (hatte mir vorher notiert, welche groupfolder ID und den dazugehörigen Namen) -> auch hier muss man auf die exakte Schreibweise achten.
        
        Dann habe ich die Dateien via WinSCP in den jeweiligen Ordner zurück kopiert. Alle Rechte dann wieder auf user www-data übertragen. dann habe ich den sudo -u www-data php /var/www/nextcloud/occ groupfolders:scan –all gemacht und im anschluss noch den file:scan –all für die user ordner
        am ende habe ich noch occ maintenance:data-fingerprint ausgeführt.
        
        client wieder mit dem server verbunden. er hat dann nach änderungen gesucht und obwohl alle daten auf dem client vorhanden waren, synct er dennoch einiges neu.
        ich bin mal gespannt wie die anderen clienten reagieren…
        
        vielleicht war der fingerprint befehl doch nicht clever ?
        oder die variante des backups ist dann eben noch nicht sooo sauber, als wenn die datenbank mit alles infos vorhanden ist.
        
        Aufjedenfall danke ich dir für deinen wunderbaren Artikel zum Aufsetzen der cloud und für unsere kleine diskussion hier.
        Es hat wieder sehr viel spass gemacht, den Server nach deiner Anleitung aufzusetzen und ein bissel zu frickeln. :)
        Kleiner Hinweis: nach der Redis Installation und Konfiguration musste ich nginx einmal komplett neu starten, damit der test der redis installation funktionierte. dieser schritt fehlt in deiner anleitung…
        
        LG und Danke
        Andi
      4. Jan
        8. April 2023 um 21:55 Uhr
        
        Hi Andi,
        
        der „fingerprint“ Befehl sorgt meines Erachtens dafür, dass den Clients mitgeteilt wird, dass sich am Server etwas verändert hat und diese sicherheitshalber „noch mal nachsehen sollten“. Ist also in deinem Use Case sicher kein Fehler.
        Der Client muss nun nochmal neu abgleichen. Wenn du sagst, das dieser nun einiges neu synchronisiert: Ist das schätzungsweise (bezogen auf die gesamte Datenmenge) viel, oder eher weniger?
        
        Du hast die Cloud nun „so halb“ migriert. 100% sauber ist das vermutlich nicht, daher ist auf Seite der Clients evtl. dies oder das neu zu synchronisieren.
        
        nginx sollte nach der Redis-Installation eigentlich nicht neu gestartet werden müssen, nginx „weiß“ ja nichts von Redis (und anders herum). Trotzdem ist es nach dem ganzen Setup sicher nicht verkehrt, wenn man mal alle Dienste (oder gleich den ganzen Server) einmal neu startet.
        
        Gruß,
        Jan
Thomas
8. April 2023 um 23:29 Uhr

Hallo Jan,

hab das Skript zur Sicherung funktioniert einwandfrei.
Ich hatte jetzt auf meinem Server einen Snapshot mit altem Datenbestand von 2022 eingespielt und danach Dein restore Skript laufen lassen.
Letztes Backup war von gestern Abend, da hb ich auch angeben lassen.
Das restore Stkript läuft sauber durch. Der Nextcloud Datenbestand ist dennoch ur-alt.

Was kann die Ursache sein?

Danke Thomas

Antworten
1. Jan
  8. April 2023 um 23:36 Uhr
  
  Hi Thomas,
  
  hier kann ich zwar nur raten, aber ich würde darauf tippen, dass irgendwelche Verzeichnisse nicht mehr gepasst haben. Hat sich bei dir evtl. irgendwas verändert (z.B. Umzug des Datenverzeichnisses seit dem Snapshot von 2022)?
  Ansonsten: Geht es nur um die Dateien, oder sind auch andere Sachen wie z.B. Kalender/Kontakte betroffen. Wenn es nur die Daten sind, dann führe mal einen Filescan mittels OCC durch (occ files:scan --all). Sind dann die neueren Dateien wieder sichtbar?
  
  Gruß,
  Jan
  
  Antworten
  1. Thomas
    8. April 2023 um 23:55 Uhr
    
    Hallo Jan,
    
    danke für die schnelle Antwort. Nein, es hat sich rein gar nichts seit 2022 geändert.
    Kalender und Kontakte scheinen aktuell zu seien, Dateien nicht. Wenn ich auf dem Server ins Datenverzeichnis gehe, da sind da auch die Daten von 2022 drin und im Web GUI von Nextcloud uralte „Zeitstempel“. Sieht so aus, als hätte er das Datenverzeichnis nicht überschrieben, obwohl das Skript es mitgeteilt hat.
    
    Ich hab noch eine unkomprimierte Rsync Sicherung der Daten, da ich ja nicht wusste, ob das Skirpt geht und mich nicht darauf alleine verlassen wollte. Theoretisch kann ich doch einfach mal das aktuelle Datenverzeichnis als old bennenen und von der StorageBox das Datenverzeichnis Stand gestern wieder einspielen lassen und User wieder auf www-data ändern. Sollte doch gehen, oder?
    
    Antworten
    1. Thomas
      8. April 2023 um 23:56 Uhr
      
      Ach ja, occ files:scan — all bringt keine Abhilfe
      
      Antworten
      1. Thomas
        8. April 2023 um 23:58 Uhr
        
        Oder kann ich einfach einen gleichnamigen Ordnder für das Datenverzeichnis erstellen, der aber leer ist? Das Skript müsste den dann doch löschen und die richtigen Daten rüberkopieren.
      2. Jan
        10. April 2023 um 17:26 Uhr
        
        Hi Thomas,
        
        ja, das müsste auch funktionieren. Das Datenverzeichnis muss eben nur exisitieren.
        
        Gruß,
        Jan
      3. Jan
        9. April 2023 um 0:03 Uhr
        
        Hi Thomas,
        
        ja, versuche mal das Datenverzeichnis wie von dir beschrieben von der StorageBox wiederherzustellen, vielleicht bringt das ha Abhilfe.
        Trotzdem gehe ich davon aus, dass hier irgend etwas mit den Verzeichnissen durcheinander gekommen ist. Du kannst die Schritte des Skriptes auch mal manuell ausführen, vielleicht sieht man hier ja den Fehler schneller. V.a. der Schritt des Löschens des Datenverzeichnisses und dessen Neuanlage aus dem Backup ist hier interessant.
        
        Gruß,
        Jan
Thomas
9. April 2023 um 0:16 Uhr

Ich hab jetzt einfach mal das Datenverzeichnis umbenannt und ein neues, leeres mit gleichen Namen angelegt.
Skript laufen lassen, jetzt scheinen die korrekten Daten drin zu sein, muss ich morgen nochmal genau prüfen. Allerdings sind die Zeitstempel trotzdem alle vom Zeitpunkt der Rücksicherung.

Lt. einem Deiner Kommentare vom 19.März, sollte aber ein 1:1 Zustand hergestellt werden… Oder hab ich da was falsch verstanden

Antworten
1. Jan
  9. April 2023 um 0:42 Uhr
  
  Hi Thomas,
  
  naja, die Dateien sind ja zum Zeitpunkt der Rücksicherung angelegt worden, das OS stellt dies korrekt dar.
  Die Frage ist nur, ob die NC die Zeitstempel vom Betriebssystem nimmt, oder ob diese Informationen irgendwo in der NC-DB gespeichert werden, das kann ich dir ad-hoc gar nicht so genau beantworten.
  
  Interessanter wäre allerdings, warum der Restore funktioniert, wenn das Ziel-Verzeichnis des Restores leer ist. Das Restore-Skript sollte eigentlich das Datenverzeichnis vor dem Rückkopieren aus dem Backup leer putzen.
  Du hast schon die aktuellste Version der Skripte aus dem Codeberg-Repository?
  
  Gruß,
  Jan
  
  Antworten
  1. Thomas
    9. April 2023 um 1:14 Uhr
    
    Ja, irgendwann Mitte März hab ich da Skript gezogen und eingerichtet. Meine Befürchtung mit den Zeitstempeln ist: Die Dateien auf der NC sind somit neuer als auf meinem lokalen System und z.B. der NExtcloud Client lädt jetzt alles runter.
    Ebenso die Notiz ab Joplin, die jetzt durcheinander kommen könnte.
    
    Antworten
  2. Thomas
    10. April 2023 um 11:30 Uhr
    
    Hallo Jan,
    Ich habe jetzt noch etwas probiert.
    Bei Verwendung des Skripts wird der Datenordner anscheinend nicht sauber geleert.
    Lege ich einen neuen an, funktioniert es. Allerdings verliere ich nach dem zurückspielen die Zeitstempel, weshalb ich meine gesicherten Daten per rsynch zurückspielen.
    
    Kann man Dein Skript so modifizieren, dass bei Erstellung und beim Zurückspielen des Backups die Zeitstempel beibehalten werden?
    
    Viele Grüße
    Thomas
    
    Antworten
    1. Jan
      10. April 2023 um 17:43 Uhr
      
      Hi Thomas,
      
      das mit den Zeitstempeln ist aber wirklich komisch. Es werden ja nur tar-Befehle genutzt und hier wird der originale Zeitstempel ja „mitgesichert“. Öffne die tar.gz-Datei doch mal mit einem beliebigen Zip-Programm und schau dir hier die Zeitstempel an: Passen diese hier? Wenn ja, dann liegt es wohl irgendwie am Restore. Wenn nein, dann ist das glaube ich ein anderes grundsätzliches Problem.
      
      Gruß,
      Jan
      
      Antworten
      1. Thomas
        10. April 2023 um 21:05 Uhr
        
        Hi Jan,
        
        in den tar.gz Dateien passt der Zeitstempel, im Ordner auf dem Server haben dann alle Dateien das gleiche Datum. Das der Wiederherstellung.
        Wenn wieder alles eingerichtet ist und ich nen Snapshot habe, probier ich es nochmal.
        
        Viele Grüße
        
        Thomas
      2. Jan
        10. April 2023 um 21:30 Uhr
        
        Hi Thomas,
        
        ich bin mir echt nicht sicher, ob das für die NC ein Problem darstellt (und die Zeitwerte der Dateien nicht doch irgendwo in der DB gespeichert werden). Zumindest hatte ich noch niemanden, der dieses Problem hatte (oder es war/ist den Leuten egal, dass der Sync-Client nach dem Restore wieder eine größere Menge Daten hin- und herschaufelt).
        
        Du könntest aber beim Restore nochmal den Parameter --atime-preserve ausprobieren (vermutlich mit Option „system“, da „replace“ schon standardmäßig genutzt wird). Mehr Infos dazu findest du hier.
        
        Gruß,
        Jan
Tom
17. April 2023 um 14:26 Uhr

Hallo,

meine MariaDB Nextcloud-DB ist noch nicht auf 4 Byte Support umgestellt und ich habe mir die Nextcloud-Doku zur Umstellung jetzt mal angeguckt.
Ganz am Ende der Doku steht noch ein Hinweis, dass nach der Umstellung auch die Sicherung mit mysqldump angepasst werden sollte (Zusatz „–default-character-set=utf8mb4“) !

In deinem Nextcloud-Restore-Script ist dbNoMultibyte berücksichtigt aber nicht im Backup-Skript beim mysqldump.

https://docs.nextcloud.com/server/25/admin_manual/configuration_database/mysql_4byte_support.html

Gruss
Tom

Antworten
1. Jan
  18. April 2023 um 18:14 Uhr
  
  Hi Tom,
  
  danke für den Hinweis, aber ich weiß nicht, ob das ein Problem ist. Habe das mal getestet: Einen Ordner mit einem Emoji erstellt, dann das Backup ausgeführt (ohne --default-character-set=utf8mb4) und daraufhin einen Restore gemacht. Also im Grunde genommen, so wie die Skripte heute (18.04.2023) auf Codeberg zur Verfügung stellen.
  Wenn es ohne diesen Zusatz nicht klappen sollte, dann hätte ich erwartet, dass nach dem Restore das Verzeichnis mit dem Emoji nicht mehr korrekt angezeigt werden würde. Wird es aber, daher denke ich, dass dieser Zusatz beim Dump nicht unbedingt erforderlich ist.
  Mit einem Emoji in einem Kommentar zu einer Datei verhält es sich übrigens analog.
  
  Gruß,
  Jan
  
  Antworten
Jim
17. April 2023 um 15:28 Uhr

Hallöchen,

falls ich das Backup-Script als User „www-data“ ausführen lassen, benötige ich kein Root-Rechte für das Backup? („sudo -u www-data“ entfällt ja dann…)

Grüße

Antworten
1. Jan
  18. April 2023 um 18:21 Uhr
  
  Hi Jim,
  
  die Skripte sind eigentlich dafür ausgelegt, mittels Root-Rechten gestartet zu werden.
  Es dürfte aber auch möglich sein, diese als User www-data auszuführen. In diesem Fall muss nur dafür gesorgt werden, dass www-data alle Befehle mittels „sudo“ ohne Passwort-Abfrage ausführen kann (mittels visudo). Das dürfte recht aufwändig werden.
  
  Warum kommen bei dir keine Root-Rechte in Frage? Hat das einen bestimmten Grund?
  
  Gruß,
  Jan
  
  Antworten
  1. Jim
    20. April 2023 um 10:34 Uhr
    
    Hallo Jan, du hast Recht, macht keinen Sinn die Backup-Skripte als www-data laufen zu lassen. Habe sie jetzt in /root/backup abgelegt und lasse sie per root-crontab starten.
    Danke!
    
    PS: der Datenbank-Dump ließe sich auch per
    $ mysqldump nextcloud_db > dump.sql
    anlegen, falls die Zugangsdaten in der File: „~/.my.cnf“ gespeichert sind. (Quelle: https://dev.mysql.com/doc/refman/8.0/en/option-files.html)
    
    Antworten
    1. Jan
      20. April 2023 um 12:07 Uhr
      
      Hi Jim,
      
      ja, der Dump ließe sich sicher auch so anfertigen. In den Skripten gebe ich aber alle Infos „direkt“ mit, da ist dann alles an einem Ort.
      
      Gruß,
      Jan
      
      Antworten