Views: 1203

Auch wenn ich allgemein recht zufrieden mit den Produkten von domainFACTORY bin, gibt es doch Dinge, die nicht ganz ideal laufen. Weil die Firmenstruktur sich geändert hat, mussten wir die Kundendaten bei unserem Hoster ändern lassen. Ändern allerdings geht leider nicht, es muss ein neues Konto eröffnet werden mit den neuen Daten. Dann muss vom bisherigen Konto eine Abtretungserklärung erfolgen, sodass alles auf das neue Konto umgeschrieben werden kann (Domains, Webspace, Managed Server…). Leider funktioniert das für JiffyBoxen nicht (und da auch etwas Gemaule von mir: das wurde nicht mitgeteilt…).

Bei JiffyBoxen muss wieder auch ein neues Konto gemacht werden, und die virtuellen Server manuell umgezogen werden. DF bietet auch einen Service an, das für einen zu machen, aber aufgrund von zeitlichen Problemen (erwartete Zeit von deren Seite aus wäre eine Woche) auch mit den Feiertagen, war das für uns nicht sinnvoll.

Innerhalb eines Kontos können Sachen simpel gemacht werden, z.B. eine neue JiffyBox erzeugen, basierend auf einem Backup einer bestehenden. Leider geht das über Kontogrenzen (natürlich) nicht. Der Helpdesk verwies uns auf einen Eintrag im Wiki (Einspielen eines heruntergeladenen Backups), der nicht ganz falsch aber auch nicht wirklich befriedigend war. Laut dem läd man sich einen Backup auf den lokalen Rechner runter, entpackt den dort und schiebt dann ein entpacktes Plattenimage auf die neue JiffyBox (Plattenimages entpackt fangen bei 50 GB an). Irgendwie muss man dann dieses Plattenimage auf einer Partition (mit Filesystem) zwischen lagern, und dann auf eine andere Partition mit dd kopieren. Das bedeutet dann schonmal mind. 50GB an Transfervolumen für das neue Konto, weiterhin nimmt ein Plattenimage auf einer Partition mit Filesystem logischerweise mehr Platz in Anspruch, als roh auf der Partition.

Ein erster Versuch meinerseits, es mit dieser Anleitung zu machen, scheiterte an vielen Stellen. Die verfügbaren Rescuesysteme funktionierten meist nicht (nur die Fedora 17, ich habe aber nicht alle ausprobiert, Debian Squeeze wollte nicht starten), als das Image dann auf die neue Partition kopiert war, startete die neue Box dennoch nicht, irgendwie konnte der Kernel keine Platte finden. Letztlich fand ich dann doch eine Methode, die funktioniert und den Datentransfer zumindest minimiert, und keine Daten über den lokalen Rechner kopiert werden mussten.

Wenn man einen Backup herunter laden möchte, erhält man in einer email einen Link zu einem tar-gz Archiv, das normalerweise 2 Plattenimages enthält, die Datenplatte und die Swap-Partition. Als Empfänger habe ich eine neue JiffyBox eingerichtet, die mehr Plattenplatz hat, als die größte Maschine, die zu verschieben ist. Mit

wget <URL zu Archivdatei>

wird das Archiv auf diese Box geladen und mit

tar xvzfS <Archivdatei>

dann entpackt. Damit liegen die beiden Partitionen vor, sowie eine README-Datei. Die Swap-Partition sowie das README können getrost gelöscht werden. Die zu kopierende Partition liegt nun entpackt vor (im kleinsten Fall 50GB). Dann wird die neue JiffyBox, die das Ziel der Verschiebeaktion ist, eingerichtet. Zunächst mit doppelt soviel Plattenplatz, wie im Betrieb benötigt. Also volle Installation. Das System installiert dann erstmal alles auf eine Partition, die die Maximalgröße hat (z.B. 100 GB). Dann verkleinert man die Platte auf eine Größe, sodass genug Platz für eine Partition bleibt, die die bisher bestehende Maschine hatte. Die Information steht unter „Profile und Festplatten“, wenn man bei der entsprechenden ‚Platte‘ auf „Ändern“ geht

:

Genauso („Profile und Festplatten“ -> „Ändern“ -> „Größe ändern“) kann dann von der neuen Box die Partition angepasst werden (Box muss gestoppt sein). Der restliche Platz wird mit einer neuen Partition gefüllt, die exakt die Größe der Partition der zu verschiebenden Box hat. Im Profil der Box trägt man noch die neue Partition mit ein, sodass die gesamte Liste folgendes enthält: /dev/xvda – die verkleinert system-partition, /dev/xvdb – Swap, /dev/xvdc – die Partition, die exakt die Größe der Original-Box hat. Aus einem mir nicht ganz verständlichen Grund funktionierte alles nur, wenn die Swap-Partition immer /dev/xvdb war. Diese neue Box wird wieder gestartet.

Auf der temporären Box läuft währenddessen gzip, um die rohe Partition so klein zu machen, dass sie auf die verkleinerte Systempartition der Ziel-Box passt:

gzip <partitions image>

Das dauert natürlich alles. Der Zwischenschritt kann aber auch übergangen werden, wenn man für die Zielbox mehr als den doppelten Platz der original-Box bucht.
Nach dem Packen muss das Image auf die Zielbox kopiert werden, da bietet sich scp an, und vor allem: die interne IP-adresse nehmen! Dann wird der Traffic nicht gezählt.

scp <partitions image>.gz root@10.x.x.x:

Auf der Zielbox wird das Image schließlich auf die noch völlig unbenutzte Partition geschrieben:

gunzip -C <partitions image>.gz|dd of=/dev/xvdc

Das dauert so seine Zeit, 50 GB zu entpacken und auf eine Platt zu schreiben ist halt ein Aufwand. Wenn das geendet hat kann die Box herunter gefahren werden, und – erstmal zum Testen, ob alles geklappt hat – ein neues Profil erstellt werden, bei dem die neue Partition als xvda und die Swap-Partition als xvdb  gemountet wird. Der richtige Kernel muss noch ausgewählt werden, und: Starten!

Wenn jetzt alles gut gegangen ist, startet die Maschine in den Zustand, den das Original beim letzten Backup hatte, und die Operation ist gelungen. Um den Tarif zu wählen, den man vorher hatte (schließlich haben wir aus Platzgründen extra einen höheren Tarif nehmen müssen), wird die nun unnötige Partition gelöscht, und ein Tarifwechsel durchgeführt.

Und: geschafft! Für die Prozedur sind ein paar Stunden einzuplanen…

Warum das ganze, anstatt – wie im Wiki beschrieben – nur im Recover-system zu arbeiten? 1. Das Fedora 17 Recovery-system enthält kein scp. 2. Aus einem mir unerfindlichen Grund waren andernfalls die kopierten Systeme nicht boot-fähig. Ich habe auch keine Ahnung, warum das so war.

Warum mit mehreren Maschinen arbeiten, wenn eigentlich eine gereicht hätte? Parallelisierung. Während der DL auf der temporären Maschine lief, habe ich die Zielmaschine vorbereitet. Lässt mehr Flexibilität auch bei der Plattenverwaltung zu, und: kost (fast) nix. Sobald die temporäre Maschine gelöscht ist, wird sie nicht mehr berechnet, und selbst wenn man langsam ist, sind höchstens vielleicht 2 Euro. Zusätzlich musste ich mich nicht so darauf konzentrieren, was ich wo gespeichert hatte.

Warum der Umweg über’s Packen? Weil ich zunächst nicht nach gedacht hatte. Ich habe die Backups auf eine Maschine geholt, die auf dem bestehenden Konto noch war (anders als oben beschrieben). Wenn dann ein entpacktes Image von dem bestehenden auf das neue Konto kopiert wird, wird für beide 50 GB Transfer berechnet (bei 1000 GB frei wird das oft egal sein, aber nicht immer), ein gepacktes Image kann aber durchaus auf unter 2 GB kommen. Außerdem: so war es einfach, wie ich es gemacht habe, und das hat funktioniert.