Jump to content
Froxlor Forum
  • 0

Backup für vollständigen Umzug auf andere Debian Version


CoXx-World
 Share

Question

Mahlzeit, wie mache Ich am besten ein komplettes Backup um einen Umzug auf Debian 10 zu vollstrecken?

Also Froxlor läuft derzeit auf Jessie, möchte aber gerne auf Buster umsteigen.

Wie bekomme Ich es am einfachsten hin das alle vHosts, eMail konten, lets encrypt, benutzerdaten bzw alles was derzeit über Froxlor läuft, mit wenig Arbeit auf einen neuen Server mit Buster 1 zu 1 kopiert bzw übernommen wird?

Gibt es da eventuell was zum ausführen, falls nicht, auch nicht schlimm? 🤣

 

Es gibt zwar normalerweise keine dumme Fragen, aber komme mir doch ziemlich Doof dabei vor 😅

Link to comment
Share on other sites

16 answers to this question

Recommended Posts

  • 0
16 minutes ago, CoXx-World said:

Gibt es da eventuell was zum ausführen, falls nicht, auch nicht schlimm? 🤣

Kein all-in-one-start-and-go Wunderwerkzeug nein.

1) Backup aller Daten machen / Snapshot der VM / o.Ä.

2) rsync /var/customers/* von alt auf neu

3) rsync /var/www/froxlor von alt auf neu

4) alle dienste auf dem alten stoppen

5) nochmal rsync /var/customer/* (abgleich von geänderten daten, sollte dann minimal sein)

6) auf dem neuen server sollte schon installiert sein: webserver, php, mysql/mariadb server

7) mysql auf dem neuen stoppen

😎 rsync von /var/lib/mysql/* von alt auf neu (alle Datenbanken, Dateien etc. mysql aktualisiert die dann selbst und die ganzen Benutzer/Kennwörter der Datenbank user sind noch da)

9) msql auf neuem starten

10) falls neue ip /var/www/froxlor/install/scripts/switch-server-ip.php script verwenden

11) /var/www/froxlor/install/scripts/config-services.php script verwenden, um alle dienste für buster zu installieren und konfigurieren (customized configs vom alten server ggfls nachpflegen sofern notwendig)

und sofern ich nicht irgendwas vergessen habe sollte es das eigentlich schon sein

 

Link to comment
Share on other sites

  • 0
Am 21.1.2021 um 19:07 schrieb d00p:

Kein all-in-one-start-and-go Wunderwerkzeug nein.

1) Backup aller Daten machen / Snapshot der VM / o.Ä.

2) rsync /var/customers/* von alt auf neu

3) rsync /var/www/froxlor von alt auf neu

4) alle dienste auf dem alten stoppen

5) nochmal rsync /var/customer/* (abgleich von geänderten daten, sollte dann minimal sein)

6) auf dem neuen server sollte schon installiert sein: webserver, php, mysql/mariadb server

7) mysql auf dem neuen stoppen

😎 rsync von /var/lib/mysql/* von alt auf neu (alle Datenbanken, Dateien etc. mysql aktualisiert die dann selbst und die ganzen Benutzer/Kennwörter der Datenbank user sind noch da)

9) msql auf neuem starten

10) falls neue ip /var/www/froxlor/install/scripts/switch-server-ip.php script verwenden

11) /var/www/froxlor/install/scripts/config-services.php script verwenden, um alle dienste für buster zu installieren und konfigurieren (customized configs vom alten server ggfls nachpflegen sofern notwendig)

und sofern ich nicht irgendwas vergessen habe sollte es das eigentlich schon sein

 

Hey, 

stehe gerade vor einer ähnlichen Challenge. Muss schnell von debian 9 auf einen neuen VPS mit debian 10.

Schritt 1-9 passt soweit - d.h. ich habe froxlor mal grundsätzlich installiert und alle services via Maske neu installiert / eingerichtet.

Problem:

Ich hänge gerade an der PHP Konfiguration! 

Zitat

Mar 04 16:32:39 x apachectl[30354]: AH00526: Syntax error on line 26 of /etc/apache2/sites-enabled/x.x.de.conf:
Mar 04 16:32:39 x apachectl[30354]: SuexecUserGroup configured, but suEXEC is disabled: Missing suexec binary /usr/lib/apache2/suexec

Dabei brauche ich das glaube ich gar nicht?! 

Wie kann ich den Server an der Stelle einfach 1:1 migrieren?

Danke!

Link to comment
Share on other sites

  • 0

Na du hast wohl FCGID aktiviert und das nicht eingerichtet...(wie vorher auf dem alten server mit Hilfe der Froxlor Configuration-Templates für FCGID).

Link to comment
Share on other sites

  • 0

Hallo, nach langer Zeit habe ich begonnen die Migration durchzuführen und bin allen oben beschriebenen Schritten gefolgt. Das Problem ist nun, dass, wenn ich versuche, die froxlor-Startseite zu öffnen, mir nur die Apache-Willkommensseite angezeigt wird.
Ich habe bereits den ipswitch und die froxlor serverconfig ausgeführt.
Haben Sie eine Idee?
(mit dem Übersetzer geschrieben, sorry für die Formulierung)

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Link to comment
Share on other sites

  • 0
El 2/2/2021 a las 5:20 PM, Patricio Medina dijo:

Muchas gracias. 

Voy a cambiar a Ubuntu desde un servidor que ejecuta Debian e intentaré estos pasos. Disculpe mi alemán

Ja !!

Anscheinend war es nur ein kleines Problem. Ich bin kein Experte, aber ich habe es gelöst, indem ich a2ensite 000-default.conf ausgeführt habe
Ich verstehe nicht genau, warum es gelöst wurde (vielleicht könnte es jemand erklären), aber jetzt funktioniert es unter www.example.com/froxlor. Jetzt werde ich weiter konfigurieren, danke.

Link to comment
Share on other sites

  • 0
On 1/21/2021 at 7:07 PM, d00p said:

😎 rsync von /var/lib/mysql/* von alt auf neu (alle Datenbanken, Dateien etc. mysql aktualisiert die dann selbst und die ganzen Benutzer/Kennwörter der Datenbank user sind noch da)

bei mir zeigt froxlor aber leider nicht die „alten“ werte an; also kunden, domains, zertifikate, etc fehlt alles im webinterface

 

//Edit

Oh ok anscheinend ein Cache Problem.

Link to comment
Share on other sites

  • 0

ich komm grad nicht drauf warum das mi dem db umzug nicht klappen will

A database error occurred
SQLSTATE[HY000] [1045] Access denied for user 'root'@'127.0.0.1' (using password: YES)

auchwenn ich mich per root in der konsole anmelde habe ich keine rechte

select User,host,plugin from mysql.user;
ERROR 1356 (HY000): View 'mysql.user' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

jemand ne idee?

Link to comment
Share on other sites

  • 0

du hast also 1:1 dein /var/lib/mysql/ Verzeichnis auf einen anderen Server ge-synced ja? auch mit entsprechenden Parametern und alle Berechtigungen und Ownerships beizubehalten, etc.?

War dabei (hoffentlich) auf beiden Servern der mysql-dienst aus? und natürlich zu beachten: debian legt einen "debian-sys-maint" user an, mit dem er z.B. das jetzt relevante "mysql_upgrade" ausführt, d.h. du musst hier vom alten Server auch die /etc/mysql/debian.cnf mit übernehmen, damit der debian-sys-maint user des "alten" systems auf dem neuen auch das selbe passwort für den mysql dienst hat

 

Link to comment
Share on other sites

  • 0

Also folgendes habe ich übertragen auf den neuen Server

rsync -avz /var/lib/mysql/
rsync -avz /etc/mysql

mit a sollte ja alles 1:1 übergeben werden

ja mariadb hab ich davor gestoppt

 

das interessante ist das das wohl nicht auf alle datenbanken und user zutrifft; die froxlor db funktioniert problemlos z.B.

 

ja kennwörter sind alle gleich, ziehe eigentlich nur von einer vm in einen container um; das backup im container kann einzelne dateien wiederherstellen.

Link to comment
Share on other sites

  • 0
47 minutes ago, d00p said:

debian legt einen "debian-sys-maint" user an

hmm den user sehe ich jedenfalls nirgends in der config

debian.cnf alter server

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = localhost
user     = root
password = 
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = root
password = 
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

debian.cnf neuer server; backup der config dateien

# THIS FILE IS OBSOLETE. STOP USING IT IF POSSIBLE.
# This file exists only for backwards compatibility for
# tools that run '--defaults-file=/etc/mysql/debian.cnf'
# and have root level access to the local filesystem.
# With those permissions one can run 'mariadb' directly
# anyway thanks to unix socket authentication and hence
# this file is useless. See package README for more info.
[client]
host     = localhost
user     = root
[mysql_upgrade]
host     = localhost
user     = root
# THIS FILE WILL BE REMOVED IN A FUTURE DEBIAN RELEASE.

 

Link to comment
Share on other sites

  • 0

Wie du unschwer erkennen kannst nutzt du dann den user "root" eben für diese Zwecke. Ich kann dir allerdings so nicht groß weiterhelfen, ich habe schon etliche Migrationen gemacht, in Bezug auf Mysql genauso wie du - ich hatte nie Probleme - ggfls. liegts am Container? Mag da vllt mysql + root + unprivileged oder sowas eine Rolle spielen? 

Link to comment
Share on other sites

  • 0
1 hour ago, d00p said:

Wie du unschwer erkennen kannst nutzt du dann den user "root" eben für diese Zwecke.

Die Datei hatte ich davor noch nie offen, daher ist mir das gerade nur aufgefallen

 

vor der migration hatte ich das problem mit dem befehl nicht, da konnte ich per root alles machen

werd wohl den mariadb server nochmal purgen und dann wohl mit dumps arbeiten müssen.

 

also hab schon 3 Server auf Container umgezogen ganz ohne Probleme. Der größte unterschied ist halt wie auf die Systemressourcen zugegriffen wird, das sollte ja die db nicht stören.

Link to comment
Share on other sites

  • 0

sehr interessant, ich habe jetzt mariadb neu installiert, dann zuerst das kennwort geändert dann de server gestoppt und die daten kopiert und nach dem start klappt es jetzt

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...