migration | siyman.de | blogging und GNU/*buntu

Nachdem mein Hoster netcup.de mich vor einem halben Jahr über die geplante Umstellung auf KVM anstelle von Linux vServer informiert hat, wurde ich nun rechtlich zwar sauber aber ethisch nicht ganz nett dazu genötigt, meinen Server zu migrieren. Damit das alles so wenig zeitaufwendig und komplikationslos wie möglich abläuft, ich aber kein Backup der Installation durchführen konnte, musste ich also alle Daten kopieren respektive adaptieren. Aber wo fängt man an, wo hört man auf, und wie hat man die geringste Last auf der eigenen Leitung – gerade beim Upload?

Zunächst habe ich meine Distribution gewechselt. Anstelle von Debian 6.0 Squeeze läuft nun ein Ubuntu Server 12.04.2 LTS. Warum? LTS! Damit habe ich theoretisch bis 2017 Ruhe vor einer neuen Migrationsrunde, und sollte das mit der Zwangsmigration bei netcup.de weiter so laufen, dann werde ich bis dahin auch immer wieder neue Hardware haben und kann dennoch bei der gleichen Installation bleiben.

Sodann habe ich überprüft, was der Server eigentlich macht, und entsprechend die Komponenten bei der neuen Installation via apt-get eingespielt. Für mich war das nicht mehr besonders viel, da der Server vor allem als Webserver dient: apache2, php5, mysql und einige Module derselben (SSL, curl, rewrite)

Hiernach ging es um die Frage der Daten. Wie bekomme ich nun alles vom einen auf den anderen Server, ohne mir dabei die Finger wund zu kopieren? Total einfach via SCP, insofern man Zugriff auf zwei SSH Server hat (was hier der Fall war). Dafür habe ich mich folgenden Tipps bedient:

MySQL-Transfer: “mysqldump –extended-insert –force –log-error=log.txt -uBENUTZER -pPASSWORT –all-databases | ssh -C BENUTZER@NEUERSERVER “mysql -uBENUTZER -pPASSWORT”

Datentransfer: “scp -rp DATEN NUTZER@SERVER:/VERZEICHNIS”

Einfach, nicht? Schon lag das gesamte /var/www sowie meine Home-Verzeichnisse samt MySQL-DB auf dem neuen Server. Was gab’s dann noch zu tun? SSL einrichten, zlib Compression in der php.ini steuern, .htaccess Datei anpassen, ownCloud testen, finito. Alles in allem hat das Übertragen der Daten via mysqldump und scp mir also vielfältige Arbeitsstunden erleichtert.

Jetzt geht es um’s Testen. Aber wie erreiche ich eigentlich den Server, wenn meine Domain die gleiche bleiben soll? Dafür ändere ich noch schnell die MX-Records auf die neue IP und flushe meinen Betriebssystem-Cache meines Produktivsystems, damit auch der neue Server erreichbar wird. Dafür gibt’s übrigens ein kleines Tool unter Ubuntu.

Übrigens: Das alles geschieht schon auf dem neuen Server, der alte ist bereits abgeschaltet. Vielleicht fällt mir ja nochmal etwas ein, was ich vergessen habe, wenn es den alten Server nicht mehr online gibt. Bis dahin sieht es sehr gut aus.

Vor einer ganzen Weile schon bin ich von Funambol auf ownCloud umgestiegen. Gründe dafür gibt es viele, der Hauptverdächtige war aber das Update- und Communityverhalten von Funambol – es existiert nicht. Außerdem war auch die Plugin-Situation für meine Exchange-Alternative Outlook minderwertig sowie eine Synchronisation mit Android abenteuerlich. Aus diesem Grund ging es zu ownCloud.

ownCloud selbst arbeitet dabei nicht als JAVA-, sondern bietet als Interface Webzugriff und fungiert als WebDAV-, CalDAV- und CardDAV-Server. Er ist ziemlich sicher, übersichtlich, komfortabel, funktional und vor allem SCHNELL. Zudem basiert er auf meinem vServer auf bereits eingerichteten Umgebungen und lässt sich leicht und sicher backupen sowie updaten.

Aber warum schreibe ich das hier? Weil ich bislang auch ownCloud über Thunderbird zugänglich gemacht habe. Nur ist das furchtbar – Synchronisation mit Kalendern und Kontakten funktioniert nur über Plugins, die selbst weder richtig gewartet werden noch korrekt funktionieren. Und das schlimmste: Der sowieso schon langsame Thunderbird geht bei einer einfachen Kalendersynchro in die Knie auf meinem i5; der Atom meines Netbooks wird unausstehlich.

Deshalb muss nun bei meinem KDE 4.9 endlich wieder KMail ran. Ich bin damals wegmigriert, weil mir Thunderbird auf allen Plattformen zur Verfügung steht, was bei KMail nur prinzipiell der Fall ist. Jedoch bin ich nun zufriedener denn je. Der Import funktioniert einfach: Über Extras -> Import-Assistent einfach alles auf Thunderbird migrieren und schon ist quasi alles wie gehabt. Die Kalender und das Adressbuch richtet man sich in Akonadi über diese Anleitung ein. Noch Fragen? Ich habe keine.

Übrigens dauert der Import bei großen Nachrichtenarchiven sehr lange – keine Sorge, der Import-Assistent arbeitet auch ohne direkte Rückmeldung. Nicht verzagen also, bei mir hat es eine gute Stunde gebraucht, weil ich aber auch Mails seit 2010 archiviere. Wichtig ist nur, dass ihr den Import auch entsprechend einschaltet – warum? Weil ich dazu erstmal einen Import-Ordner bestimmen müsst (das blaue Ordnersymbol bietet euch da die Auswahl) und danach auf Starten/Weiter klickt. Erst dann geht’s richtig los 😉

All posts tagged migration

Serverumzug

Von Thunderbird zu Kubuntu – Endlich natives PIM mit ownCloud und KDE