Der gro\u00dfe Umzug<\/strong>
![\"dg_umzug.png\"](\"https:\/\/hub.hubzilla.hu\/photo\/4d2fb827-b83a-4c1c-835c-355cbf9ada08-2.png\" "\\"dg_umzug.png\\"")
<\/a>
Keine Ahnung, ob dieser Artikel nun wirklich f\u00fcr andere interessant ist. Ich beschreibe hier den Umzug meines Hubzilla Hub Whoville<\/a> von einem Remote-Server zu einem anderen Remote-Server. Sowas ist nat\u00fcrlich auch immer ausgesprochen individuell und speziell, was die Voraussetzungen betrifft. Auf der anderen Seite beschreibe ich nat\u00fcrlich auch etliche Schritte und \u00dcberlegungen, die f\u00fcr vergleichbare Umzugspl\u00e4ne interessant sein k\u00f6nnten.
Nun denn... die
Voraussetzungen<\/h3>
<\/a>Keine Ahnung, ob dieser Artikel nun wirklich f\u00fcr andere interessant ist. Ich beschreibe hier den Umzug meines Hubzilla Hub Whoville<\/a> von einem Remote-Server zu einem anderen Remote-Server. Sowas ist nat\u00fcrlich auch immer ausgesprochen individuell und speziell, was die Voraussetzungen betrifft. Auf der anderen Seite beschreibe ich nat\u00fcrlich auch etliche Schritte und \u00dcberlegungen, die f\u00fcr vergleichbare Umzugspl\u00e4ne interessant sein k\u00f6nnten.
Nun denn... die
Voraussetzungen<\/h3>
bei MIR...
Ich habe meinen Hub "Whoville" auf einem VPS bei meinem ungarischen Hoster betrieben. Aus bestimmten Gr\u00fcnden wollte ich ihn nun aber zu einem anderen VPS bei einem anderen Hoster umziehen.
VPS 1<\/strong>
Beim urspr\u00fcnglichen Server, ich nenne ihn hier jetzt VPS 1, lief Hubzilla unter YunoHost. Allerdings \u2013 aus Gr\u00fcnden \u2013 nicht als YunoHost Hubzilla-App, sondern als manuelle Installation in einer YunoHost My_Webapp (weshalb, kann man hier<\/a> nachlesen). Da der Hub nun schon recht lange lief, hat sich einiges an Daten angesammelt. So belegte er im Webroot 29.5 GB, wobei der B\u00e4renanteil nat\u00fcrlich auf den Ordner "store" mit insgesamt 28.4 GB ging. Die Datenbank (MySQL) kam auf 16.3 GB. Und die letzte Backup-Datei (YunoHost Backup der My_Webapp) wog 32.4 GB.
VPS 2<\/strong>
Der neue Server, VPS 2, war noch recht "leer", aber bereits ebenfalls mit YunoHost "best\u00fcckt".
Selbstverst\u00e4ndlich habe ich Zugriff auf die DNS-Eintr\u00e4ge f\u00fcr die Domain "hubzilla.hu".
Ein gro\u00dfer Vorteil von YunoHost (neben etlichen anderen) ist, dass es Backup-Funktionen f\u00fcr die Apps gibt. Und ein Backup einer My_Webapp umfasst den kompletten Inhalt von Webroot, einen Datenbank-Dump (sofern es eine DB gibt), sowie System-Konfigurations-Dateien (was so unter \/etc<\/code> zu finden ist), die spezifisch f\u00fcr die Webapp sind und die ge\u00e4ndert wurden. Damit hatte ich in dem gro\u00dfen tar-Archiv also eigentlich alles, was ich ben\u00f6tige.
Der Plan<\/h3>
1. Die Nutzer mit Accounts per Rundmail (Hubzilla bietet mit dem Addon "Hubwall" eine einfache M\u00f6glichkeit daf\u00fcr an) \u00fcber die geplante Downtime (ich habe mit mindestens drei Stunden gerechnet... es wurden sogar vier) informieren.
2. Eine index.html<\/code> f\u00fcr eine Wartungs-Mitteilung erstellen.
3. Ein frisches Backup von My_Webapp auf VPS 1 erstellen.
4. Die DNS-Eintr\u00e4ge f\u00fcr hubzilla.hu<\/code>, vor allem aber f\u00fcr die Subdomain des Hub hub.hubzilla.hu<\/code> von der IP des VPS 1 auf die IP des VPS 2 "umbiegen" und ein wenig warten.
5. Sobald die neue IP publik ist, dann die Domains mit YunoHost auf VPS 2 \u00fcbernehmen und daf\u00fcr sorgen, dass Let's Encrypt Zertifikate erstellt werden.
6. Danach auf VPS 2 eine My_Webapp unter der Domain hub.hubzilla.hu<\/code> installieren und die index.html (mit dem Wartungshinweis) dort zun\u00e4chst "servieren".
7. Nun die aktuelle Backup-Datei (tar) von VPS 1 auf VPS 2 \u00fcbertragen.
8. Die Backup-Datei auf VPS 2 entpacken.
9. Den Inhalt des Backups auf VPS 2 anpassen (.htconfig.php<\/code>, Nginx- und PHP-Konfigirationsdateien).
10. Die noch fehlenden Pakete (gem\u00e4\u00df der Installationsanleitung von Hubzilla) installieren.
11. Den Datenbank-Dump aus dem Backup in die neue, noch leere DB von My_Webapp auf VPS 2 importieren.
12. Den Webroot-Inhalt des entpackten Backups nun ins neue Webroot der My_Webapp auf VPS 2 verschieben.
13. Die Konfigurationsdateien f\u00fcr Nginx und PHP an die entsprechenden Orte unter \/etc<\/code> bei VPS 2 verschieben.
14. Dienste neu starten und \u00fcberpr\u00fcfen, ob sie ordentlich laufen (Nginx und php-fpm) und checken, ob sie fehlerfrei gestartet wurden und laufen.
15. Wichtig! Den Cronjob einrichten.
16. Eigentlich nicht notwendig, weil Dienste ja neu gestartet, aber aus Sicherheitsgr\u00fcnden: Reboot von VPS 2.
17. Finger \u00fcberkreuzen, Sto\u00dfgebet gen Himmel, Whoville im Browser aufrufen.
Vor\u00fcberlegungen \/ Vorbereitung<\/h3>
Die Rundmail war schnell rausgeschickt. Ich hatte mir die Nacht von Ostersonntag auf Ostermontag f\u00fcr den Umzug vorgesehen, weil da am wenigsten Traffic und Zugriffe auf meinen Hub zu erwarten waren. Und auch die index.html<\/code> war rasch erstellt.
![\"wartungsindex.png\"](\"https:\/\/hub.hubzilla.hu\/photo\/b05189f0-7c10-4fe7-bb74-5c9a7aea64d5-2.png\" "\\"wartungsindex.png\\"")
<\/a>
F\u00fcr die \u00dcbertragung der doch recht gro\u00dfen Backup-Datei wollte ich nicht darauf zur\u00fcckgreifen, sie zun\u00e4chst auf meinen lokalen Rechner zu laden und anschlie\u00dfend von dort aus auf den neuen Server wieder hochzuladen. Das dauert auch bei guter Anbindung erstens ziemlich lange und erzeugt zus\u00e4tzliche vermeidbare Fehlerquellen (Fehler bei der Daten\u00fcbertragung). Klar war also, dass ich die Datei direkt von VPS 1 zu VPS 2 \u00fcbertragen wollte. Da entstand nat\u00fcrlich die Frage, ob mit sFTP, per SSH mit scp oder der SSH mittels rsync. Welche Vor- und Nachteile ergeben sich f\u00fcr meinen speziellen Zweck bei den einzelnen Methoden?
Und hier nun mein Gest\u00e4ndnis: Selbst wenn ich bei solchen Dingen schon eigene Ideen habe, frage ich gerne die "KI" (also ein LLM). In der Frage halte ich mich dann mit meinen eigenen Gedanken zur\u00fcck, um sie nicht zu beeinflussen. Und damit hole ich mir quasi eine "zweite Meinung" ein. Ich habe in der Vergangenheit die Erfahrung gemacht, dass ich auf diese Weise bestimmte Ansichten zu solchen Sachen bekomme, die mir sonst nicht so pr\u00e4sent waren. Das kann bei der Entscheidungsfindung durchaus helfen. Bis jetzt bin ich damit immer sehr gut gefahren. Aber das "dicke Ende" kommt noch... ich habe daf\u00fcr Grok verwendet... also die "KI" von dem p\u00f6hsen Pupen, dessen Namen man nicht laut aussprechen darf (alle, die das verwerflich finden, d\u00fcrfen mich gerne mal dort, wo die Sonne nie scheint und anschlie\u00dfend an ihrer Moral ersticken\u00a0\ud83d\ude09\ud83d\ude01). Ich habe in der Vergangenheit einfach die besten Erfahrungen mit genau diesem Dienst gemacht.
F\u00fcr eine \u00dcbertragung mit FTP h\u00e4tte ich mich erstmal wieder frisch einlesen m\u00fcssen... in die Nutzung auf der Kommandozeile. Im t\u00e4glichen Betrieb nutze ich ja nur Filezilla (und selten Dolphin) f\u00fcr solche \u00dcbertragungen. Das geht remote aber nicht einfach so. Ich h\u00e4tte scp<\/code> bevorzugt. Grok empfahl mir aber, mir doch einmal die Methode mit rsync<\/code> via SSH anzuschauen. Und das Argument war \u00fcberzeugend... w\u00e4hrend scp<\/code> n\u00e4mlich nicht "resumable" ist, also bei einem Verbindungsabbruch die Daten\u00fcbertragung diese nicht wieder aufnehmen kann, ist das bei rsync<\/code> der Fall. Hat mich \u00fcberzeugt! Und mit dem Parameter "--progress<\/code>" habe ich auch ein visuelles Feedback \u00fcber den Fortschritt der \u00dcbertragung, ohne andere Tools daf\u00fcr einsetzen zu m\u00fcssen.
Ich habe dann die anderen geplanten Schritte auch noch mit Grok "durchgesprochen". Insgesamt wurde mein Plan generell "abgenickt" und als erfolgversprechend gewertet.
Umzug<\/h3>
1. und 2. waren ja schon erledigt...
3. War auch rasch getan ("rasch" ist relativ... das Erstellen der Backup-Datei dauerte bei der Gr\u00f6\u00dfe auch immer schon knapp 20 Minuten auf dem alten, etwas schwachbr\u00fcstigen VPS 1). Nun lag die Datei\u00a0"20260405-225032.tar<\/code>" im Backupverzeichnis meines VPS 1.
4. Dann habe ich ab kurz vor 01:00 Uhr nachts die DNS-Eintr\u00e4ge vom alten auf das neue VPS umgebogen. Ab diesem Augenblick lag Whoville also im Koma (ich hatte unmittelbar zuvor die index.php<\/code> auf VPS 1, also dem alten VPS, in _index.php<\/code> umbenannt, damit in der Zeit, bis die neue IP bekannt war, nicht noch irgendwelche Aktivit\u00e4ten stattfinden konnten.
5. Als die Sache dann erledigt war, habe ich die beiden Domains bei YunoHost auf VPS 2 \u00fcbernommen. Let's Encrypt Zertifikate inklusive.
6. Das Installieren der My_Webapp (mit PHP und MySQL-Datenbank) war rasch erledigt. W\u00e4hrend Whoville auf VPS 1 noch mit php8.2 lief, habe ich bei der My_Webapp php8.4 ausgew\u00e4hlt. Die index.htm<\/code>l hochgeladen und nun wurde der Wartungshinweis angezeigt, wenn man Whoville aufgerufen hat.
7. Dann habe ich die Backup-Datei von VPS 1 nach VPS 2 \u00fcbertragen. Daf\u00fcr habe ich dann, aufgrund des Hinweises und der Emofehlung von Grok rsync via SSH verwendet. Schema:
rsync -av --progress \/pfad\/zum\/backup\/backup-datei.tar.gz \\
\u00a0 \u00a0 \u00a0 deinuser@DOMAIN-BEI-VPS2:\/pfad\/wohin\/auf\/vps2\/<\/code><\/pre>
Nach der \u00dcbertragung, die knapp 40 Minuten gedauert hat, habe ich auf VPS 2 die Backup-Datei vom Eingangsverzeichnis ins Webroot der frisch installierten My_Webapp verschoben.
8. Anschlie\u00dfend habe ich die Backup-Datei an Ort und Stelle entpackt. Das erzeugte ein Verzeichnis "apps<\/code>" unter welchem dann die ganzen Daten strukturiert lagen.
tar -xvf 20260405-225032.tar<\/code>
Auch dazu habe ich wieder einmal Grok konsultiert. Mir stellte sich n\u00e4mlich die Frage, wie es denn mit der Eigent\u00fcmer-Eigenschaft und den Rechten aussehen mag. Auch wenn es auf VPS 2 mit YunoHost die Benutzer\/Gruppen "my_webapp_1<\/code>" und "www-data<\/code>" gibt, so unterscheiden sich doch die Benutzer- und Gruppen-Id's wahrscheinlich. Also zumindest f\u00fcr "my_webapp_1<\/code>". Wie k\u00f6nnte ich denn sichergehen, dass die korrekten Eigent\u00fcmer bei den entpackten Dateien und Verzeichnissen gesetzt sind. Grok meinte, dass wahrscheinlich Probleme wegen unterschiedelicher numerischer Id's auftreten k\u00f6nnte und empfahl rekursiv die Eigent\u00fcmer zu setzen.
Es kam aber anders (angenehmer), als bef\u00fcrchtet. Ich nutze ja sehr gerne und quasi schon immer den Midnight Commander (mc<\/code>) f\u00fcr die bequeme Dateiverwaltung auf der Konsole. Das hatte ich auf VPS 2 nat\u00fcrlich auch installiert. Und mc<\/code> zeigte mir f\u00fcr die entpackten Daten tats\u00e4chlich auch die urspr\u00fcnglichen Besitzer an. Aber stimmen denn nun die numerischen Id's auch \u00fcberein? Tatsache! Dem war so. Beim Entpacken wurden also offensichtlich die Id's (also nur die von "my_webapp_1<\/code>", die Id f\u00fcr "www-data<\/code>" war bei beiden VPS ohnehin identisch) der Dateien und Verzeichnisse auf die aktuellen Id's von VPS 2 gesetzt. Also Benutzer sind ok. Ebenso waren die Rechte sauber \u00fcbernommen. Da brauchte ich nichts zu \u00e4ndern.
9. Nun ging es ans Anpassen der Konfiguration. BTW: Grok ist sehr gespr\u00e4chig. Es hat mit immer wieder auch gesagt, was ich denn wie anpassen m\u00fcsste. Ok... das habe ich dann \u00fcberlesen, denn das wusste ich ohnehin.
Zun\u00e4chst war die .htconfig.php dran<\/code>. Hier musste ich das Datenbank-Passwort aktualisieren. DB-Name und DB-Benutzername waren gleich geblieben, weil ich bei beiden VPS die My_Webapp als my_webapp_1<\/code> installiert hatte.
Au\u00dferdem habe ich noch den Pfad zu PHP anpassen m\u00fcssen, weil ich nun ja von php8.2<\/code> auf php8.4<\/code> umgestiegen bin:
\/\/ Location of PHP command line processor
App::$config['system']['php_path'] = '\/usr\/bin\/php8.4';<\/code><\/pre>
Ebenfalls mussten die beiden Dateien \/etc\/nginx\/conf.d\/hub.hubzilla.hu\/my_webapp.conf<\/code> und\u00a0\/etc\/nginx\/conf.d\/hub.hubzilla.hu\/my_webapp.d\/php.conf<\/code> jeweils von\u00a0\/var\/run\/php\/php[b]8.2[\/b]-fpm-my_webapp.sock<\/code> auf\u00a0\/var\/run\/php\/php[b]8.4[\/b]-fpm-my_webapp.sock<\/code> ge\u00e4ndert werden.
10. Wie auch bei der urspr\u00fcnglichen Installation<\/a> von Hubzilla in eine My_Webapp mussten noch einige Pakete installiert werden, weil sie nicht in einer Standard-Installation vorhanden waren. Der INSTALL.txt<\/code> aus der Hubzilla-Distribution kann man entnehmen, was notwendig ist. Auch das habe ich rasch erledigt.
11. Nun musste nur noch die Datenbank mit dem Dump aus dem Bckup "Bev\u00f6lkert" werden.
pv db.sql | mysql -u my_webapp -p my_webapp<\/code>
Dank "pv<\/code>" mit Fortschrittsbalken... hat bei der Gr\u00f6\u00dfe neun Minuten gedauert.
12. Dann habe ich den Inhalt des Backup-Webroot ins Webroot der neuen My_Webapp auf VPS 2 verschoben. Aus Bequemlichkeit mit dem Midnight Commander. Und nochmal die Besitzer und Rechte \u00fcberpr\u00fcft... alles ok.
13. Danach die ge\u00e4nderten Konfigurationsdateien (Punkt 9.) an die entsprechenden Stellen verschoben.
14. Nun die Dienste (Nginx und PHP-fpm) neu gestartet
yunohost service restart nginx
yunohost service restart php8.4-fpm<\/code><\/pre>
und ihren Status \u00fcberpr\u00fcft
yunohost service status nginx
yunohost service status php8.4-fpm<\/code><\/pre>
Alles im gr\u00fcnen Bereich!
15. Nun mit crontab -e<\/code> den Cronjob eingerichtet:
*\/10 * * * * cd \/var\/www\/my_webapp\/www && \/usr\/bin\/php8.4 Zotlabs\/Daemon\/Master.php Cron > \/dev\/null 2>&1<\/code>
Und \u00fcberpr\u00fcft: crontab -l<\/code>
16. Nachdem nun alles ordentlich aussah und ich auch keine Fehler oder St\u00f6rungen feststellen konnte, habe ich die _index.php<\/code> zur\u00fcck in index.php<\/code> umbenannt, den Ordner "apps" mit den Resten des entpackten Backups, und, um wirklich sicherzugehen, dass alles mit den aktuellen Konfigurationen l\u00e4uft, VPS 2 rebootet.
17. Es war inzwischen 04:30 Uhr geworden... und ich habe Whoville im Webbrowser aufgerufen...
Jawoll! Er war da! Und ich habe herumprobiert, auch ein Testposting abgesetzt und von einem anderen Dienst (Mastodon), wo es angekommen war (Zustellungsbericht war auch ok) kommentiert, was auch wieder sauber ankam.<\/strong>
Ich habe bis jetzt keine Probleme festgestellt. Es ist extrem geschmeidig gelaufen.<\/strong>
Sicherlich habe ich einiges unn\u00f6tig umst\u00e4ndlich gemacht, aber ich war halt an verschiedenen Stellen extrem vorsichtig und "mit dem Arsch an der Wand", weil mir ein gelungener Umzug mit meinem Haupt-Hub wirklich wichtig war.
Titelbild von Moondance<\/a> auf Pixabay<\/a><\/span><\/div><\/div>
<\/div>","width":640,"height":426}
Der Plan<\/h3>
1. Die Nutzer mit Accounts per Rundmail (Hubzilla bietet mit dem Addon "Hubwall" eine einfache M\u00f6glichkeit daf\u00fcr an) \u00fcber die geplante Downtime (ich habe mit mindestens drei Stunden gerechnet... es wurden sogar vier) informieren.
2. Eine index.html<\/code> f\u00fcr eine Wartungs-Mitteilung erstellen.
3. Ein frisches Backup von My_Webapp auf VPS 1 erstellen.
4. Die DNS-Eintr\u00e4ge f\u00fcr hubzilla.hu<\/code>, vor allem aber f\u00fcr die Subdomain des Hub hub.hubzilla.hu<\/code> von der IP des VPS 1 auf die IP des VPS 2 "umbiegen" und ein wenig warten.
5. Sobald die neue IP publik ist, dann die Domains mit YunoHost auf VPS 2 \u00fcbernehmen und daf\u00fcr sorgen, dass Let's Encrypt Zertifikate erstellt werden.
6. Danach auf VPS 2 eine My_Webapp unter der Domain hub.hubzilla.hu<\/code> installieren und die index.html (mit dem Wartungshinweis) dort zun\u00e4chst "servieren".
7. Nun die aktuelle Backup-Datei (tar) von VPS 1 auf VPS 2 \u00fcbertragen.
8. Die Backup-Datei auf VPS 2 entpacken.
9. Den Inhalt des Backups auf VPS 2 anpassen (.htconfig.php<\/code>, Nginx- und PHP-Konfigirationsdateien).
10. Die noch fehlenden Pakete (gem\u00e4\u00df der Installationsanleitung von Hubzilla) installieren.
11. Den Datenbank-Dump aus dem Backup in die neue, noch leere DB von My_Webapp auf VPS 2 importieren.
12. Den Webroot-Inhalt des entpackten Backups nun ins neue Webroot der My_Webapp auf VPS 2 verschieben.
13. Die Konfigurationsdateien f\u00fcr Nginx und PHP an die entsprechenden Orte unter \/etc<\/code> bei VPS 2 verschieben.
14. Dienste neu starten und \u00fcberpr\u00fcfen, ob sie ordentlich laufen (Nginx und php-fpm) und checken, ob sie fehlerfrei gestartet wurden und laufen.
15. Wichtig! Den Cronjob einrichten.
16. Eigentlich nicht notwendig, weil Dienste ja neu gestartet, aber aus Sicherheitsgr\u00fcnden: Reboot von VPS 2.
17. Finger \u00fcberkreuzen, Sto\u00dfgebet gen Himmel, Whoville im Browser aufrufen.
Vor\u00fcberlegungen \/ Vorbereitung<\/h3>
Die Rundmail war schnell rausgeschickt. Ich hatte mir die Nacht von Ostersonntag auf Ostermontag f\u00fcr den Umzug vorgesehen, weil da am wenigsten Traffic und Zugriffe auf meinen Hub zu erwarten waren. Und auch die index.html<\/code> war rasch erstellt.
<\/a>
F\u00fcr die \u00dcbertragung der doch recht gro\u00dfen Backup-Datei wollte ich nicht darauf zur\u00fcckgreifen, sie zun\u00e4chst auf meinen lokalen Rechner zu laden und anschlie\u00dfend von dort aus auf den neuen Server wieder hochzuladen. Das dauert auch bei guter Anbindung erstens ziemlich lange und erzeugt zus\u00e4tzliche vermeidbare Fehlerquellen (Fehler bei der Daten\u00fcbertragung). Klar war also, dass ich die Datei direkt von VPS 1 zu VPS 2 \u00fcbertragen wollte. Da entstand nat\u00fcrlich die Frage, ob mit sFTP, per SSH mit scp oder der SSH mittels rsync. Welche Vor- und Nachteile ergeben sich f\u00fcr meinen speziellen Zweck bei den einzelnen Methoden?
Und hier nun mein Gest\u00e4ndnis: Selbst wenn ich bei solchen Dingen schon eigene Ideen habe, frage ich gerne die "KI" (also ein LLM). In der Frage halte ich mich dann mit meinen eigenen Gedanken zur\u00fcck, um sie nicht zu beeinflussen. Und damit hole ich mir quasi eine "zweite Meinung" ein. Ich habe in der Vergangenheit die Erfahrung gemacht, dass ich auf diese Weise bestimmte Ansichten zu solchen Sachen bekomme, die mir sonst nicht so pr\u00e4sent waren. Das kann bei der Entscheidungsfindung durchaus helfen. Bis jetzt bin ich damit immer sehr gut gefahren. Aber das "dicke Ende" kommt noch... ich habe daf\u00fcr Grok verwendet... also die "KI" von dem p\u00f6hsen Pupen, dessen Namen man nicht laut aussprechen darf (alle, die das verwerflich finden, d\u00fcrfen mich gerne mal dort, wo die Sonne nie scheint und anschlie\u00dfend an ihrer Moral ersticken\u00a0\ud83d\ude09\ud83d\ude01). Ich habe in der Vergangenheit einfach die besten Erfahrungen mit genau diesem Dienst gemacht.
F\u00fcr eine \u00dcbertragung mit FTP h\u00e4tte ich mich erstmal wieder frisch einlesen m\u00fcssen... in die Nutzung auf der Kommandozeile. Im t\u00e4glichen Betrieb nutze ich ja nur Filezilla (und selten Dolphin) f\u00fcr solche \u00dcbertragungen. Das geht remote aber nicht einfach so. Ich h\u00e4tte scp<\/code> bevorzugt. Grok empfahl mir aber, mir doch einmal die Methode mit rsync<\/code> via SSH anzuschauen. Und das Argument war \u00fcberzeugend... w\u00e4hrend scp<\/code> n\u00e4mlich nicht "resumable" ist, also bei einem Verbindungsabbruch die Daten\u00fcbertragung diese nicht wieder aufnehmen kann, ist das bei rsync<\/code> der Fall. Hat mich \u00fcberzeugt! Und mit dem Parameter "--progress<\/code>" habe ich auch ein visuelles Feedback \u00fcber den Fortschritt der \u00dcbertragung, ohne andere Tools daf\u00fcr einsetzen zu m\u00fcssen.
Ich habe dann die anderen geplanten Schritte auch noch mit Grok "durchgesprochen". Insgesamt wurde mein Plan generell "abgenickt" und als erfolgversprechend gewertet.
Umzug<\/h3>
1. und 2. waren ja schon erledigt...
3. War auch rasch getan ("rasch" ist relativ... das Erstellen der Backup-Datei dauerte bei der Gr\u00f6\u00dfe auch immer schon knapp 20 Minuten auf dem alten, etwas schwachbr\u00fcstigen VPS 1). Nun lag die Datei\u00a0"20260405-225032.tar<\/code>" im Backupverzeichnis meines VPS 1.
4. Dann habe ich ab kurz vor 01:00 Uhr nachts die DNS-Eintr\u00e4ge vom alten auf das neue VPS umgebogen. Ab diesem Augenblick lag Whoville also im Koma (ich hatte unmittelbar zuvor die index.php<\/code> auf VPS 1, also dem alten VPS, in _index.php<\/code> umbenannt, damit in der Zeit, bis die neue IP bekannt war, nicht noch irgendwelche Aktivit\u00e4ten stattfinden konnten.
5. Als die Sache dann erledigt war, habe ich die beiden Domains bei YunoHost auf VPS 2 \u00fcbernommen. Let's Encrypt Zertifikate inklusive.
6. Das Installieren der My_Webapp (mit PHP und MySQL-Datenbank) war rasch erledigt. W\u00e4hrend Whoville auf VPS 1 noch mit php8.2 lief, habe ich bei der My_Webapp php8.4 ausgew\u00e4hlt. Die index.htm<\/code>l hochgeladen und nun wurde der Wartungshinweis angezeigt, wenn man Whoville aufgerufen hat.
7. Dann habe ich die Backup-Datei von VPS 1 nach VPS 2 \u00fcbertragen. Daf\u00fcr habe ich dann, aufgrund des Hinweises und der Emofehlung von Grok rsync via SSH verwendet. Schema:
rsync -av --progress \/pfad\/zum\/backup\/backup-datei.tar.gz \\
\u00a0 \u00a0 \u00a0 deinuser@DOMAIN-BEI-VPS2:\/pfad\/wohin\/auf\/vps2\/<\/code><\/pre>
Nach der \u00dcbertragung, die knapp 40 Minuten gedauert hat, habe ich auf VPS 2 die Backup-Datei vom Eingangsverzeichnis ins Webroot der frisch installierten My_Webapp verschoben.
8. Anschlie\u00dfend habe ich die Backup-Datei an Ort und Stelle entpackt. Das erzeugte ein Verzeichnis "apps<\/code>" unter welchem dann die ganzen Daten strukturiert lagen.
tar -xvf 20260405-225032.tar<\/code>
Auch dazu habe ich wieder einmal Grok konsultiert. Mir stellte sich n\u00e4mlich die Frage, wie es denn mit der Eigent\u00fcmer-Eigenschaft und den Rechten aussehen mag. Auch wenn es auf VPS 2 mit YunoHost die Benutzer\/Gruppen "my_webapp_1<\/code>" und "www-data<\/code>" gibt, so unterscheiden sich doch die Benutzer- und Gruppen-Id's wahrscheinlich. Also zumindest f\u00fcr "my_webapp_1<\/code>". Wie k\u00f6nnte ich denn sichergehen, dass die korrekten Eigent\u00fcmer bei den entpackten Dateien und Verzeichnissen gesetzt sind. Grok meinte, dass wahrscheinlich Probleme wegen unterschiedelicher numerischer Id's auftreten k\u00f6nnte und empfahl rekursiv die Eigent\u00fcmer zu setzen.
Es kam aber anders (angenehmer), als bef\u00fcrchtet. Ich nutze ja sehr gerne und quasi schon immer den Midnight Commander (mc<\/code>) f\u00fcr die bequeme Dateiverwaltung auf der Konsole. Das hatte ich auf VPS 2 nat\u00fcrlich auch installiert. Und mc<\/code> zeigte mir f\u00fcr die entpackten Daten tats\u00e4chlich auch die urspr\u00fcnglichen Besitzer an. Aber stimmen denn nun die numerischen Id's auch \u00fcberein? Tatsache! Dem war so. Beim Entpacken wurden also offensichtlich die Id's (also nur die von "my_webapp_1<\/code>", die Id f\u00fcr "www-data<\/code>" war bei beiden VPS ohnehin identisch) der Dateien und Verzeichnisse auf die aktuellen Id's von VPS 2 gesetzt. Also Benutzer sind ok. Ebenso waren die Rechte sauber \u00fcbernommen. Da brauchte ich nichts zu \u00e4ndern.
9. Nun ging es ans Anpassen der Konfiguration. BTW: Grok ist sehr gespr\u00e4chig. Es hat mit immer wieder auch gesagt, was ich denn wie anpassen m\u00fcsste. Ok... das habe ich dann \u00fcberlesen, denn das wusste ich ohnehin.
Zun\u00e4chst war die .htconfig.php dran<\/code>. Hier musste ich das Datenbank-Passwort aktualisieren. DB-Name und DB-Benutzername waren gleich geblieben, weil ich bei beiden VPS die My_Webapp als my_webapp_1<\/code> installiert hatte.
Au\u00dferdem habe ich noch den Pfad zu PHP anpassen m\u00fcssen, weil ich nun ja von php8.2<\/code> auf php8.4<\/code> umgestiegen bin:
\/\/ Location of PHP command line processor
App::$config['system']['php_path'] = '\/usr\/bin\/php8.4';<\/code><\/pre>
Ebenfalls mussten die beiden Dateien \/etc\/nginx\/conf.d\/hub.hubzilla.hu\/my_webapp.conf<\/code> und\u00a0\/etc\/nginx\/conf.d\/hub.hubzilla.hu\/my_webapp.d\/php.conf<\/code> jeweils von\u00a0\/var\/run\/php\/php[b]8.2[\/b]-fpm-my_webapp.sock<\/code> auf\u00a0\/var\/run\/php\/php[b]8.4[\/b]-fpm-my_webapp.sock<\/code> ge\u00e4ndert werden.
10. Wie auch bei der urspr\u00fcnglichen Installation<\/a> von Hubzilla in eine My_Webapp mussten noch einige Pakete installiert werden, weil sie nicht in einer Standard-Installation vorhanden waren. Der INSTALL.txt<\/code> aus der Hubzilla-Distribution kann man entnehmen, was notwendig ist. Auch das habe ich rasch erledigt.
11. Nun musste nur noch die Datenbank mit dem Dump aus dem Bckup "Bev\u00f6lkert" werden.
pv db.sql | mysql -u my_webapp -p my_webapp<\/code>
Dank "pv<\/code>" mit Fortschrittsbalken... hat bei der Gr\u00f6\u00dfe neun Minuten gedauert.
12. Dann habe ich den Inhalt des Backup-Webroot ins Webroot der neuen My_Webapp auf VPS 2 verschoben. Aus Bequemlichkeit mit dem Midnight Commander. Und nochmal die Besitzer und Rechte \u00fcberpr\u00fcft... alles ok.
13. Danach die ge\u00e4nderten Konfigurationsdateien (Punkt 9.) an die entsprechenden Stellen verschoben.
14. Nun die Dienste (Nginx und PHP-fpm) neu gestartet
yunohost service restart nginx
yunohost service restart php8.4-fpm<\/code><\/pre>
und ihren Status \u00fcberpr\u00fcft
yunohost service status nginx
yunohost service status php8.4-fpm<\/code><\/pre>
Alles im gr\u00fcnen Bereich!
15. Nun mit crontab -e<\/code> den Cronjob eingerichtet:
*\/10 * * * * cd \/var\/www\/my_webapp\/www && \/usr\/bin\/php8.4 Zotlabs\/Daemon\/Master.php Cron > \/dev\/null 2>&1<\/code>
Und \u00fcberpr\u00fcft: crontab -l<\/code>
16. Nachdem nun alles ordentlich aussah und ich auch keine Fehler oder St\u00f6rungen feststellen konnte, habe ich die _index.php<\/code> zur\u00fcck in index.php<\/code> umbenannt, den Ordner "apps" mit den Resten des entpackten Backups, und, um wirklich sicherzugehen, dass alles mit den aktuellen Konfigurationen l\u00e4uft, VPS 2 rebootet.
17. Es war inzwischen 04:30 Uhr geworden... und ich habe Whoville im Webbrowser aufgerufen...
Jawoll! Er war da! Und ich habe herumprobiert, auch ein Testposting abgesetzt und von einem anderen Dienst (Mastodon), wo es angekommen war (Zustellungsbericht war auch ok) kommentiert, was auch wieder sauber ankam.<\/strong>
Ich habe bis jetzt keine Probleme festgestellt. Es ist extrem geschmeidig gelaufen.<\/strong>
Sicherlich habe ich einiges unn\u00f6tig umst\u00e4ndlich gemacht, aber ich war halt an verschiedenen Stellen extrem vorsichtig und "mit dem Arsch an der Wand", weil mir ein gelungener Umzug mit meinem Haupt-Hub wirklich wichtig war.
Titelbild von Moondance<\/a> auf Pixabay<\/a><\/span><\/div><\/div>
<\/div>","width":640,"height":426}
3. Ein frisches Backup von My_Webapp auf VPS 1 erstellen.
4. Die DNS-Eintr\u00e4ge f\u00fcr
hubzilla.hu<\/code>, vor allem aber f\u00fcr die Subdomain des Hub hub.hubzilla.hu<\/code> von der IP des VPS 1 auf die IP des VPS 2 "umbiegen" und ein wenig warten.
5. Sobald die neue IP publik ist, dann die Domains mit YunoHost auf VPS 2 \u00fcbernehmen und daf\u00fcr sorgen, dass Let's Encrypt Zertifikate erstellt werden.
6. Danach auf VPS 2 eine My_Webapp unter der Domain hub.hubzilla.hu<\/code> installieren und die index.html (mit dem Wartungshinweis) dort zun\u00e4chst "servieren".
7. Nun die aktuelle Backup-Datei (tar) von VPS 1 auf VPS 2 \u00fcbertragen.
8. Die Backup-Datei auf VPS 2 entpacken.
9. Den Inhalt des Backups auf VPS 2 anpassen (.htconfig.php<\/code>, Nginx- und PHP-Konfigirationsdateien).
10. Die noch fehlenden Pakete (gem\u00e4\u00df der Installationsanleitung von Hubzilla) installieren.
11. Den Datenbank-Dump aus dem Backup in die neue, noch leere DB von My_Webapp auf VPS 2 importieren.
12. Den Webroot-Inhalt des entpackten Backups nun ins neue Webroot der My_Webapp auf VPS 2 verschieben.
13. Die Konfigurationsdateien f\u00fcr Nginx und PHP an die entsprechenden Orte unter \/etc<\/code> bei VPS 2 verschieben.
14. Dienste neu starten und \u00fcberpr\u00fcfen, ob sie ordentlich laufen (Nginx und php-fpm) und checken, ob sie fehlerfrei gestartet wurden und laufen.
15. Wichtig! Den Cronjob einrichten.
16. Eigentlich nicht notwendig, weil Dienste ja neu gestartet, aber aus Sicherheitsgr\u00fcnden: Reboot von VPS 2.
17. Finger \u00fcberkreuzen, Sto\u00dfgebet gen Himmel, Whoville im Browser aufrufen.
Vor\u00fcberlegungen \/ Vorbereitung<\/h3>
Die Rundmail war schnell rausgeschickt. Ich hatte mir die Nacht von Ostersonntag auf Ostermontag f\u00fcr den Umzug vorgesehen, weil da am wenigsten Traffic und Zugriffe auf meinen Hub zu erwarten waren. Und auch die index.html<\/code> war rasch erstellt.
<\/a>
F\u00fcr die \u00dcbertragung der doch recht gro\u00dfen Backup-Datei wollte ich nicht darauf zur\u00fcckgreifen, sie zun\u00e4chst auf meinen lokalen Rechner zu laden und anschlie\u00dfend von dort aus auf den neuen Server wieder hochzuladen. Das dauert auch bei guter Anbindung erstens ziemlich lange und erzeugt zus\u00e4tzliche vermeidbare Fehlerquellen (Fehler bei der Daten\u00fcbertragung). Klar war also, dass ich die Datei direkt von VPS 1 zu VPS 2 \u00fcbertragen wollte. Da entstand nat\u00fcrlich die Frage, ob mit sFTP, per SSH mit scp oder der SSH mittels rsync. Welche Vor- und Nachteile ergeben sich f\u00fcr meinen speziellen Zweck bei den einzelnen Methoden?
Und hier nun mein Gest\u00e4ndnis: Selbst wenn ich bei solchen Dingen schon eigene Ideen habe, frage ich gerne die "KI" (also ein LLM). In der Frage halte ich mich dann mit meinen eigenen Gedanken zur\u00fcck, um sie nicht zu beeinflussen. Und damit hole ich mir quasi eine "zweite Meinung" ein. Ich habe in der Vergangenheit die Erfahrung gemacht, dass ich auf diese Weise bestimmte Ansichten zu solchen Sachen bekomme, die mir sonst nicht so pr\u00e4sent waren. Das kann bei der Entscheidungsfindung durchaus helfen. Bis jetzt bin ich damit immer sehr gut gefahren. Aber das "dicke Ende" kommt noch... ich habe daf\u00fcr Grok verwendet... also die "KI" von dem p\u00f6hsen Pupen, dessen Namen man nicht laut aussprechen darf (alle, die das verwerflich finden, d\u00fcrfen mich gerne mal dort, wo die Sonne nie scheint und anschlie\u00dfend an ihrer Moral ersticken\u00a0\ud83d\ude09\ud83d\ude01). Ich habe in der Vergangenheit einfach die besten Erfahrungen mit genau diesem Dienst gemacht.
F\u00fcr eine \u00dcbertragung mit FTP h\u00e4tte ich mich erstmal wieder frisch einlesen m\u00fcssen... in die Nutzung auf der Kommandozeile. Im t\u00e4glichen Betrieb nutze ich ja nur Filezilla (und selten Dolphin) f\u00fcr solche \u00dcbertragungen. Das geht remote aber nicht einfach so. Ich h\u00e4tte scp<\/code> bevorzugt. Grok empfahl mir aber, mir doch einmal die Methode mit rsync<\/code> via SSH anzuschauen. Und das Argument war \u00fcberzeugend... w\u00e4hrend scp<\/code> n\u00e4mlich nicht "resumable" ist, also bei einem Verbindungsabbruch die Daten\u00fcbertragung diese nicht wieder aufnehmen kann, ist das bei rsync<\/code> der Fall. Hat mich \u00fcberzeugt! Und mit dem Parameter "--progress<\/code>" habe ich auch ein visuelles Feedback \u00fcber den Fortschritt der \u00dcbertragung, ohne andere Tools daf\u00fcr einsetzen zu m\u00fcssen.
Ich habe dann die anderen geplanten Schritte auch noch mit Grok "durchgesprochen". Insgesamt wurde mein Plan generell "abgenickt" und als erfolgversprechend gewertet.
Umzug<\/h3>
1. und 2. waren ja schon erledigt...
3. War auch rasch getan ("rasch" ist relativ... das Erstellen der Backup-Datei dauerte bei der Gr\u00f6\u00dfe auch immer schon knapp 20 Minuten auf dem alten, etwas schwachbr\u00fcstigen VPS 1). Nun lag die Datei\u00a0"20260405-225032.tar<\/code>" im Backupverzeichnis meines VPS 1.
4. Dann habe ich ab kurz vor 01:00 Uhr nachts die DNS-Eintr\u00e4ge vom alten auf das neue VPS umgebogen. Ab diesem Augenblick lag Whoville also im Koma (ich hatte unmittelbar zuvor die index.php<\/code> auf VPS 1, also dem alten VPS, in _index.php<\/code> umbenannt, damit in der Zeit, bis die neue IP bekannt war, nicht noch irgendwelche Aktivit\u00e4ten stattfinden konnten.
5. Als die Sache dann erledigt war, habe ich die beiden Domains bei YunoHost auf VPS 2 \u00fcbernommen. Let's Encrypt Zertifikate inklusive.
6. Das Installieren der My_Webapp (mit PHP und MySQL-Datenbank) war rasch erledigt. W\u00e4hrend Whoville auf VPS 1 noch mit php8.2 lief, habe ich bei der My_Webapp php8.4 ausgew\u00e4hlt. Die index.htm<\/code>l hochgeladen und nun wurde der Wartungshinweis angezeigt, wenn man Whoville aufgerufen hat.
7. Dann habe ich die Backup-Datei von VPS 1 nach VPS 2 \u00fcbertragen. Daf\u00fcr habe ich dann, aufgrund des Hinweises und der Emofehlung von Grok rsync via SSH verwendet. Schema:
rsync -av --progress \/pfad\/zum\/backup\/backup-datei.tar.gz \\
\u00a0 \u00a0 \u00a0 deinuser@DOMAIN-BEI-VPS2:\/pfad\/wohin\/auf\/vps2\/<\/code><\/pre>
Nach der \u00dcbertragung, die knapp 40 Minuten gedauert hat, habe ich auf VPS 2 die Backup-Datei vom Eingangsverzeichnis ins Webroot der frisch installierten My_Webapp verschoben.
8. Anschlie\u00dfend habe ich die Backup-Datei an Ort und Stelle entpackt. Das erzeugte ein Verzeichnis "apps<\/code>" unter welchem dann die ganzen Daten strukturiert lagen.
tar -xvf 20260405-225032.tar<\/code>
Auch dazu habe ich wieder einmal Grok konsultiert. Mir stellte sich n\u00e4mlich die Frage, wie es denn mit der Eigent\u00fcmer-Eigenschaft und den Rechten aussehen mag. Auch wenn es auf VPS 2 mit YunoHost die Benutzer\/Gruppen "my_webapp_1<\/code>" und "www-data<\/code>" gibt, so unterscheiden sich doch die Benutzer- und Gruppen-Id's wahrscheinlich. Also zumindest f\u00fcr "my_webapp_1<\/code>". Wie k\u00f6nnte ich denn sichergehen, dass die korrekten Eigent\u00fcmer bei den entpackten Dateien und Verzeichnissen gesetzt sind. Grok meinte, dass wahrscheinlich Probleme wegen unterschiedelicher numerischer Id's auftreten k\u00f6nnte und empfahl rekursiv die Eigent\u00fcmer zu setzen.
Es kam aber anders (angenehmer), als bef\u00fcrchtet. Ich nutze ja sehr gerne und quasi schon immer den Midnight Commander (mc<\/code>) f\u00fcr die bequeme Dateiverwaltung auf der Konsole. Das hatte ich auf VPS 2 nat\u00fcrlich auch installiert. Und mc<\/code> zeigte mir f\u00fcr die entpackten Daten tats\u00e4chlich auch die urspr\u00fcnglichen Besitzer an. Aber stimmen denn nun die numerischen Id's auch \u00fcberein? Tatsache! Dem war so. Beim Entpacken wurden also offensichtlich die Id's (also nur die von "my_webapp_1<\/code>", die Id f\u00fcr "www-data<\/code>" war bei beiden VPS ohnehin identisch) der Dateien und Verzeichnisse auf die aktuellen Id's von VPS 2 gesetzt. Also Benutzer sind ok. Ebenso waren die Rechte sauber \u00fcbernommen. Da brauchte ich nichts zu \u00e4ndern.
9. Nun ging es ans Anpassen der Konfiguration. BTW: Grok ist sehr gespr\u00e4chig. Es hat mit immer wieder auch gesagt, was ich denn wie anpassen m\u00fcsste. Ok... das habe ich dann \u00fcberlesen, denn das wusste ich ohnehin.
Zun\u00e4chst war die .htconfig.php dran<\/code>. Hier musste ich das Datenbank-Passwort aktualisieren. DB-Name und DB-Benutzername waren gleich geblieben, weil ich bei beiden VPS die My_Webapp als my_webapp_1<\/code> installiert hatte.
Au\u00dferdem habe ich noch den Pfad zu PHP anpassen m\u00fcssen, weil ich nun ja von php8.2<\/code> auf php8.4<\/code> umgestiegen bin:
\/\/ Location of PHP command line processor
App::$config['system']['php_path'] = '\/usr\/bin\/php8.4';<\/code><\/pre>
Ebenfalls mussten die beiden Dateien \/etc\/nginx\/conf.d\/hub.hubzilla.hu\/my_webapp.conf<\/code> und\u00a0\/etc\/nginx\/conf.d\/hub.hubzilla.hu\/my_webapp.d\/php.conf<\/code> jeweils von\u00a0\/var\/run\/php\/php[b]8.2[\/b]-fpm-my_webapp.sock<\/code> auf\u00a0\/var\/run\/php\/php[b]8.4[\/b]-fpm-my_webapp.sock<\/code> ge\u00e4ndert werden.
10. Wie auch bei der urspr\u00fcnglichen Installation<\/a> von Hubzilla in eine My_Webapp mussten noch einige Pakete installiert werden, weil sie nicht in einer Standard-Installation vorhanden waren. Der INSTALL.txt<\/code> aus der Hubzilla-Distribution kann man entnehmen, was notwendig ist. Auch das habe ich rasch erledigt.
11. Nun musste nur noch die Datenbank mit dem Dump aus dem Bckup "Bev\u00f6lkert" werden.
pv db.sql | mysql -u my_webapp -p my_webapp<\/code>
Dank "pv<\/code>" mit Fortschrittsbalken... hat bei der Gr\u00f6\u00dfe neun Minuten gedauert.
12. Dann habe ich den Inhalt des Backup-Webroot ins Webroot der neuen My_Webapp auf VPS 2 verschoben. Aus Bequemlichkeit mit dem Midnight Commander. Und nochmal die Besitzer und Rechte \u00fcberpr\u00fcft... alles ok.
13. Danach die ge\u00e4nderten Konfigurationsdateien (Punkt 9.) an die entsprechenden Stellen verschoben.
14. Nun die Dienste (Nginx und PHP-fpm) neu gestartet
yunohost service restart nginx
yunohost service restart php8.4-fpm<\/code><\/pre>
und ihren Status \u00fcberpr\u00fcft
yunohost service status nginx
yunohost service status php8.4-fpm<\/code><\/pre>
Alles im gr\u00fcnen Bereich!
15. Nun mit crontab -e<\/code> den Cronjob eingerichtet:
*\/10 * * * * cd \/var\/www\/my_webapp\/www && \/usr\/bin\/php8.4 Zotlabs\/Daemon\/Master.php Cron > \/dev\/null 2>&1<\/code>
Und \u00fcberpr\u00fcft: crontab -l<\/code>
16. Nachdem nun alles ordentlich aussah und ich auch keine Fehler oder St\u00f6rungen feststellen konnte, habe ich die _index.php<\/code> zur\u00fcck in index.php<\/code> umbenannt, den Ordner "apps" mit den Resten des entpackten Backups, und, um wirklich sicherzugehen, dass alles mit den aktuellen Konfigurationen l\u00e4uft, VPS 2 rebootet.
17. Es war inzwischen 04:30 Uhr geworden... und ich habe Whoville im Webbrowser aufgerufen...
Jawoll! Er war da! Und ich habe herumprobiert, auch ein Testposting abgesetzt und von einem anderen Dienst (Mastodon), wo es angekommen war (Zustellungsbericht war auch ok) kommentiert, was auch wieder sauber ankam.<\/strong>
Ich habe bis jetzt keine Probleme festgestellt. Es ist extrem geschmeidig gelaufen.<\/strong>
Sicherlich habe ich einiges unn\u00f6tig umst\u00e4ndlich gemacht, aber ich war halt an verschiedenen Stellen extrem vorsichtig und "mit dem Arsch an der Wand", weil mir ein gelungener Umzug mit meinem Haupt-Hub wirklich wichtig war.
Titelbild von Moondance<\/a> auf Pixabay<\/a><\/span><\/div><\/div>
<\/div>","width":640,"height":426}