# ISPconfig3 backup bzw Serverumzug und Kundentransfer



## erazor666 (20. Juni 2010)

Hallo,
ich habe ein ISPconfig 3 laufen und möchte nun einen weiteren ISPc3 Host bei einem anderen Provider installieren. Da dieser Leistungsfähiger ist, möchte ich auch einige Kunden mit ihren gesamten Daten zum neuen Host verschieben.
Ich habe schon gesucht aber nichts zum Thema Backup/Restore, Backup einzelner Kunden, ... gefunden.
Ich frage mich momentan ob eine dieser Möglichkeiten funktionieren könnte?
1. SingleServer Setup - Kann ich ein Backup von einem User(inkl. files, DBs etc) auf Host A erstellen das ich in Host B wieder einspielen kann? (einzelne user transferieren) oder auch gleich alle user auf einmal backupen und am neuen Host restoren?

2. Multi Server Setup - kann ich Host B als Slave installieren und komplette Kunden per GUI verschieben? (hab leider nicht viel über die Multiserver Funktionen finden können) 

3. Wenn die beiden anderen Optionen nicht funktionieren: wie kann ich ein Backup der gesamten ISPconfig installation erstellen und auf Host B wieder einspielen? Danach könnte ich dann auf dem alten Host die dort nicht mehr benötigten Kunden löschen und auf dem neuen die löschen die nur auf dem alten Host bleiben sollen.

Mir wäre am liebsten wenn ich einzelne Kunden verschieben könnte, wenn  ich zB neue Provider(neue ISPc Hosts) dazu nehme zur Lastverteilung.

Vielen Dank für eure Tipps!
Gruß Marco


----------



## Till (20. Juni 2010)

1) nein.
2) nein.
3) ja, das geht. Aber nur wenn es sich um einen einzelnen Server, also kein Multiserver setup handelt oder aber Du einen bestehenden Server in einem Multiserver Verbund erstetzen willst. Denn in einem Multiserver setup sind alle Webs, user, etc. durch eine eindeutige ID gekennzeichnet und die würden beim einbinden eines kopiereten Systems in einen Multiserver Verbund kollidieren.

Umzug eines ISPConfig 3 Servers bzw. erstellen einer Serverkopie:

1) Kopiere alle web* user Zeilen aus den /etc/passwd und /etc/shadow Dateien auf das neue System.
2) Kopiere alle client* Gruppen Zeilen aus den /etc/group und /etc/gshadow Dateien auf das neue System.
3) Kopiere die Ordner /var/vmail und /var/www auf den neuen Server.
4) Kopiere die ISPConfig mysql Datenbank auf den neuen Server.
5) Kopiere die mysql Datenbanken der Webseiten auf den neuen Server. Außerdem müsst Du ggf. noch die User und DB Einträge aus der "mysql.mysql" Datenbank für diese Datenbanken mit phpmyadmin exportieren und auf dem neuen System importieren. Pass aber auf dass Du nur User und DB Einträge für die Webseiten / Client datenbanken kopierst und nicht aus versehen auch die Einträge für die ispconfig DB oder den mysql root User.


----------



## erazor666 (20. Juni 2010)

Vielen Dank für die schnelle Antwort!
Ok also 1-3 sind klar.

4-5 -> welche Datenbank Dateien sind dies und wo liegen sie ? Kann ich sie einfach per file copy übertragen?

mysql.mysql user + db  - sind das diese ??? (wo liegt sie?)

Server: localhost  -  Datenbank: mysql  -  Tabelle: db "Database privileges"
 Darin gibt es einträge "test , test% , ispconfig ..." und viele kundenids

Server: localhost -  Datenbank: mysql -  Tabelle: user "Users and global privileges"
Darin gibt es user "root, ispconfig, debian-sys-maint" und viele kunden ids ... 
http://babette.hostador.com/phpmyadmin/main.php?token=5ac1d0bba27fac18b00e0470ca520f8e
Ich soll also nur die kundenids aus beiden exportieren/importieren - richtig?


Danke!!!!


----------



## Till (20. Juni 2010)

> 4-5 -> welche Datenbank Dateien sind dies und wo liegen sie ? Kann  ich sie einfach per file copy übertragen?


/var/lib/mysql/

Ob Du sie als Dateien kopieren kannst, hängt vom gewählten Tabellentyp ab. MyIsam Tabellen kannst Du einfach durch kopieren der Verzeichnisse verschieben. Hast Du auch innodb Datenbanktabellen, dann musst Du sie per "mysqldump" Befehl exportieren und sie dann je nach Größe mit phpmyadmin (für kleine Datenbanken) oder dem mysql Shell Befehl wieder importieren.



> mysql.mysql user + db  - sind das diese ??? (wo liegt sie?)


Die sind auch in /var/lib/mysql. Da die diese Tabellen aber nicht komplett rüber kopieren darfst um ds neue Setup nicht zu zertsören, exportierst Du einfach nur die Zeieln die Du benötigst mit phpmyadmin.



> Ich soll also nur die kundenids aus beiden exportieren/importieren -  richtig?


Ja. Da die anderen Einträge Systemspezifisch sind.

Und noch was. Du musst natürlich ISPConfig vorher auf dem neuen System installiert haben, und zwar in der gleichen Version wie auf dem alten Server.


----------



## erazor666 (20. Juni 2010)

Ok ich werde es mal versuchen. 

Vielen Dank für die nette und schnelle Hilfe!


----------



## Greenhorn2013 (19. Juli 2012)

Gibt es hier einen neuen Sachstand?


----------



## Feanwulf (22. März 2013)

Ich gehe das gleich auch an - und werde dann ein Fedback geben ISPConfig 3.0.5.1


----------



## Feanwulf (22. März 2013)

Feedback: Kopieren ging soweit

Aber die VHOSTS, DNS Einträge usw sind natürlich noch nicht auf Platte geschrieben - muss ich das alles manuell machen oder kann man das irgendwie für alle DNS Zonen und Websites einfacher machen?

EDIT: Einfach gehts indem man 1 Eintag dann ändert und alle neu geschrieben werden (Vorher habe ich die DNS Einträge in der mySQL Datenbank mit UPDATE SET WHERE angepasst).


----------



## lehan (5. Apr. 2013)

Hallo

ich hab grad das gleiche vor bzw. befinde mich mittendrin. Durch einen dummen Fehler hab ich die client zeilen aus der /etc/shadow nicht kopiert - und auch keine Möglichkeit mehr auf die alte /etc/shadow zuzugreifen.

In der /etc/shadow sind ja normalerweise nur die Benutzernamen und Passwörter (und noch ein bischen mehr) gespeichert. Also dürften da doch nur diejenigen User drinstehen denen ich Shell-Zugang gewährt habe oder?

Das wäre bei mir eh nur einer gewesen. Wenn ich jetzt den usernamen manuell neu anlege und mittels passwd dem user ein neues PW gebe, dann sollte doch alles weiterhin funktionieren? Oder waren da noch andere Einträge drin? Der ispconfig bzw. ispapps Account sind ja durch die Installation angelegt worden.

Macht es eigentlich was wenn sich der Hostname des Systems zwischen dem Umzug / Migration ändert?

Vielen Dank!

Gruß
lehan


----------



## Till (5. Apr. 2013)

> In der /etc/shadow sind ja normalerweise nur die Benutzernamen und Passwörter (und noch ein bischen mehr) gespeichert. Also dürften da doch nur diejenigen User drinstehen denen ich Shell-Zugang gewährt habe oder?


Nein, dort stehen auch die web User drin. Jede Webseite hat einen eigenen User und eine eigene Gruppeunter der die Scripte der Webseite laufen.

Die einzge Möglichkeit die Dir bleibt ist das resync tool zu verwenden. dann werden die User neu angelegt, es kann aber sein dass sie andere ID's bekommen so dass die Dateien der Webs dann falschen Usern gehören.



> Macht es eigentlich was wenn sich der Hostname des Systems zwischen dem Umzug / Migration ändert?


Das macht nichts.


----------



## Brainfood (8. Apr. 2013)

Lust ein HowTo zu schreiben, was alles bei einem Serverumzug beachtet werden muss (Config/Datenbackup, Übergangslösungen per DNS/rinetd/Mail Relay etc. und importieren von alten ISPConfig DBs ins neue System) ?


----------



## lehan (21. Apr. 2013)

Hallo

bin endlich dazugekommen weiterzumachen.

Vor  dem Einspielen des Datenbankdumps habe ich alle darin vorkommenden  alten URLs des Servers mit der neuen ersetzt und diese dann über  Phpmyadmin eingespielt. Soweit auch kein Problem. Nur ist das ispconfig webinterface unglaublich langsam (phpmyadmin ist rasend schnell, beide angesprochen über die selbe Domain). Im Apache error_log hab ich beim Zugriff auf das WI folgende Meldung:


```
mod_fcgid: stderr: PHP Warning:  mysqli::mysqli(): (28000/1045): Access denied for user 'ispconfig'@'localhost' (using password: YES) in /usr/local/ispconfig/interface/lib/classes/db_mysql.inc.php on line 70, referer: https://domain.url:8080/
```
Liegt es daran das das WI so langsam ist? Muss hier irgendwo das PW für den user ispconfig angepasst werden?

Ich habe den alten Threat der bei der Suche rauskommt gelesen, der hat mich aber auch nicht weitergebracht.

Zu dem Problem mit der fehlenden shadow: Kann ich das Problem mit neuen IDs nicht einfach durch ein chown auf die neuen Besitzer erledigen?

Viele Grüße


----------



## Till (22. Apr. 2013)

Im Datenbank Dump sollte nichts geändert werden.



> Liegt es daran das das WI so langsam ist? Muss hier irgendwo das PW für den user ispconfig angepasst werden?


Ich vermute Du hast entweder Dateien in /usr/local/ispconfig/ auf dem neuen Server mit Daten des alten Servers überschrieben oder Du hast in der mysql.mysql DB den User ispconfig aif dem neuen Server mit Daten vom alten Server überschrieben, beides führt zu einem Ausfall von ispconfig, postfix, dovecot und FTP da keiner der dienste sich dann mehr mit mysql verbinden kann.



> Zu dem Problem mit der fehlenden shadow: Kann ich das Problem mit neuen IDs nicht einfach durch ein chown auf die neuen Besitzer erledigen?


Ja, aber die diversen Unetrverzeichnisse eiens Webs haben unterschiedliche User, Du müsstest also gut aufpassen dass Du nicht zu viele Dateien und Verzeichnisse änderst.


----------



## lehan (22. Apr. 2013)

Abermals vielen Dank für deine schnelle Antwort Till.

OK, dann darf ich den kompletten Datenbankdump nicht einfach so komplett zurückspielen, da ich ja hier dann auch die mysql.mysql auf dem neuen Server mit der alten Version überschreibe.

Ich hab gottseidank die Datenbank-files auch kopiert, dann spiele ich diese manuell zurück und importiere die User dann serperat. Das müsste ja klappen.


 Ich werde mich wieder melden ob es geklappt hat.

Viele Grüße


----------



## thommy (2. Sep. 2013)

mal als kurze Zusammenfassung unter der Voraussetzung, dass Quell- und Zielsystem die gleiche ISPC-Version haben und auf beiden Systemen die gleichen Systemuser bzw. -gruppen laufen:

/etc/passwd syncen
/etc/shadow syncen
/var/vmail copy alt > neu
/var/www copy alt > neu
/var/lib/mysql copy alt > neu

ich hab da noch was in dunkler erinnerung, dass es reicht wie folgt vorzugehen:
/var/vmail copy
/var/www copy
/var/lib/mysql copy
resync im ISPC

ist das soweit richtig?

Edith: wo gibts die aktuelle version vom Billing-Modul?


----------



## Till (3. Sep. 2013)

Ganz so einfach geht es nicht, ich habe die Vorgehensweise in Post #2 dieses Threads beschrieben.



> Edith: wo gibts die aktuelle version vom Billing-Modul?


Die aktuelle Version des Billing Moduls (Version 1.3) wurde bei Erscheinen Anfang des Jahres (zusammen mit dem 3.0.5 ISPConfig release) an alle Kunden per Email verschickt. Wenn Du die Version 1.3 nicht erhalten hast, dann schreib mir bte eine Email an die Adresse info [at] ispconfig [dot] org


----------



## Viperdriver2000 (8. Dez. 2013)

Ich habe da glaube ich nochmal ne blöde frage wo ich glaube die Antwort schon zu kennen, aber ich frage trotzdem mal.

Kurze Vorgeschichte.
Ich habe von meinem Server Backups erstellt.
/home
/var/www
/var/vmail

Mit mysqldumper habe ich alle DB gebackupt.

nun ist mir am Freitag meine Platte kaputt gegangen.

Habe ne neue bekommen und alles neu installiert.

Ich habe dann blauäugig wie ich bin meine alte DB von ispconfig wieder eingespielt. (von der frischen Installation habe ich ein Backup)
Sieht alles schön aus, weil ist ja alles da 
habe dann alles zurückgesichert und die Mails gehen auch. (ich war hoch erfreut )
Die webs leider nicht. Auch die DBs sind nicht da (also die Struktur so das ich den dump wieder einspielen könnte)

wenn ich das jetzt richtig gelesen habe, habe ich keine andere Wahl als die "leere" ispconfig db wieder einzuspielen und alles neu anzulegen?
ist das soweit richtig?
oder gibt es ne Möglichkeit das ispconfig das alles im nachhinein nochmal anlegt?`

Danke & Gruß
Vip


----------



## Brainfood (8. Dez. 2013)

Dein Backup war nur ne HalbeSache ...

/var/lib/mysql beinhaltet die kompletten MySQL Daten (mysqldump ist somit nicht nötig)

wenn du wirklich per Hand alles sichern + wiederherstellen willst:

*/etc*
*/usr/local/ispconfig*
*/var* (komplett)

tar pcvfz .... deinbackup.tar.gz (-p berücksichtigt die Berechtigungen)

dann sollte es genügen, Linux komplett neu aufzusetzen, alle gewünschten Packages vom vorherigen System nachinstallieren und einfach nur /etc, /usr/local/ispconfig und komplett /var (aus dem Backup) ins aktuelle system zu hängen


----------



## Till (9. Dez. 2013)

Wie Brainfood berets erläutert hat, war in Deinem backup leider nicht alles drin. Du kannst aber durchaus ISPConfig die Konfogurationnneu schreiben lassen, das geht ünder Tools > Resync. Es kann dann jedoch sein dass die Webseiten neue UID's bekommen, daher müsstest Du unter Umständen per chown die html / php dateien in den web verzeichnissen der einzelnen Seiten an die richtigen Web User anpassen.


----------



## Viperdriver2000 (11. Dez. 2013)

ah okay, danke. 
Aber leider hatte ich nun schon alle manuell neu angelegt


----------



## tomnick (13. Dez. 2013)

Was ist denn mit den ganzen vhost in /etc/apache2/sites-available, dort sind doch noch gar keine angelegt....manuell? Kopieren?


----------



## Till (16. Dez. 2013)

Dann ist Dein Server irgendwie nicht richtig installiert. Schau mal hier um die Ursache zu finden:

Debugging of ISPConfig 3 server actions in case of a failure « FAQforge


----------



## tomnick (16. Dez. 2013)

Zitat von Till:


> Dann ist Dein Server irgendwie nicht richtig installiert.


Ich glaube, ich habe mich blöd ausgedrückt. Ich bin verfahren wie unter #2+4 von Dir beschrieben. Das klappt auch alles hervorragend aber die vhost werden ja nicht mitübertragen. Mein Ispconfig hat auf dem Quellserver in /etc/apache2/sites-available für jede Domain eine meinedomain.de.vhost gebildet oder anders gesagt, das habe ich so verstanden, ansonsten hat der heilige Geist seine Finger mit im Spiel... das hat logischerweise zur Folge, das alle Domains auf /var/www verweisen. Deshalb war meine Frage, was mit den vhost Dateien zu tun ist oder bildet ispconfig irgendwann diese wieder selbst?


----------



## Till (16. Dez. 2013)

Ahh, ok. Hatte ich ganz vergessen  Logge Dich in ISPConfig ein, gehe zu tools > resync, aktiviere alle Optionen und klicke auf Resync.


----------



## tomnick (16. Dez. 2013)

Zitat von Till:


> Ahh, ok. Hatte ich ganz vergessen  Logge Dich in ISPConfig ein, gehe zu tools > resync, aktiviere alle Optionen und klicke auf Resync.


Yoh, das hatte ich bereits letzte Woche getan, danach war auf jeder Seite "Access denied". Kann es sein, das rysnc dann neue user angelegt hat die dann nicht mit dem kopierten Datenbestand konform laufen?


----------



## Till (16. Dez. 2013)

Du hast ja kein rsync auf /etc gemacht, daher kann es ja nicht sein.


----------



## tomnick (16. Dez. 2013)

Das resync hat aber völlig neue vhost in "/etc/apache2/sites-available" gebildet. Wo sollten sie denn sonst stehen?


----------



## renky (27. Feb. 2015)

Ich habe jetzt mal ein migrate-shell script erstellt über das ich gerne diskutieren möchte.
Achtung: das Scirpt ist noch nicht getestet - d.h. ich weiß nicht, ob es wirklich funktioniert. Ich habe versucht alle Punkte von Till einzubauen. Es sind aber dennoch anschließend noch manuelle Punkte zu erledigen - z.B. das resync oder auch das Kopieren der mysql-db und user Einträge mittels phpMyAdmin.
Bevor das migrate-script ausgeführt wird muss natürlich der neue Server eingerichtet sein und ispconfig installiert sein.


> #!/bin/bash
> 
> #Voraussetzung: Neuer Server hat ssh-Zugriff mit Key auf alten Server, migrate läuft auf neuem Server
> OLD_IP="x.x.x.x"           # or domain-name
> ...


Im Anschluss nun noch die mysql.db und mysql.users einträge vom alten auf den neuen Server kopieren und resyncs machen


----------



## st2xo (16. März 2015)

Zitat von Till:


> Umzug eines ISPConfig 3 Servers bzw. erstellen einer Serverkopie:


Würde dieser Komplettumzug durch Backups wie beschrieben auch von einem OpenSuse 13.x auf ein Debian-System funktionieren?


----------



## Till (16. März 2015)

Ich denke dass es generall auch zum Kopieren einer Installation zwischen 2 verschiedenen Distributionen gehen sollte. Schau aber zur Sicherheit vorher in die passswd Datei des Zielsystems ob es dort nicht bereits User mit den ID's der ispconfig web* User gibt.

@renky: Eine Sache ist mir gerade noch bezüglich der web* user aufgefallen, die hatte ich heute gerade in #8 in diesem Post beschrieben:

https://www.howtoforge.de/forum/threads/isp-config-3-migration.8607/

leider lässt sich das nicht so einfach automatisieren, due müsstest alle ID's der web user bestimmen und dann alle user mit diesen ID's exportieren. Da die shelluser der webs aliasuser sind, also die selbe ID wie der web* User des webs haben, hättest Du dann alle User in einem export.


----------



## renky (16. März 2015)

Hallo
Grundsätzlich wird das auch bei Distributions-Übergreifenden  Umzügen funktionieren - hier empfehle ich aber wirklcih das vorherige anschauen jeder einzelnen Datei, die dieses Script anfasst - z.B. wegen der sshuser-Gruppe -> die kann bei CentOS ganz anders aussehen als bei Debian, dann einfach die Zeile im Script entfernen. Das Dumpen von Mysql und auch das rsync der Verzeichnisse für vmail und www sollte identisch sein...
ich hab das script jetzt nochmal überarbeitet, weil ich es life bei einem Umzug verwendet habe (natürlich hab ich den Umzug ca. 5 Mal gemacht, weil das Script doch nicht überall so funktioniert hat wie ich wollte... Das Endergebnis war jetzt das folgende und auch hier gilt wieder OHNE GEWÄR - außerdem muss jeder durchschauen ob er auch all das was ich hier gemacht habe wirklich will - z.b. eben das Löschen der web-User auf dem neuen System, falls schon welche da sind.
@Till: die SSH-User habe ich jetzt auch einfach vom alten System übernommen mit den folgenden Befehlen:


> sed -i 's/^sshusers:.*$/'`grep sshusers: \/tmp\/oldgroup`'/' /etc/group
> sed -i 's/^sshusers:.*$/'`grep sshusers: \/tmp\/oldgshadow`'/' /etc/gshadow


Der Punkt ist aber: ich weiß genau, dass das passt - das alte System war debian, das neue auch, beide Male nur mit ISPConfig erstellt und in den ssh-usern war kein anderer User außer der 5002 und den web* drin. und die 5002 war auch auf dem neuen System drin -> also kein Problem - das bitte vorher prüfen.

Ansonsten habe ich noch folgende Tips:
1. Führt die rsync passage vorher durch, damit das Kopieren während der endgültigen eigentlichen Migration nicht zu heftig auffällt.
2. Wenn Ihr auch DNS-Server drauf habt, und Kundendomains und die Erreichbarkeit gewährleistet sein soll habe ich (erfolgreich) folgenden Plan: Timeouts aller DNS-Entries auf kurze Zeitspannen runtersetzen - ich bin sogar auf 180 Sekunden runter gegangen - lange vorher, damit beim eigentlichen Umzug nichts passieren kann. Wichtig war: ich hatte überall den gleichen Timeout drin - d.h. keine Kundenspezifischen sondereinstellungen - kann also hinterher wieder gekonnt überall auf den gleichen Wert hochsetzen. Wenn Ihr das so nicht habt, dann sichert Euch die dns_rr-Tabelle und die dns_soa-Tabelle vorher weg, damit Ihr die Timeouts habt.
3. Das zwischendrin stehende Script savedatabases.sh sollte auf der alten Maschine schonmal getestet worden sein und auch tatsächlcih den gebrauchten Output im tmp-Verzeichnis anlegen.
4. Wenn alles gesynct ist (soweit zumindest) die DNS-Einträge unten sind, dann das migrate Script durchführen. Und zwar auch mit den Befehlen zum stoppen der Services auf der alten Maschine. 5 Minuten ist dann halt alles nicht erreichbar.
5. Im Migrate Script werden die DNS-Einträge mit der neue IP Überschrieben und auch mit meiner Standard TTL -> anpassen, wem es so nicht passt.
6. Nach dem Migrate-Script im ISPConfig-Admin unter Tools -> Resyncen und zwar alles...

Und zuguterletzt noch eine Erfahrung aus meinem eigenen Umzug: beim Mysqlimport ist mir das neue System abgeschmiert... der Grund war am Ende, dass ich zu viele Datenbanken mit zu vielen Tabellen hatte, so dass mysql mit der Meldung "Error 24 - too much open files" ausgestiegen ist -> aber immer gleich so, dass nur ein kill geholfen hat... das hat mich beim gesamten Umzug einige Stunden gekostet, bis ich es endlich geglaubt habe, dass es wohl wahr sein muss und nachdem ich mich halb totgegoogelt habe in der Nacht, kam ich auf diesen Fix:
http://dev.mysql.com/doc/refman/5.5/en/server-options.html#c12634
Und auch NUR DIESER  hat beim Neustart effektiv geholfen - alle anderen Fixes die man im Internet findet waren nur von kurzer Dauer und halfen nur im Life-System... Was mir bis heute schleierhaft ist, ist warum es auf dem alten System ohne diese Änderung lief, wo ich doch nur genau die gleichen Datenbanken kopiert habe -> wenn jemand eine Lösung/Erklärung hierfür hat, ich bin offen für alle Ideen...

(Script folgt im nächsten Beitrag, weil der Beitrag sonst zu groß wäre  )


----------



## renky (16. März 2015)

Wie gesagt: ohne Gewähr


> #!/bin/bash
> 
> # What to do before:
> # Install ispconfig on new server in exactly the same version as on
> ...


----------



## Till (16. März 2015)

@renky: das was ich mit den SSH Usern meinte ist noch was anderes, es gibt schlicht user deren name nicht mit web* anfängt. Ich hab das gerade nochmal im anderen Thread weiter erläutert, daher poste ich es hier nicht nochmal.


----------



## renky (16. März 2015)

Ich hab das Problem falsch verstanden - ich dachte Du redest von der Gruppe "sshusers" -> das Problem hatte ich aber tatsächlich bei meinem Umzug nicht. Aber das kann man einfach noch erweitern: im Script auf dem Alten Server (savedatabases) wird noch eine weitere txt-Datei angelegt, die die Namen aller shelluser enthält, und diese können dann zusätzlich noch aus der olduser-Datei übernommen werden.


----------



## Viperdriver2000 (12. Aug. 2022)

Hey,
sorry wenn ich dieses uralten Thema nochmal wiederbelebe.
mein Debian möchte sich nicht mehr updaten lassen O und ich muss es neu installieren.
ich habe gerade noch kompletten zugriff und es läuft auch noch alles. ich habe ISPConfig 3.2.8p1
ich habe angefangen backups zu machen. diesmal versuche ich von allem backups zu haben ^^.

ist das was Till geschrieben hatte aus #2 noch aktuell?

mein backup habe ich jetzt wie folgt erstellt.


```
mysqldump -u root -p --events --all-databases --ignore-table=mysql.innodb_index_stats --ignore-table=mysql.innodb_table_stats > ~/db_backup/mysql-dump_$(date +"%Y-%m-%d_%s").sql
for i in $(cat ~/db_backup/databases-list); do mysqldump -u root -p --databases $i --ignore-table=mysql.innodb_index_stats --ignore-table=mysql.innodb_table_stats > ~/db_backup/mysql-dump-$i-$(date +"%Y-%m-%d_%s").sql; done
mysql mysql -u root -p -e 'show tables like "db%"' | grep -v Tables_in | xargs mysqldump mysql -u root -p > ~/db_backup/mysql-dump-mysql-db-$(date +"%Y-%m-%d_%s").sql
mysql mysql -u root -p -e 'show tables like "user%"' | grep -v Tables_in | xargs mysqldump mysql -u root -p > ~/db_backup/mysql-dump-mysql-user-$(date +"%Y-%m-%d_%s").sql

rsync -avAXEWSlHhP -e ssh -p 22 / --delete --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/cdrom/*,/lost+found} root@[BACKUPSERVER]:/home/rsync/  | tee rsync_$(date +"%Y-%m-%d_%s").log
```
damit sollte ich doch alles erschlagen haben, oder?
letzter step wäre alles stoppen und nochmal den rsync laufen lassen dann könnte ich den server reinstallen.
oder habe ich was übersehen?


----------

