Wechsel von JiffyBox (Domainfactory) zu Hetzner Cloud

M

majestyk

Guest
Hi,

der virtuelle Server von Domainfactory (JiffyBox) wird in Kürze nicht mehr angeboten. Daher sind wir in Kürze gezwungen, mit unseren beiden Servern umzuziehen.
In Frage kommen Hetzner Cloud Server.
Frage: Ist es möglich, ein Jiffybox-Image auf einem Hetzner-Server einzuspielen? Wenn ja, wie?
Die JiffyBox bietet eine Exportfunktion als Raw-Image (tar.gz.) incl. Swap-Partitionen an.
Bei Hetzner scheint zum Import ein .iso Image erwartet zu werden (https://docs.hetzner.com/de/cloud/servers/faq#wie-kann-ich-ein-eigenes-iso-nutzen).
Kann/muss man das JiffyBox Image in ein .iso umwandeln? Wenn ja, wie?

Ist der Ansatz mit den Images überhaupt gangbar? Oder müssen die Server komplett neu aufgesetzt werden?
Wäre schön, wenn jemand sich dazu äußern könnte, wir sind mit dieser unerwarteten Herausforderung nämlich leicht überfordert.

Besten Dank!
 
Ich würde mal folgendes versuchen:

1.Export bei JiffyBox herunterladen
2.Hetzner Cloud Server ins Rescue System booten
3.Export-Image bereitstellen (bspw über einen HTTPS-Link), über den Cloud Server herunterladen und im selben Moment das ganze Image via "dd" auf die lokale Disk schreiben.
(4.1 ggf. weitere Anpassungen (Netzwerkconfig o.ä. ) vornehmen)
4. Cloud Server neu starten und hoffen.

Die Platte im Cloud Server muss natürlich entsprechend dimensioniert sein.
 
Der einzig saubere Weg:
- Nutzdaten sichern
- System beim neuen Anbieter neu aufsetzen
- Nutzerdaten wieder einspielen
- eventuell noch Anpassungen vornehmen (IP Adressen, etc.)
- glücklich sein:cool:
 
  • Like
Reactions: d3p
Hat denn jemand schon erfolgreich ein Image von der Jiffybox auf eine Hetzner-Cloud aufgespielt? Wenn ja, wäre eine Anleitung Schritt für Schritt sehr hilfreich. Stehen vor dem gleichen Problem :-(
 
nexus said:
Guckst du:
Click to expand...
- Nutzdaten sichern
- System beim neuen Anbieter neu aufsetzen
- Nutzerdaten wieder einspielen

...schon klar und sicher der sauberste Weg. Aber das kostet Zeit, damit Geld und ist nicht rentabel. Das Abschalten bei df ist einfach dreist. Deshalb die Idee mit dem Einspielen eines Backups. Wer hat es wo und wie erfolgreich wieder zum Laufen gebracht? Bitte mit Serverstandort Deutschland. Danke für eine Anleitung ;-)
 
Ingolf78 said:
Aber das kostet Zeit, damit Geld und ist nicht rentabel.
Click to expand...
Ob du nun die Daten aus einem Image oder aus einem Backup auf die neue Maschine schaufelst, macht vom Zeitaufwand her wohl eher keinen Unterschied. Einzig die 10-15 Minuten für das Aufsetzen des neuen Grundsystems würden als zeitlicher Mehraufwand zum Tragen kommen.
 
Hmm, z. B.
Bash: 
dd if=/dev/sda status=progress bs=10M conv=fsync | ssh user@hetznerip dd of=/dev/sda
Also probiert habe ich das nicht, wäre mir aber einen Versuch wert :unsure:
Da wäre es aber gut, wenn sich beide Systeme im Rescue-Modus befinden, damit es während der Aktion nicht zu Inkonsistenzen kommt. Bei Hetzner müssen dann die Netzwerkeinstellungen angepasst werden und mit etwas Glück war's das mit dem Umzug … ;)
 
Vielleicht noch komprimieren und dekomprimieren, damit es schneller geht? (parallel via pigz oder pixz)? und ggf. den leeren Platz mit Nullen vollschreiben?
 
Klar, dieser Einzeiler war natürlich nur ein Serviervorschlag, der sich noch verfeinern lässt. Aber geil wär's schon, wenn sich so 'ne Kiste von A nach Timbuktu damit umziehen lässt :LOL:

Hintergrund:
Ich habe kürzlich auf meinem 12 Jahre alten Homeserver ein Ubuntu 14.04 gegen ein aktuelles Bodhi-Linux getauscht, weil das noch auf dem uralten Atom-Board und mit 1 GB RAM installierbar war. Klar, das lief dann gemächlich, aber es war mal wieder ein aktuelles System.
Also hab ich der alten Kiste dann doch mal ein neues Board spendiert, und mehr RAM drauf gepackt. Eingeschaltet. Hochgefahren. Läuft. Ohne eine einzige Anpassung.

Einfach ausprobieren und schauen ob es klappt. Ein dd-Image kann man sich ja trotzdem noch in eine Storage-Box bei Hetzner schaufeln, um noch ein Backup von der jiffybox zu haben.
 
Das klingt nach Hoffnung. Hat es denn geklappt @syntaxys ? Wenn ja, mit welchen Verbesserungen zum Serviervorschlag bzw. Einzeiler, wenn ich mich Anfang März darauf stürze? Vielen Dank vorab ;-)
 
Habe sicherheitshalber eine Jiffybox-Kopie angelegt und konnte diese auf einen Hetzner Cloudserver schaufeln. Dazu per SSH auf den Hetzner-Cloud-Server mit:

Code: 
ssh User@JiffyBoxIP  "dd bs=4M if=/dev/xvda status=progress | gzip -1 -" | dd bs=4M of=/dev/sda

Lief alles erfolgreich durch. Leider hatte ich dann nur Zugriff bei Hetzner im Rescue-Modus. Auch kein Aufruf der Seite im Browser nach Nameserver-Änderung möglich.

Muss sicher noch irgendwie gemountet werden und/oder Netzwerkeinstellungen im Ubuntu 20.04? Hat jemand eine Idee? Danke!
 
Last edited:
Also ich hab das selbst noch nicht probiert, aber schön daß zumindest das Umschaufeln geklappt hat. Ich vermute mal falsche Einträge in der fstab und/oder in der Netzwerkkonfiguration, wahrscheinlich muss grub auch neu geschrieben werden.
Wenn Du Dir die Einstellungen von Hetzner nicht vorab gesichert hast, dann buche einfach einen zweiten Server mit Ubuntu 22.04 für ein paar Minuten dazu und guck's Dir dort ab. Die Dinger werden ja eh sekundenweise abgerechnet.

Die richtige UUID der boot-Partition für die fstab ermittelst Du mit blkid, die IP-Adresse(n) liefert Dir ja das Webinterface.
Grub kannst Du nach Anpassung der config dann so neu schreiben:
  1. Im Rescue-Modus des Servers die Root-Partion (vermutl. /dev/sda1) unter /mnt einhängen.
  2. Die boot-Partition unter /mnt/boot einhängen.
  3. Die EFI-Partition unter /mnt/boot/efi einhängen.
    Bei mir sieht die Partitionierung eines Cloud-Servers mit Debian so aus:
    Device Start End Sectors Size Type
    /dev/sda1 503808 80003038 79499231 37.9G Linux filesystem
    /dev/sda14 2048 4095 2048 1M BIOS boot
    /dev/sda15 4096 503807 499712 244M EFI System
  4. Nun Schreibrechte vergeben und ins System chrooten:
    mount -o bind /dev /mnt/dev
    mount --rbind /sys /mnt/sys
    mount -t proc /proc /mnt/proc
    chroot /mnt /bin/bash
  5. Nun kann grub neu installiert werden – mit update-grub und folgendem grub-install sollte der Reboot ins System wieder möglich sein, wenn sonst alles passt. Wenn der Kernel nicht gefunden werden kann, weil die ID der Partition nicht bekannt ist, dann liegt der Fehler in der fstab (die also vor dem Reboot mit der Ausgabe von blkid abgleichen).
Ansonsten den Bootvorgang einfach über eine Konsole beobachten, aber die ist standardmäßig schon dabei (also zumindest bei den Cloud-Servern). Projekt > Server > rechts oben im Menü beim Ein-/Ausschalter des Hosts kannst Du die Konsole im neuen Fenster öffnen und schauen, was zickt …
 
syntaxys said:
Also ich hab das selbst noch nicht probiert, aber schön daß zumindest das Umschaufeln geklappt hat. Ich vermute mal falsche Einträge in der fstab und/oder in der Netzwerkkonfiguration, wahrscheinlich muss grub auch neu geschrieben werden.
Wenn Du Dir die Einstellungen von Hetzner nicht vorab gesichert hast, dann buche einfach einen zweiten Server mit Ubuntu 22.04 für ein paar Minuten dazu und guck's Dir dort ab. Die Dinger werden ja eh sekundenweise abgerechnet.

Die richtige UUID der boot-Partition für die fstab ermittelst Du mit blkid, die IP-Adresse(n) liefert Dir ja das Webinterface.
Grub kannst Du nach Anpassung der config dann so neu schreiben:
  1. Im Rescue-Modus des Servers die Root-Partion (vermutl. /dev/sda1) unter /mnt einhängen.
  2. Die boot-Partition unter /mnt/boot einhängen.
  3. Die EFI-Partition unter /mnt/boot/efi einhängen.
    Bei mir sieht die Partitionierung eines Cloud-Servers mit Debian so aus:
    Device Start End Sectors Size Type
    /dev/sda1 503808 80003038 79499231 37.9G Linux filesystem
    /dev/sda14 2048 4095 2048 1M BIOS boot
    /dev/sda15 4096 503807 499712 244M EFI System
  4. Nun Schreibrechte vergeben und ins System chrooten:
    mount -o bind /dev /mnt/dev
    mount --rbind /sys /mnt/sys
    mount -t proc /proc /mnt/proc
    chroot /mnt /bin/bash
  5. Nun kann grub neu installiert werden – mit update-grub und folgendem grub-install sollte der Reboot ins System wieder möglich sein, wenn sonst alles passt. Wenn der Kernel nicht gefunden werden kann, weil die ID der Partition nicht bekannt ist, dann liegt der Fehler in der fstab (die also vor dem Reboot mit der Ausgabe von blkid abgleichen).
Ansonsten den Bootvorgang einfach über eine Konsole beobachten, aber die ist standardmäßig schon dabei (also zumindest bei den Cloud-Servern). Projekt > Server > rechts oben im Menü beim Ein-/Ausschalter des Hosts kannst Du die Konsole im neuen Fenster öffnen und schauen, was zickt …
Click to expand...
Danke für die Anleitung, da kämpf ich mich mal durch. Habe grad noch den Code zum Schaufeln geändert. Hole mir bei Hetzner per SSH die Daten von der JiffiBox-Kopie. Dauert nur wenige Minuten bei 50 GB.
 
Prüfe erst mal die Netzwerkeinstellungen vom Rescue-System aus, ich bin mir ziemlich sicher, daß es nur daran liegt. Alle Geräte in diesen Cloud-Servern sind ja virtuelle Standardgeräte, die in jedem Host-System bereitgestellt werden. Das ist eine CPU, RAM, Speicherplatz und Netzwerkkarte, da sind keine speziellen Treiber nötig. Nur für die Netzanbindung sind die Einstellungen bei Hetzner ganz sicher anders, als bei der jiffybox.
Normalerweise sollten sich die Partitions-IDs bei einer dd-Kopie nicht ändern, das würde ich angehen, wenn's vom Netzwerk her passt.

Die Doku bei Hetzner liefert Dir alles für die Konfiguration mit netplan, als auch für ifupdown:
Hetzner Cloud Netzwerk Konfiguration
 
Na da schau ich morgen mal. Hab schon ein paar Stunden heute vergeigt. Aber die Konsole zeigt mir an, dass er schon mal nicht von Festplatte bootet, sondern letztendlich in der CD-ROM hängt. Das ist alles Neuland für mich. Ein frisches System bauen liegt mir besser. Aber da hängt zuviel Rattenschwanz dran. Will es weiter versuchen...so ein Umzug sollte doch irgendwie machbar sein.

Die /etc/fstab ist leer. Die Ausgabe blkid liefert nur /dev/loop0: UUID="c9a7c467-ddfs....." BLOCK_SIZE="4096" TYPE="ext2". Ansonsten habe ich nach Abfrage lsblk nur meine bespielte sda, die loop0 und sdr. :-(
 
Ingolf78 said:
Hab schon ein paar Stunden heute vergeigt ... Will es weiter versuchen
Click to expand...
Warum in aller Welt 'verschwendet' man seine Zeit, anstatt (in einem Bruchteil dieser Zeit) die neue Maschine neu aufzusetzen und ein aktuelles Backup einzuspielen...?
Dieses Vorgehen erschließt sich mir einfach nicht...:rolleyes:
 
Nun, daß der Gast beim regulären Bootvorgang im CD-ROM hängen bleibt, erschliesst sich mir nicht. Also ich würde das Problem so lösen:
  1. Den vServer bei Hetzner frisch mit Ubuntu neu installieren, das dauert wenige Minuten.
  2. In den frischen Cloud-Server einloggen und ein paar Daten zur jiffybox-Kopie rüberschieben. Ein bequemes Werkzeug auf der CLI ist der Midnight Commander, falls Du den noch nicht kennst: apt-get install mc
  3. Du brauchst auf der jiffybox-Kopie zumindest die /etc/fstab und – ich gehe mal davon aus, daß die jiffybox auch per netplan konfiguriert ist – die Daten unter /etc/netplan. Falls die /etc/network/interfaces nicht leer ist, dann diesen Ordner auch noch.
    Zu Sicherheit kopierst Du Dir noch die /etc/default/grub und den Ordner /boot/grub zur jiffybox-Kopie rüber. Sonst fällt mir grad nichts ein, was Du dort brauchen müsstest.
    EDIT: Die Daten jedoch dort nicht überschreiben, sondern irgendwo als Kopie ablegen. Und alles, was Du in der jiffybox änderst, vorab als .bak kopieren.
  4. Den Hetzner-Server bootest Du dann in den Rescue-Modus. Auch dort kannst Du den mc nachinstallieren, falls er nicht schon vorhanden ist.
  5. In der jiffybox-Kopie übernimmst Du die Konfiguration von Hetzner an den entsprechenden Stellen.
  6. Jetzt hängt's davon ab, wie der Ordner /boot auf der jiffybox konfiguriert ist. Wenn das wie bei Hetzner auch eine eigene Partition ist, dann muss die extra dupliziert werden:
    ssh User@JiffyBoxIP "dd bs=4M if=/dev/xvdaNummer-der-Bootpartition status=progress | gzip -1 -" | dd bs=4M of=/dev/sdaNummer-der-Bootpartition
    Die Ausgabe der Partitionsnummern bekommst Du mit fdisk -l
    Wenn /boot auf der jiffybox keine eigene Partition ist, dann dupliziere gleich die gesamte Root-Partion zu Hetzner:
    ssh User@JiffyBoxIP "dd bs=4M if=/dev/xvdaNummer-der-Rootpartition status=progress | gzip -1 -" | dd bs=4M of=/dev/sdaNummer-der-Rootpartition.
  7. Bei Hetzner mountest Du dessen Rootpartition (vermutlich /dev/sda1) unter /mnt und hast dort nun die Installation der jiffybox-Kopie.
  8. War auf der jiffybox /boot keine eigene Partition? Dann ist folgendes nötig:
    Mit mv /mnt/boot /mnt/boot.jiffybox && mkdir /mnt/boot eine Kopie behalten.
    Die Hetzner-Bootpartition unter /mnt/boot (siehe Ausgabe von fdisk für /dev/sdaXY) einhängen und alle Daten dort in einen Ordner als Backup verschieben:
    mkdir /mnt/boot.hetzner && mv -R /mnt/boot/* /mnt/boot.hetzner/
    Nun die Daten aus /mnt/boot.jiffybox nach /mnt/boot kopieren, damit hast Du nun den richtigen Kernel der jiffybox in der Bootpartition.

    War auf der jiffybox /boot eine eigene Partition? Dann hast Du die ja vorhin schon extra kopiert und es geht so weiter:
  9. Die boot-Partition (siehe Ausgabe von fdisk) unter /mnt/boot einhängen.
  10. Die EFI-Partition (siehe Ausgabe von fdisk) unter /mnt/boot/efi einhängen.
  11. Nun Schreibrechte vergeben und ins System chrooten:
    mount -o bind /dev /mnt/dev
    mount --rbind /sys /mnt/sys
    mount -t proc /proc /mnt/proc
    chroot /mnt /bin/bash
  12. Nun kann grub neu installiert werden – mit update-grub und folgendem grub-install sollte danach der Reboot ins System wieder möglich sein, wenn sonst alles passt.
  13. Wichtig – vor dem Reboot prüfen:
    Sowohl in der /boot/grub/grub.cfg als auch in der /etc/fstab sollten alle "UUID=xxx-yyy..."-Werte die richtigen IDs von Hetzner enthalten, die Ausgabe von blkid hilft Dir da weiter. Die Netzwerk-Konfiguration muss stimmen!
    Lass beim Booten die Konsole offen, so daß Du siehst was passiert.
Zum weiteren Verständnis:
Der Bootloader ist in /dev/sda installiert und sucht nach dem Ubuntu 22 -Kernel in der Partition mit der ID "xxx-yyy-…" von der Hetzner-Installation. Daher muss der neu installiert werden und vorab müssen die Parameter stimmen, damit der jiffybox-Kernel gefunden wird.

@nexus: Eine Neuinstallation von Ubuntu 22 wäre sicher von Vorteil, ist aber auch aufwändiger. Diese Methode mit der Direktkopie ist eigentlich in einer halben Stunde vom Tisch. Das Problem sind einfach nur die unterschiedlichen Einstellungen und hier muss man wissen, wo man schrauben muss. Dann geht das recht schnell.

Ich hab das jetzt im Blindflug erklärt, aber genau so habe ich kürzlich (mit Punkt 7-13) ein ext4-Dateisystem durch btrfs mit neuen Partitions-IDs unter einer Ubuntu-Installation ersetzt, weil ich zu faul war, eine neue Installation aufzusetzen. Hat funktioniert.
Ich hab selbst Cloud-Server bei Hetzner, aber die laufen dort nicht mit Ubuntu. Ich weiß daher nicht, inwieweit die Konfiguration eventuell abweicht.
 
Last edited:
You must log in or register to reply here.
Back
Top