Hallo,
wir haben eine Nextcloud 18.0.1 auf einer VM mit CentOS bei einem Hoster.
Nun soll diese Nexcloud-Instanz zu einem anderen Hoster auf einen dedizierten Server umziehen.
Bisher habe ich recherchiert, dass man die Nextcloud auf dem neuen Server frisch aufsetzen soll und dann die Daten, NC-Config und die DB per rsync rüberziehen soll.
Soweit… hab ich noch nie gemacht. Habt ihr Tips? Oder ein Tutorial, dass mir hilft oder eine andere Idee, die Nextcloud rüber zu ziehen?
Vielen Dank im Voraus!
Sehe ich genauso. Falls du Zugriff per SSH hast (wovon ich mal ausgehe), macht es Sinn sich die Anleitungen für Backup und Restore anzuschauen. Denn wirklich was anderes ist es nicht. Achte darauf, dass die Versionen identisch sind. Installiere evtl. beim neuen Hoster dafür auch die Version 18 und nicht die neue Version 19. Links [1] und [2] . Wahrscheinlich würde ich die Dateien nicht zippen, sondern einfach per rsync über ssh übertragen. Du solltest ein wenig Ahnung von Standard-Linux-Mechanismen haben. Meine Lieblingsanleitung ist im übrigen [3].
Falls es dir aber nur um die Verlagerung von Dateien geht und z. B. Shares sowieso nicht erhalten werden müssen oder können (neue Domain, …), kannst du auch die Nextcloud-Funktion “Federated Sharing” [4] verwenden. Hierbei muss dann jeder Benutzer seine Ordner für seinen neuen Benutzer in der neuen Cloud freigeben. Um den Aufwand zu minimieren kann der Benutzer vielleicht vorher zuvor alle Ordner in einen Ordner verschieben. Der dann für den neuen Benutzer freigegebene Ordner (user@server) bekommt der Benutzer dann in der neuen Cloud zugeordnet. Nun kann er die Inhalte aus der alten Cloud in die neue Cloud per WebDAV (Server zu Server) kopieren. Ein Download der Dateien ist für den Benutzer nicht notwendig. Ich habe das mal für ein paar Hundert MB Fotos durchgeführt. Funktionierte problemlos. Aber wie gesagt das gilt nur für Dateien. Der Rest muss vom Benutzer in der neuen Cloud dann neu aufgebaut werden.
[1] Backup — Nextcloud latest Administration Manual latest documentation
[2] Restoring backup — Nextcloud latest Administration Manual latest documentation
[3] How to Install NextCloud on Debian 10
[4] Federated-Sharing — Nextcloud latest Benutzerhandbuch latest documentation
1 Like
Danke für die schnelle Antwort.
Muss ich auch darauf achten, dass es das gleiche Betriebssystem ist oder ist das egal, wenn ich das per SSH mache?
Nein. Ohne es selbst jemals ausprobiert zu haben gehe ich davon aus, dass ein Wechsel des Betriebssystems möglich ist. Da jedoch die Strukturen in der MariaDB von der Nextcloud-Version abhängen, sehe ich Risiken bei abweichenden Nextcloud-Versionen.
Ich habe im übrigen meinen Beitrag gerade noch editiert und eine Anleitung für Debian Buster angefügt. Ich empfehle dir mal Debian Buster als Ziel-Betriebssystem.
Falls du zuhause einen alten sagen wir 10 Jahre alten Rechner hast, kannst du da ja mal ein Debian draufziehen, das Backup nach Anleitung machen und dann als Restore auf dem Debian-Rechner zurückspielen. Kannst natürlich auch Ubuntu usw. nehmen.
Vielleicht wird das nicht ganz funktionieren, da du für z. B. SSL-Zertifikate (Lets Encrypt) einen DynDNS-Eintrag und ein Port-Forwarding benötigst. Direkt im Internet wäre das weit einfacher. Aber beim Testen kannst du ja auch ausnahmsweise auf http:// stattt https:// setzen. Es geht darum zu testen, ob die Nextcloud überhaupt wieder läuft.
Solltest du die Nextcloud professionell nutzen so überlege mehr Wissen aufzubauen oder einen Nextcloud-Provider zu verwenden.
Falls es eine begrenzte Anzahl User ist (1-3) und nicht so viele Daten über das Netz müssen (10-20GB). Kannst Du auch die einfache Methode nehmen:
- Setze den Server auf
- Lösche auf dem Client die alte Verbindung, aber sage bei “Lokale Dateien löschen?” Nein
- Setze eine Neue Verbindung auf mit dem alten Directory zum neuen Server.
Die Sync sollte automatisch starten.
Du verlierst “nur” die alten historisierten Fileversionen, aber falls die für dich nicht von Interesse sind, ist das zu verschmerzen.
Nette und wirklich gute Idee. Wichtig ist natürlich vorher alles lokal synchronisiert zu haben. Ich denke aber, dass meine Idee mit “Federated Sharing” (Link 4 oben) schneller geht, da man die Daten zwischen zwei Servern im Internet und nicht zwischen Client und Server austauscht. Liegt aber vielleicht auch ein wenig an der eigenen Internetanbindung und der Datenmenge.