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,
zunächst mal vielen Dank für deine großartigen Anleitungen :-)
Leider hatte sich beim Ausführen deines Backup-Scripts bei mir ein Tippfehler eingeschlichen, wodurch das Daten-Verzeichnis lokal auf der viel zu kleinen SSD gesichert wurde. Dadurch sah ich mich dann gezwungen, dass Backup abzubrechen (Ctrl+C). Natürlich sollte anschließend der Maintenance-Modus ausgeschaltet werden, was mir auch als erfolgreich bestätigt wurde.
Jedoch wurde der Maintenance-Modus wohl nicht nur ausgeschaltet, sondern die Installation gleich in den Installationsmodus geschickt. Offenbar wurde mindestens die config.php aus dem Installationsverzeichnis gelöscht. Zufall oder steckt mehr dahinter?
Da das Installationsverzeichnis (filedir) bereits vollständig gesichert war, konnte ich dieses manuell wiederherstellen und meine Installation somit „retten“.
Grüße
Niklas
Hi Niklas,
das Backup-Skript löscht keine Dateien (außer alte Backups, wenn die Variable maxNrOfBackups ungleich 0 ist).
Daher kann ich mir das Verhalten nicht so recht erklären. Weißt du zufällig noch, was da Skript zuletzt angezeigt hat, als du das Backup mit STRG+C abgebrochen hast (also bei welchem Schritt es gerade beschäftigt war)?
Gruß,
Jan
Hallo Jan,
das weiß ich leider nicht mehr. Jetzt läuft es jedenfalls wieder.
Grüße
Niklas
Hi Niklas,
OK, wenn es wieder läuft, dann scheint es ja nur ein temporäres Problem gewesen zu sein.
Gruß,
Jan
Hallo Jan,
welches Format wähle ich am besten aus, um eine USB-HDD für das Backup zu formatieren. Ich möchte auch, wenn es geht die Daten unter Windows abrufen können. Google sagt NTFS. der andere sagt, es geht nur mit FAT32. Hast Du für mich einen Tipp?
Hi Klaus,
ext (4) geht unter Windows nicht. NTFS kann man zwar auch unter Linux nutzen, allerdings hat man hier und da einige Einschränkungen. V.a. ist das mit dem Setzen der Rechte wohl ein Problem. Mehr Infos dazu hier.
Wenn du also mit den Einschänkungen von FAT32 leben kannst (z.B. keine Dateien größer 4 GB), dann würde ich für dieses Vorhaben vermutlich FAT32 wählen.
Ein anderer Ansatz wäre, die Platte nur unter Linux zu nutzen und dementsprechend in ext4 zu formatieren. Anschließend wird dann eine Samba-Freigabe eingerichtet, so dass man auch mit Windows-Systemen Zugriff auf die Inhalte der Platte hat. Ist vielleicht eine gute Alternative.
Gruß,
Jan
Ach…schon Cool, wenn man jemanden kennt, der weiß, wie es geht. Leider bin ich zur Zeit in der Ausbildung und kann mich nur mit Worten für Deine Hilfe bedanken.
VIELEN DANK
Hallo Jan,
ich schließe mich an…. Super Anleitung.
Hat mir schon 2x den Hintern gerettet.
So nun zu meinem Anliegen,
die Wiederherstellung!!
Wie kann ich den Clients nun klar machen, daß es einen Unterschied zwischen ihren Datenstand und die des Servers gibt? In meinem Fall ca. 3 Tage. Gibt es eine solche möglichkeit?
Gruß
Francisco
Hi Francisco,
das kann man nicht „von außen“ steuern. Eigentlich sollte dies durch das Datum der letzten Änderung (z.B. einer Datei) zu ermitteln sein.
Welche Problem hast du nun konkret an den Clients?
Gruß,
Jan
Hallo Jan,
Probleme nur in so weit, dass die Daten auf den Clients aktueller sind als auf dem Server. Durch meine Dummheit sind mir 3 Tage an Daten (Bilder usw.) verloren gegangen. Dank deiner Beschreibung (Sicherung und Wiederherstellung) läuft nun wieder alles. Bis auf den kleinen Datenunterschied. Nun kann ich alle Mitarbeiter bitten ihre Daten manuell noch einmal hoch zu laden, aber wie das nun mal so ist…… :-)
Gruß
Francisco
Hi Francisco,
es gibt in den Sync Clients meist eine Option „Synchronisierung erzwingen“. Dann sollte das System eigentlich merken, dass die Dateien auf den Clients neuer sind als die Dateien in der Cloud. Vielleicht ist das ja schon ausreichend und es muss nichts manuell hochgeladen werden.
Nutzt die Cloud im professionellen Umfeld?
Gruß,
Jan
Hallo Jan,
ich würde sagen semi Professionell. Ca. 12 Mitarbeiter und div Firmenkunden die bei uns zwischenspeichern. Wie wir sagen — wir haben eine gewachsenen Struktur! .-)
Es begann als ein Test und ist nun ein Teil des Ganzen geworden.
So nun aber zu deiner Frage: „Das erzwingen“ brachte keinen Erfolg!
Laut Datenbank sind keine Daten hinzugekommen durch diesen Versuch.
Aber DANKE für deine Anregungen. Ich denke wir werden noch so ein bis zwei kleine Probleme in den nächsten Monaten bekommen. (liegt wohl in der Natur der Sache)
Gruß
Francisco
Hi Francisco,
hier könnte man dann noch mit dem OCC Befehl testen, ob sich etwas an der Situation ändert, siehe hier.
Ich würde mal mit einem „cleanup“ beginnen und anschließend noch ein „scan“.
Gruß,
Jan
Hallo Jan,
DANKE — werde ich wenn alle Sicherungen abgeschlossen sind, starten!
Gruß
Francisco
Hallo Jan,
Ich habe die Nextcloud komplett neu nach deiner Anleitung aufgesetzt und wollte nun das Backup zurückspielen.
Die Parameter habe ich alle angepasst und sing richtig.
Leider gibt mir das Restore Script folgende Fehlermeldung aus:
tar: ./BLABLA/files/Handy Backup/Bilder u. Videos/Camera/2018_13.jpg: Cannot open: No such file or directory
tar: ./BLABLA/files/Handy Backup: Cannot mkdir: No space left on device
Ich kann es mir nicht erklären… den auf der Platte ist noch massig Platz.
Bei der Installation habe ich einfach 500GB LVM use entire Disk gewählt. (wie immer)
Hast du evtl eine Ahnung woran das liegen könnte?
Danke Gruß
Bernd
Arg habs gefunden….
Sry
Gruß Bernd
Hi Bernd,
woran lag es nun? Würde mich mal interessieren, da ich mir den Fehler auch nicht erklären konnte.
Gruß,
Jan
Hi, würde mich ebenfalls freuen, wenn du sagen könntest woran es gelegen hat. Ich habe das selbe Problem beim erstellen der Backupdatei.
root@xxx:~# tar -cpzf /mnt/Share/Backups/Nextcloud/NextcloudBackup_FileDir_`date +“%Y%m%d“`.tar.gz -C /var/www/nextcloud .
tar (child): /mnt/Share/Backups/Nextcloud/NextcloudBackup_FileDir_20200707.tar.gz: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: /mnt/Share/Backups/Nextcloud/NextcloudBackup_FileDir_20200707.tar.gz: Cannot write: Broken pipe
tar: Child returned status 2
tar: Error is not recoverable: exiting now
Habe ebenfalls bereits probiert, das Verzeichnis mit „mkdir /mnt/Share/Backups/Nextcloud/“ anzulegen, bekomme dort aber die selbe Fehlermeldung.
Mit „sudo“ vorweg bin ich auch nicht weitergekommen :/
Danke für da Script – Ist ein super Einstieg.
Da ich allerdings meine nextcloud_data Verzeichnisse per smb eingehängt sind und diese schon auf andere weise gesichter werden, habe ich diesen Teil auskommentiert – ich hoffe das gibt auf dauer keine probleme
Hi Bastian,
wichtig ist hier, dass „alles in einem Rutsch“ gesichert wird: Maintenance-Mode an, alles sichern (wie auch immer), Maintenance-Mode aus.
Wenn beide Sicherungen (NC und Samba) zu unterschiedlichen Zeitpunkten laufen, dann könnten Inkonsistenzen entstehen. Hintergrund ist, dass die Daten im Datenverzeichnis von NC auch noch über die NC-DB referenziert werden. Wenn DB-Backup und Dateisystem-Backup nicht zusammen passen, könnten nach einem Restore Dateien verschwunden sein (also nicht in der Web-UI angezeigt werden) oder „tote“ Einträge in der DB übrig bleiben.
Eine Überlegung: Könntest du aus der Samba-Sicherung nicht das NC-Datenverzeichnis ausschließen und dies dann nur über das NC-Backup-Skript sichern?
Gruß,
Jan
Ich habe Freenas im Einsatz – auf diesem laufen die shares und die Sicherungen.
Meine Nextcloud läuft ebendfalls auf dem Freenas in einer VM.
Die Sicherung so umbiegen das Sie über NC gesichert wird wäre bestimmt möglich – nur warscheinlich sehr umfangreich.
Wenn du möchtest kann ich dir mal mein aktuelles Backup script zusenden.
Dieses sichert immer nur die differenz zum letzten Backup.
—-
Könntest du noch erläutern mit welchem Syntax ich den crontab -e füttern muss.
Denn mit
0 3 * * * ./NextcloudBackup.sh >/dev/null 2>&1
klappts nicht
Hi Bastian,
kannst mir gern mal das Backup-Skript per Mail schicken, kann dir aber nicht versprechen, dass ich da eine zündende Idee habe. ;-)
Wegen crontab: Ich denke mal, dass hier die Pfadangabe fehlt. Sachen wie „./dir/…“ funktionieren hier nicht, da muss der absolute Pfad rein, also z.B. „/home/user/scripts/NextcloudBackup.sh“.
Gruß,
Jan
Moin Jan,
also leider funktioniert das auch nicht:
0 3 * * * „/home/user/scripts/NextcloudBackup.sh“
sowohl mit als auch ohne “ „
Hi Bastian,
seltsam, dann muss es wohl an etwas anderem liegen. Schau mal nach, zu welchem Fehler es beim Ausführen des Cronjobs kommt:
grep CRON /var/log/syslogGruß,
Jan
Danke Jan für das Skript.
Wenn ich bei {maxNrOfBackups} was anderes als 0 eingebe werden immer alle Backups inkl des aktuellen gelöscht.
Schade.
Hi Marvin,
eigentlich sollte das schon funktionieren. Ich werd’s mir die Tage mal ansehen.
Du kannst bei solchen Problemen/Fehlern auch übrigens einen Issue direkt auf GitHub anlegen.
Gruß,
Jan
Hi Marvin,
ich habe mir das nun nochmal genauer angesehen, aber konnte hier keinen Fehler feststellen.
Was du mal ausprobieren könntest: geb die einzelnen Zeilen deines Scripts mal einzeln in die Kommandozeile ein. Es wäre wichtig zu wissen, bei welchem Schritt genau sämtliche Backups gelöscht werden.
Gruß,
Jan
Hallo Jan,
die aktuelle NC-Dokumentation empfiehlt rsync als Bcakup-Tool, wohingegen du mit tar arbeitest.
Gibt es dafür Gründe? Ich denke mit tar kann man immer nur vollständige Backups machen, was Zeit, Strom und Plattenplatz beansprucht.
Gibt es Sicherheitsbedenken gegen ein differentielles Backup mit rsync? Ich denke, dass die Vereinshistorie, die NC von jeder Datei anlegt eine Wiederherstellung auch dann ermöglicht, wenn z.B. ein Verschlüsselungstrojaner meinen PC lahmgelegt hat. Oder?
Vielen Dank und viele Grüße
Jürgen
Hi Jürgen,
mit was du Kopien der Dateien anlegst, ist erst einmal egal, man könnte auch einfach nur cp verwenden. Ich nehme tar, damit die Dateien komprimiert werden.
Das Differentielle mache ich dann noch über Bog Backup: Ich mache immer eine Komplettsicherung mit diesen Skripts und diese landen dann in einem Borg Repo. Borg dedupliziert sehr effizient, da brauche ich keine differentiellen Backups mittels rsync.
Gruß,
Jan
Hallo Jan, das klingt interessant, jedoch verstehe ich als Neuling nur Bahnhof. Gibt es irgendwo nähere Informationen zu dem Borg-Backup?
Vielen Dank und viele Grüße
Jürgen
Hi Jürgen,
ja, generelle Infos zu Borg gibt es hier.
Die Lösung, die ich bevorzuge, ist jedoch „mehrschichtig“. Lokale Backups mittels Skripts (Nextcloud, FHEM, etc.) und Sichern dieser Backups mittels Borg.
Vielleicht lohnt es sich hier, mal einen Blog-Artikel zu planen. ;-)
Gruß,
Jan
Hallo Jan,
habe leider Probleme oder eine Verständnisproblem beim backup. Backup vom We-Verzeichnis und Daten-Verzeichnis war kein Problem. Beim Backup der Datenbank erhalte ich immer folgende Fehlermeldung:
juergen@owncloud:/var/www/nextcloud$ mysqldump –single-transaction -h localhost -u nextcloud_db_user -p nextcloud_db > /mnt/NextcloudBackup/NextcloudBackup_DB_`date +“%Y%m%d“`.sql
-bash: /mnt/NextcloudBackup/NextcloudBackup_DB_`date +“%Y%m%d“`.sql: Keine Berechtigung
Hi,
hast du hier den richtigen User/Passwort eingegeben? Das muss der DB-User und das Passwort des Nextcloud-DB-Users angeben, welches du auch beim Setup von Nextcloud eingegeben hast.
Gruß,
Jan
Hi Jan,
bin kein Datenbamk-Experte ;-) Wenn ich das richtig sehe sind die beiden Optionen Benuter und Passwort: -u nextcloud_db_user -p nextcloud_db, nextcloud_db_user = user und nextcloud_db = passwort. D.h. beides ersetze ich durch die Namen die ich vergeben habe. Allerdings habe ich im Passwort Sonderzeichen, muss ich die irgendwie in Hochkommata etc. setzen?
Hi,
nicht ganz. „nextcloud_db“ ist der Name der NC-Datenbank.
Das „-p“ sorgt dafür, dass er dich nach dem Absetzen des Befehls nach dem Passwort des DB-Benutzers („nextcloud_db_user“) fragt.
Gruß,
Jan
Danke für die Anleitung bzw das skript… Soweit würde es bei mir auch laufen. Nur hat die Sicherung nur um die 500MB – Die NC hat aber aktuell eine Auslastung von knapp 3TB. Wenn ich tar bzw gzip viel zutraue – aber da hakt es noch… Hast du eine Idee wo ich schauen könnte…
Beim Database Backup hab ich mal mit ‚–all-databases‘ gespielt. Ha aber nichts am Ergebnis geändert…?!?!?!?!?!?!?!
cu
Stefan
Hallo Stefan,
also der DB-Dump ist meist (auch auf großen Instanzen) erstaunlich klein, daran wird es nicht liegen.
Ich vermute eher mal, dass er (aus welchem Grund auch immer) das Datenverzeichnis nicht korrekt weg sichert. Geb doch mal alle Zeilen des Scripts manuell per Kommandozeile ein und kontrolliere nach jedem Schritt, ob die entsprechenden Sicherungen angelegt wurden und ob die Dateigrößen plausibel sind. Vermutlich ist hier nur eine Pfadangabe falsch. Bitte auch auf die Kommentare im Script achten.
Gruß,
Jan
Moin Jan,
herzlichen Dank für deine hilfreichen Skripte!
ich habe neu das aktuelle Nextcloud unter Debian10 installiert
Beim Ausführen deines Backup-Scriptes gibt es folgende Fehlermeldung:
mysqldump: Got error: 1045: „Access denied for user ’nextcloud’@’localhost‘ (using password: YES)“ when trying to connect
Mein benutztes Passwort stimmt, habe ich mit
service mysql restart && mysql -uroot -p
überprüft.
What to do ?
Gruß
Michael
.
Moin Jan,
hat sich erledigt, Denkfehler meinereinerseits. Passwort für DB-User war gefordert, nicht root.
Gruß Michael
Hallo Michael,
ja, das war einfach das Passwort des falschen Users. Aber das hast du ja schon selbst rausgefunden. Klappt nun alles?
Gruß,
Jan
Hallo Jan,
funkt bestens, Backup-Script noch in crontab eingehängt, alles in bester Butter.
Da ich selber keinen Plan von Linux habe bin ich dringend auf fertige Lösungen angewiesen. Dafür dir meinen herzlichen Dank.
Gruß
Michael
Danke für das tolle Tutorial!
Das Aufsetzen meiner Nextcloud hat damit super funktioniert.
Ich habe nur das Problem, dass beim Hochladen von Dateien mit der Smartphone App der Fehler „Request Entity too large“ kommt.
Hat hier jemand das selbe Problem und eine Lösung dafür gefunden?
Es gibt mehrere Foren, wo dieses Problem bei Nutzung von nginx und einem Reverse Proxy geschildert ist. Allerdings, habe ich bishher nohc keine Lösung finden können.
Hallo Thomas,
hier ist die Einstellung client_max_body_size entscheidend, siehe Nextcloud-Artikel.
Dieser Wert muss sowohl im Gateway-Host, als auch im vHost von Nextcloud selbst korrekt gesetzt werden.
Wenn das dann auch noch nichts hilft, kannst du mal versuchen, den Wert für client_body_buffer_size ebenfalls zu erhöhen.
Gruß,
Jan
Im Abschnitt „Backup/Restore mit Bash-Skript“ wechseln wir mit sudo -s auf den root User. Der Befehl wechselt jedoch nicht in den Homeordner von root, sondern von dem User, von dem abgesprungen wird. Mit „sudo su – root“ würde man im /root Verzeichnis landen, wo wir die Skripte abspeichern wollen.
Gruß
Hendrik
Hallo Hendrik,
danke für den Hinweis.
Konkret speichere ich die Dateien jedoch nicht in /root ab, sondern wirklich im Home-Verzeichnis des (Sudo-)Users. Natürlich kann man hier auch direkt in /root speichern, wenn dies besser zum eigenen Workflow passt.
Gruß,
Jan
Hallo Jan
Erst mal Danke für die tolle Anleitung.
Zu dem ersten Teil (Backup des Datenverzeichnisses) hätte ich eine Frage:
In diesem Verzeichnis liegt auch der Ordner „Bilder“ in dem ALLE meine Bilder liegen, ca. 200GB. Dies war auch mein ursprüngliches Vorhaben, dass ich jederzeit von überall über Nextcloud Zugriff auf meine Bilder habe.
Jedoch sind diese zuerst auf dem Laptop, dann auf einer externen Festplatte, danach auf meinem Desktop PC und dann nochmal in der Nexctcloud.
Ist es zwingend notwendig, also in Bezug auf die Funktionsweise des gesamten Backups, das Datenverzeichnis mit zu sichern?
Gruß
Roland
Hi Roland,
im Sinne von Nextcloud ist die Sicherung des Datenverzeichnisses schon wichtig, da DB und Datenverzeichnis eine Einheit bilden. Ich würde also das Datenverzeichnis nicht aus der Sicherung raus nehmen.
Denk lieber darüber nach, ob ein anderer Speicherort wirklich noch notwendig ist. Trotzdem ist es sicher nicht verkehrt, die Daten mehrfach gesichert zu haben.
Schau dir dazu auch mal diesen Artikel hier an. Hier wird die NC-Sicherung nochmal in Borg Backup „verpackt“. Borg sichert deduplizierend, d.h. hier wird immer nur das Delta gesichert und die Backup-Sets nach der initialen Sicherung werden dadurch sehr klein. Vielleicht ist das für dich ja eine Alternative.
Gruß,
Jan
Hallo,
zuerst einmal tolle nextcloud Anleitung, vielen Dank dafür!
Um die Nextcloud zu sichern wäre es besser, ebenfalls ein Script per cronjob auf dem NAS auszuführen, welches die Sicherungsdateien per rsync und rsa key authentifizierung vom nextcloudserver abholt, da die Nextcloud evtl. in einer DMZ betrieben wird und so keine Sicherheitslücke entsteht?
Viele Grüße
Armin
Hallo Armin,
klar, das sollte auch möglich sein: Ein System erstellt das Backup (Nextcloud Server) und ein anderes System holt sich die Backups dann ab und löscht diese dann auch vom Quellsystem.
Gruß,
Jan
Hallo,
muss der Webserver gestoppt werden oder reicht der Maintenace Mode?
Grüße
Olaf
Hi Olaf,
der Maintenance-Mode sollte ausreichen. Um aber auf Nummer sicher zu gehen, stoppe ich immer auch den Webserver.
Gruß,
Jan
Hallo Jan,
danke, und danke für das Script. :-)
Gruß
Olaf
Moin,
wuderbare Anleitung hat mir erstmal geholfen an meine Sachen wieder dran zu kommen. Allerdings kann ich das weder die funktion „Benutzer“ , „Einstellungen“ oder „Apps“ aufrufen. Es kommt zu der Meldung:
„Zugriff verboten
App is not enabled“
hast du ne Idee wo es dran liegen könnte. Rechte habe ich sowohl auf dem „nextcloud_data“ als auch auf dem „nextcloud“ Ordner als „www-data“
Danke
Hi Bastian,
das sind ein paar wenige Infos. Hier würde ich in das Nextcloud-Log und ggf. in das nginx error.log schauen, ob hier aussagekräftigere Informationen enthalten sind.
Gruß,
Jan
Hallo Jan,
ich habe mittlerweile das Problem, dass mein Data Verzeichnis 180GB groß. Das sind meist Bilder der Kinder die sich aber verständlicher weise nicht trennen wollen. Nun braucht das Backup 3,5 Stunden. Kann ich das anders löschen. Mir wäre lieb wenn ich das Data Verzeichnis nur auf Veränderung abgleichen würde. Du sagst aber ja auch das unbedingt zusammen gesichert werden soll.
Gruß
Olaf
Hi Olaf,
schau dir dazu mal diesen Artikel an: Dort werden die Nextcloud-Backups nochmals mittels Borg Backup „verpackt“. Durch die Deduplizierung reduziert sich dadurch der Datenbestand ganz erheblich.
Eine Optimierung (damit das Backup dann schneller durchläuft) könnte sein, dass du das Nextcloud-Backup nicht mehr „zwischenparkst“, sondern direkt mittels Borg sicherst. D.h. dann, dass du das NC-Datenverzeichnis aus dem NC-Backup-Skript rausnimmst und dafür direkt über Borg sicherst.
Gruß,
Jan
Hi Jan,
danke, ja den Artikel hatte ich schon gelesen. Ich dachte an rsync oder Borg für das Data backup. Da muss ich mich dann mal beschäftigen. Ich mache das zu Zeit über 2 Pis. einer bei uns im Haus als Backup Server und der anderen Bei meinen Eltern über VPN als externes Backup.
Gruß
Olaf
Hi Olaf,
ja, Borg ist echt gut. Unbedingt mal ausprobieren, nach einem initialen Backup laufen subsequente Backups rasend schnell.
Gruß,
Jan
Hallo Jan,
hast Du zufällig eine Idee, warum nach dem Starten des Backup-Scripts beim Aufruf der Nextcloud keine Wartungsmeldung angezeigt wird, sondern stattdessen die Fehlermeldung: Öffnen der Seite fehlgeschlagen?
Ein Aufruf von „sudo -u www-data php occ maintenance:mode“ im Terminal ergibt die korrekte Ausgabe „Maintenance mode is currently enabled“.
Viele Grüße
Matthias
Vergiss die selten dämliche Frage. Bei gestopptem Webserver kann auch nicht viel anderes passieren. 😉
Hi Matthias,
ja, das liegt am gestoppten Webserver. Solange nur die Nextcloud vom Webserver ausgeliefert wird, ist eine Stoppen des Webservers zu empfehlen. Werden noch weitere Webanwendungen gehostet, kann man zur Not auch das Stoppen des Webservers aus den Skripten entfernen.
Gruß,
Jan
Hallo Jan,
ich habe dein Skript zum Sichern und Wiederherstellen der Nextcloud abgeändert, um meine Mattermost-Instanz zu sichern.
Habe das Backup getestet. Funktioniert. Danach kam der Test für den Restore dran. Dieser klappt auch allerdings mit der Ausnahme, dass mir der Besitzer der Mattermost-Ordner vom Nutzer Mattermost auf den Nutzer des Webservers umgeschrieben wird. Hast Du eine Idee woran dies liegen könnte?
Sonnige Grüße
Thomas
Hi Thomas,
das kommt drauf an, wo die Berechtigungen gesetzt werden. Wenn z.B. Mattermost unter /var/www/mattermost installiert wurde, dann musst du die Berechtigungen anders setzen, z.B. auf www-data für /var/www/nextcloud und mattermost für /var/www/mattermost (also nicht generell Berechtigungen setzen für /var/www).
Gruß,
Jan
Hallo Jan,
danke für Deine schnelle Antwort.
Hmmm … Ich stehe gerade bei deiner Erklärung etwas auf dem Schlauch …
Also, aufm Raspberry liegen Mattermost und Nextcloud in unterschiedlichen Ordnern und haben unterschiedliche Besitzer. Mattermost hat den User Mattermost und Nextcloud den User www-data.
Der übergeordnete Ordner /var/www hat noch mal nen ganz anderen Besitzer.
Ich kann nicht nachvollziehen wodurch beim Restore des Mattermost Backups (welches auf deinem Nextcloud-Backup-Skript mit entsprechenden Änderungen beruht) der Besitzer des Mattermost-Ordners von Mattermost auf www-data geändert wird.
Sonnige Grüße
Thomas
Hi Thomas,
OK, das sollte eigentlich funktionieren. Erweitere das Skript doch am Ende mal mit folgender Anweisung:
chown -R Mattermost:Mattermost /var/www/mattermostDas Verzeichnis noch entsprechend anpassen, je nachdem, wo Mattermost installiert wurde.
Gruß,
Jan
Hallo Jan,
oh Mann, so einfach … Es klappt! :-)
Vielen Dank
Thomas
Hallo Jan,
dank deiner Anleitung habe ich mehr oder weniger so wie beschrieben meine Nextcloud sowie das Backup eingerichtet.
Seit einiger Zeit macht aber das Backup Probleme. Mein System läuft auf einem NUC und das Backup wird auf eine externe (USB-) Festplatte gesichert (als NFTS formatiert). Bisher lief das immer wöchentlich nachts (die Daten auf der Nextcloud sind mittlerweile 300 GB groß). Jetzt läuft aber das Backup des Datenordners extrem lang (sicherlich über 24 Std.). Hast du eine Ahnung woran das liegen kann? Ich hab alternativ zu „tar“ auch mal „rsync“ ausprobiert und zwischenzeitlich habe ich auch die Platte formatiert. Genug Platz ist eigentlich auch. Aber wirklich schneller wurde es dadurch nicht. Bin etwas ratlos.
Beste Grüße
Benedikt
Hi Benedikt,
mit den Skripten sichert er eben immer die vollen 300 GB. Wenn du 300 GB manuell vom NUC auf die Platte kopierst, ist das dann ebenfalls so langsam?
Um die Menge der übertragenen Daten zu reduzieren, kann man die Backup-Strategie noch mittels Borg Backup ausbauen (deduplizierend, archivierend). Dazu kannst du dir ja mal diesen Artikel hier ansehen.
Gruß,
Jan
Hallo Jan,
ich möchte meine NC-Instanz, die mit/auf nextcloudpi läuft auf einen neuen Server umziehen. Die Backups nach deiner Anleitung erstellt, kann ich auch in der Nextcloud unter Ubuntu20.04 nach deiner Anleitung wiederherstellen? Vor allem bei der Datenbank bin ich mir nicht sicher wie ich das am besten mache. Muss in MariaDB dann der Name und Benutzer der Datenbank gleich heißen wie im Backup? Das würde ich zumindest mal annehmen.
Lg
Amelia
Hi Amelia,
im Prinzip kannst du die alte Installation einfach auf einem neuen Server übernehmen. Die Datenbank muss gleich heißen und Benutzer/Passwort müssen ebenso identisch zur alten Installation sein. Das ist aber kein Muss, diese Daten können nach dem Wiederherstellen des Backups auf dem neuen System auch mit der config.php von Nextcloud angepasst werden.
Auf jeden Fall müssen vor dem Wiederherstellen des Backups auf der neuen Maschine alle Voraussetzungen erfüllt werden (PHP, MariaDB/MySQL, etc.).
Hast du meine vorgefertigten Bash-Skripte für das Backup verwendet?
Gruß,
Jan
Hallo,
ich habe das Backup nach deiner Anleitung erstellt, ja. Also installiere und erstelle ich erst mal alles gleich wie bei der alten Installation und danach kann ich Datenbankname (z.B.) ändern, oder?
Hi Amelia,
genau, erst einmal das neue System vorbereiten (Installation aller Abhängigkeiten). Dann Datenbank und zugehörigen User per MySQL-Kommandozeile erstellen.
Nun vor dem Ausführen des Wiederherstellungs-Skripts in diesem die DB-Credentials anpassen. Skript ausführen und danach musst du ggf. noch in der wiederhergestellten config.php DB und User ändern.
Gruß,
Jan
Hi,
vielen Dank für die Antwort.
Ich habe schlussendlich lieber eine saubere Neuinstallation gemacht und anschließend die Daten kopiert. Ich hatte außerdem vormals Apache als Webserver und bin jetzt nach deiner Anleitung auf nginx umgestiegen.
Danke!
Hi Amelia,
klappt nach der Neuinstallation nun alles (inkl. NC Talk)?
Gruß,
Jan
Hey,
ja, alles klappt wunderbar eigentlich. Inzwischen läuft OnlyOffice und Talk. Gegenüber meinem Vorgänger nextcloudpi auf einem Raspi3 habe ich das Gefühl, die Cloud ist schon etwas performanter, flüssiger irgendwie.
Auf dem gleichen Server habe ich noch einen FirefoxSyncServer aufgesetzt, läuft auch wunderbar!
Jetzt müssen noch die Backups automatisch implementiert werden und dann plane ich noch WordPress nebenher laufen zu lassen…
Super Blog, Danke!
Hallo Jan,
sorry, dass ich in diesem Forum auch nochmal nerve. Ich hatte durch einen defekten USB-Stick einen Datenverlust meiner NC (16) auf dem Raspi mit Stretch. Kann ich ein dort erstelltes Backup in NC 20 wiederherstellen? Werden eigentlich grundsätzlich die Apps und Benutzerprofile dadurch quasi neu erstellt oder muss man vor der Wiederherstellung alle Apps installieren, die man vorher hatte?
Weil ich mir nicht sicher war, ob og. Vorgehen klappt, habe ich mir die NC16 installiert, die ich vorher hatte. Beim Einschalten des Maintenance-Modes kam dann eine Fehlermeldung, die ich zu spät verstand. Der PHP-Befehl muss bei mir PHP7.2 lauten, weil das ja in stretch nicht standardmäßig vorhanden ist. Die Fehlermeldung habe ich dennoch ignoriert, dann die Ordner gelöscht, Backup zurückgespielt, alles nach Deiner Anleitung. Beim SQL-Import kam dann noch ein Fehler wegen der Zeichenlänge,den ich aber auch beheben konnte. Dann hatte ich auch zwischenzeitlich das mit dem php-Befehl gecheckt, dann nochmal den repair-Befehl abgesetzt, was auch unbeanstandet ablief. Zuletzt nginx neu gestartet, Wartungsmodus beendet und, voilá: Internal server error.
error.log und access.log von nginx bringen mich nicht wirklich weiter. Es wird gemeckert, dass er eine „favicon.ico“ nicht findet – aber das klingt eigentlich nicht so schwerwiegend. Meinst Du, das kann man reparieren, oder soll ich einfach alle Ordner nochmal löschen und das Backup neu einspielen? Aber das funktioniert wahrscheinlich nur, wenn vorher einmal eine funktionierende NC-Instanz vorhanden war? Also NC deinstallieren, dann Deiner Installationsanleitung ab dem Punkt weiter folgen und dann das mit dem Backup nochmal machen? Wie schön, dass das beim Hamburger Wetter gar nicht schlimm ist, das ganze WE vor dem Rechner zu verbringen :-)
Viele Grüße
Johannes
Hallo Johannes,
zum Wiederherstellen des Backups muss vorher gar keine NC installiert sein. Nur die Domain muss vorher richtig eingerichtet sein (also nginx vHost, Let’s Encrypt, etc.). Nach der Wiederherstellung hast du dann eine Nextcloud der Version, die im Backup vorhanden war. Darauf aufbauend kannst du dann nach 17, dann nach 18, etc. updaten.
Hier sehe ich also eigentlich kein Problem. Einfach das Backup nochmal neu einspielen (vorher noch die bestehende DB löschen).
Gruß,
Jan
Hallo Jan, das ist ja perfekt! Dann mach ich das alles auf dem betören raspi, der ist ja viel schneller. Und das updaten ist auch unproblematisch? Ich hatte mal gelesen, dass bei bestimmten Versionssprüngen eine Neuinstallation besser sei – aber das hab ich vlt auch falsch verstanden. Mit dem maintenance mode hab ich dann aber in meinem Fall auch gar nix zu tun, oder?
VG Johannes
Hi Johannes,
Updates von Version 16 auf 19 (oder 20) sind meines Wissens nach unproblematisch. Wichtig ist nur, dass du immer von einer Major-Version auf die nächste updatest.
Mit dem Maintenance-Mode kommst du im Normalfall gar nicht in Berührung.
Gruß,
Jan
Hallo Jan,
wenn ich das doch direkt am Anfang gemacht hätte, dann hätte ich meine Urlaubswoche auch sinnvoller verbringen können. Läuft jetzt alles ganz gut, bei jedem Update gibt es 1-2 kleine Fehlerchen, die aber andere vor mir zum Glück auch schon hatten, so dass ich die Lösung abschreiben kann. Wie in der Schule. Bin jetzt schon bei Version 19, also fast am Ziel. Habe gesehen, dass ich dafür noch PHP updaten muss, aber auch das werde ich wohl schaffen! Vielen Dank für Deine Hilfe!
Viele Grüße
Johannes
Hi Johannes,
das klingt doch schon mal sehr gut. Das wichtigste ist aber denke ich, dass du bei deiner Wiederherstellungs-Aktion auch viel gelernt hast. Das bringt dich dann in Zukunft weiter, wenn du mal vor ähnlichen Problemen stehst.
Auf jeden Fall danke für die positive Rückmeldung!
Gruß,
Jan
Hallo Jan!
Sehr schöne und plausible Erklärungen!
Ich nutze NCP auf meinem Pi4. Ich möchte meine 64GB SD Karte auf 16 GB reduzieren und ein komplett frisches System inklusive frischer NCP aufsetzten. Als Datenspeicher möchte ich weiterhin meine HDD nutzen (mittelfristig möchte ich gerne auf SSD umsteigen). Daher mein Gedanke, das Vorhaben, wie von die oben beschrieben durchzuführen. Folgende Schritte habe ich dafür angedacht:
1.) Clients auf dem PC und Android abmelden
2.) Wartungsmodus einschalten:
sudo -u www-data php7.4 /var/www/nextcloud/occ maintenance:mode –on
3.) Sicherung der Datenbank:
mysqldump –single-transaction -h localhost -unextcloud -pnextcloud nextcloud > /home/osusername/ncdb_date +“%w“.sql
4.) Frische SD Karte mit frischer NCP in den Pi
5.) Wartungsmodus aktivieren
6.) Stoppen aller relevanter Services:
/usr/sbin/service nginx stop
/usr/sbin/service php7.4-fpm stop
7.) Löschen der Datenbank:
mysql -h localhost -uroot -pnextcloud -e “DROP DATABASE nextcloud”
8.) Anlegen einer leeren Datenbank:
mysql -h localhost -uroot -pnextcloud -e “CREATE DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci”
9.) Berechtigung setzten:
mysql -h localhost -uroot -pnextcloud -e “GRANT ALL PRIVILEGES on nextcloud.* to nextcloud@localhost”
10.) Datenbank herüber schieben:
mysql -h localhost -unextcloud -pnextcloud nextcloud < /home/osusername/ncdb_1.sql
11.) Neustart der Services:
/usr/sbin/service php7.4-fpm start
/usr/sbin/service nginx start
12.) Fingerprint setzten:
sudo -u www-data php7.4 /var/www/nextcloud/occ maintenance:data-fingerprint
13.) Wartungsmodus deaktivieren:
sudo -u www-data php7.4 /var/www/nextcloud/occ maintenance:mode –off
14.) Clients wieder anmelden
Sehe ich das so richtig?
Die Sicherung des Datenverzeichnisses sowie des Webverzeichnisses kann ich mir ja für dieses Vorhaben sparen (frisches System / alte Daten HDD behalten).
Weiterhin frage ich mich, wie ich mit der config.php umgehe. Einfach im frischen System den Pfad für die HDD anpassen?
Besten Gruß und vielen Dank im Voraus!
LG Karel
Hi Karel,
das Vorgehen ist so erst einmal richtig denke ich. Bedenke nur, dass NCP hier viele Sachen „extra“ hat, die eine normale NC-Instanz nicht hat.
Am sichersten ist denke ich mal, wenn du vor deinem Vorhaben ein komplettes Image der SD-Karte anfertigst, man weiß ja nie…
Die config.php würde ich aus der alten Installation mit rüber nehmen und am Zielsystem dann anpassen.
Gruß,
Jan
Hi Jan, danke für deine Antwort!
Ein Image werde ich vorher definitiv anfertigen!!!
Was wäre denn noch in der config.php mitzunehmen? Außer des angepassten Pfades für die Daten?
Gruß Karel
Hi Karel,
das kommt darauf an, was in der Cloud alles konfiguriert ist. Am besten die alte config.php irgendwo sicher abspeichern und wenn in der neuen Instanz dann irgendwas nicht mehr funktioniert/fehlt, dann in die alte config.php schauen, ob noch was vergessen wurde.
Gruß,
Jan
Okay super, das mache ich dann so. 2 Fragen habe ich allerdings noch.
Woran denkst du, als du meintest, dass NCP noch einige Sachen „extra“ hat?
Du hast beschrieben, beim Zurückspielen der DB wird nach dem Passwort gefragt. Ich habe allerdings diesbezüglich nie eines festgelegt…?
Grüße!
Hi Karel,
NCP hat doch doch viele Scripts, etc. an Board, um die Verwaltung der Cloud einfacher zu machen. Ob nach einem Restore das alles noch klappt, habe ich noch nicht ausprobiert, da ich immer nur auf „einfachen“ NC-Installationen unterwegs bin.
Mit dem Passwort bin in nun nicht sicher: Beim ersten Setup einer normalen NC-Instanz wird man immer nach dem Passwort des DB-Users gefragt. Ich wüsste nicht, dass man dies „umgehen“ kann. Aber vielleicht ist das genau so ein „Extra“, was durch NCP „versteckt“ wird.
Versuch einfach mal, dich mit dem NC-DB-User über die MySQL-Kommandozeile an der DB anzumelden. Wenn das auch ohne Passwort klappt, dann steht der Migration eigentlich nichts mehr im Wege.
Gruß,
Jan
Hi Jan!
Hat alles geklappt mittlerweile. Bei den Datenbank-Befehlen konnte ich das Passwort weglassen. Lediglich das Setzen der Berechtigung unter 9.) und das Stoppen der Services unter 6.) hat nicht funktioniert. Läuft allerdings trotzdem alles sauber auf der neuen SD Karte.
Danke für Deine Hilfe!
PS: Ich konnte auf deine letzten Kommentar nicht mehr antworten.