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:
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
Links
- Backup (Nextcloud Dokumentation, englisch)
- Restoring Backup (Nextcloud Dokumentation, englisch)
- Using the occ command (Nextcloud Dokumentation, englisch)
- Repository: Nextcloud-Backup-Restore (Codeberg)
Ähnliche Artikel:
Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
Nextcloud Talk mit eigenem Signaling-Server (High Performance Backend)
Nextcloud 21: High Performance Backend für Dateien
Nextcloud auf Ubuntu Server 22.04 LTS mit nginx, PostgreSQL/MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
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
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_073953Dazu 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
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
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
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.?
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
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
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 mitumount ...wieder unzumounten.Gruß,
Jan
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
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
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
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
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
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
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
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-hddgemountet 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
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
Vielen Dank für das Script, darf ich es denn verwenden? Aktuell hat es keine Lizenz.
Gruß
prk0ghy
Never mind, I found the license sometimes I wonder if I am blind.
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
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
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
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‘
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
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
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
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
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. :-)
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
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
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
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.
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/nextcloudenpacken willst, aber/var/wwwist (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
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?
Hi Max,
zum Extrahieren ist dies hier korrekt, wenn pigz eingesetzt wird:
'tar -I pigz -xmpfAnderweitig ist das:
tar -xmpzfVersuch aber mal, den letzten Slash beim Pfad bei
-Czu entfernen.Gruß,
Jan
Hm, daran lags leider nicht. :/
Hi Max,
also dieses
tar (child): pigz: Cannot exec: No such file or directoryweißt schon sehr stark darauf hin, dass er pigz nicht ausführen kann. Was gibt der Befehlwhich pigzbei dir aus?Gruß,
Jan
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.
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
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
Salue, super Anleitung, mir fehlt nur eines:
Konfigurationdes Nextcloud High Performance Backend für Dateien (App in Nextcloud)
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
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
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.
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
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.
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
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.
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
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.
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
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.
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
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
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.
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
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
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
Ich werde mich mal durch wurschteln ;)
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
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
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
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
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