Im folgenden möchte ich euch ein kleines Howto geben wie man einen Umzug eines Confixx Servers auf eine andere Maschine vornimmt, und vor allem welche Klippen man überwinden muss um dies alles erfolgreich zum Abschluss zu bringen. Vorab bleibt zu erwähnen. Das schlimmste was jeweils passieren kann ist kein Backup zu haben. Die Zeit, welche man für den gesamten Umzug benötigt, ist stark von der Datenmenge und der Art der Kunden Webs abhängig. Die größte Zeit benötigt das Backup auf dem Quellen Server. Aber auch beim Restore kann die Zeit lang werden wenn zum Beispiel eine Datenbank enthalten ist eines phpBB Forums mit einer Millionen Einträge fassenden Wordlist Tabelle.
Ich habe das ganzen vorher 3 mal trainiert, unser Confixx hatte 85 Webs und der ganze Durchlauf mit Backup, Rsync, Restore hat damit gute 12 Stunden gebraucht. Was das Howto verschweigt, was aber enorm wichtig ist zu wissen:
1. Die webx werden ja durchnummeriert. Oft löscht man ja auch mal ein web zwischen drin. Nach dem Restore werden die webx wieder neu durchnummeriert, die Lücken verschwinden und was vorher web50 war wird dann plötzlich zu web45 oder so. Da daran alle Benutzer hängen ist das eine Katastrophe wenn man vor dem Backup die Lücken nicht mit Dummys auffüllt!
2. Unbedingt die selben Confixx Versionen verwenden UND die selben Optionen über die admin.pl setzen. Vergisst man das und hat auf dem Zielserver Dienste abgeschaltet die aber Kunden zugewiesen waren verlieren alle diese Kunden die Eigenschaften. Das kann ungemütlich werden.
3. mySQL. Bei unserem Backup waren einige Dumps der Datenbanken faul, vielen Primärschlüssel Spalten in Tabellen hat im Dump der auto_increment Wert gefehlt. Das macht die Datenbanken nach dem Restore unbenutzbar. Dies ist ein bekannter Bug bei verschiedenen mySQL Versionen.
Wir haben diese Datenbanken nachträglich von Hand verschoben, was komischerweise, bei Benutzung der selben Tools, dann funktioniert.
Der Umzug selber wurde im Detail zu 99% nach dem Howto von Data Travelers durchgeführt. Die Einzigste Änderung, da wir mit dem Backup / Transfer / Restore und einer recht langen Wartezeit zu rechnen hatten haben wir das nicht aktiv in der SSH Sitzung ausgeführt sondern die Prozesse jeweils in den Hintergrund geschickt und die Ausgaben in ein Log File umgeleitet. Das empfehle ich auf jeden Fall, da die SSH Sitzung zwischen drin abreißen kann, entweder wegen Timeout, wegen Inaktivität oder auch weil der DSL Router mal zickt oder andere Dinge auf dem Weg durchs Netz hier stören.
Daher die drei Befehle ca. so erweitert:
./backup.pl --dump /backup/bak -sm > /root/backup.log 2>&1 &
Punkt 1 ist quatsch. Ich habe ca 50 Serverumzüge hintermir und mir ist das noch nie passiert das sich webs geändert haben. Wäre auch nicht tragbar wenn das so wäre. Es müssten alle Kundenscripte angepasst werden.
Punkt 2 ist auch quatsch. Diese Einstellungen spielen keine Rolle. Das Backup wird trozdem ohne Fehler eingespielt.
Punkt 3 ist mir auch noch nicht passiert.
Kleiner Tipp vielleicht. Ich mache die Confixx Backups auch wie bei Data Travelers beschrieben wird. Nur kopiere ich zuvor die Kundendaten raus. Also alle webs, alle eMails und alle Datenbanken. Anschließend das Backup durchlaufen lassen. So ist das Backup in wenigen Minuten beendet. Anschließend die Kundendaten wieder rein kopieren. Somit ist ein geringer Ausfall für die Kunden zu erwarten. Anschließend das Backup auf dem Zielserver einspielen. Danach die Dummy Ordner für eMail MySQl und Webs auf dem Zielserver löschen und die Daten per rsync vom Quellserver kopieren. Somit stört es auch nicht, wenn beim Übertragen der Daten die SSH Verbindung unterbricht. Die Daten werden weiter kopiert. Auch fällt die Wartezeit für das Packen der Daten weg. Es besteht auch kein Risiko, dass eine der gepackten Datei beschädigt und somit unbrauchbar ist. Das einzigste ist der Traffic. Der muss natürich darunter etwas leiden. Aber die Server heutzutage haben in der Regel genug Traffic und wer meint er muss 1000 Kunden pro Server verwalten der ist eh nicht mehr ganz bei Trost. Bei mir gibt es maximal 50-70 Kunden pro Server bzw vServer.