Serverumzug per Snapshot möglich?

  • Serverumzug per Snapshot möglich?


    Ich möchte demnächst von einem "VPS 6000 G9 12M Root-Server" auf einen "RS 1000 G9.5" umziehen, ein Downgrade ist wohl leider nicht möglich.

    Dazu eine (Anfänger)Frage: Ist es möglich einen Snapshot zu erstellen und den auf den neuen Server aufzuspielen?

    Also quasi ein Umzug mit ein paar Klicks? Platz ist mehr als genug vorhanden, das komplette System hat gerade mal 50gb.

    Gruß Franz

  • ein Hinweis, wenn die Platte bzw. der in Summe belegte Teil der Platte mit Partitionen des Quell-Servers größer ist als die Platte vom Ziel-Server, geht es nicht;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Nein, das geht in deinem Fall nicht, weil die Qelldisk größer ist als die Zieldisk.

    Da hilft es auch nicht, dass nur ein Teil davon belegt ist. Die Partition voher zu verkleinern funktioniert leider auch nicht. (Hatte das selbst schon versucht und bekam die Absage: "Das gewählte Installationsmedium ist zu groß und kann aus diesem Grund nicht eingespielt werden")

    Evtl. kann man aber den snapshot exportieren, herunterladen und mit qemu das image entsprechend bearbeiten und wieder hochladen. Nie ausprobiert.

  • Evtl. kann man aber den snapshot exportieren, herunterladen und mit qemu das image entsprechend bearbeiten und wieder hochladen.

    Das ist eine Möglichkeit (und wahrscheinlich die einfachste, wenngleich die Daten hier zunächst auf ein Drittsystem transferiert werden müssen); sofern ein Backup existiert, könnte man auch das Dateisystem der Quell-KVM-Instanz verkleinern und die Partitionsgröße anpassen (siehe beispielsweise hier); danach beide KVM-Instanzen über das Rettungssystem booten und die nunmehr nicht mehr in Benutzung befindliche Quellpartition via "dd" und "ssh" sektorweise auf die Zielpartition übertragen. Danach kann das Dateisystem der Ziel-KVM-Instanz wieder vergrößert werden (das sollte direkt aus dem Rettungssystem heraus funktionieren, sofern die entsprechenden Hilfsprogramme für das verwendete Dateisystem vorhanden sind oder eingespielt werden können).

    Bei neueren Dateisystemen wie Btrfs oder ZFS kann man (die dateisystemspezifischen, nicht mit der Netcup-SCP-Funktionalität zu verwechselnden) Snapshots direkt übertragen; beim Einsatz von LVM sollte man hier die zusätzliche logische Ebene bei der Verkleinerung/Vergrößerung beachten.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Edited once, last by m_ueberall ().

  • warum immer das herumgehampel mit snapshots? rsync (im recovery) ist der goldene weg imho.


    1. zielserver ins recovery booten
    2. partitionen erstellen (gdisk) und filesysteme initialisieren (mkfs.ext4)
    3. filesysteme einhängen
      1. mkdir /target
      2. mount /dev/sda2 /target
      3. mkdir /target/boot
      4. mount /dev/sda1 /target/boot
    4. erster sync wenn der quellserver noch normal läuft ionice -c idle rsync -axHAXvP --numeric-ids --delete / root@<zielserver>:/target/
    5. quellserver ins recovery booten
    6. filesysteme wie am zielserver einhängen
      1. mkdir /source
      2. mount /dev/sda2 /source
      3. mount /dev/sda1 /source/boot
    7. finaler sync rsync -axHAXvP --numeric-ids --delete /source/ root@<zielserver>:/target/
    8. ins chroot wechseln (hoffentlich gibts das prepare auch im netcup recovery)
      1. chroot-prepare /target
      2. chroot /target
    9. grub installieren
      1. grub-mkdevicemap -n
      2. grub-install /dev/sda
    10. in der /etc/fstab noch die uuids aus blkid anpassen
    11. je nach bedarf sollte man noch /etc/udev/rules.d/70-persistent-net.rules und /etc/mdadm/mdadm.conf anpassen
    12. es empfiehlt sich auch jetzt schon die IP adresse anzupassen, die stellen findet man mit fgrep -sir "<IP>" /
    13. boot-fähig machen
      1. update-initramfs -u -k all
      2. update-grub2
    14. reboot
    15. in der console aufgeregt zusehen wie der zielserver erfolgreich bootet

    mkswap und lvm oder eine notwendige uefi partition darf sich jeder selbst dazubasteln.

    Edited once, last by hoedlmoser: finaler sync braucht kein nice, hinweis bzgl lvm, mkswap und uefi ().

    Like 5 Thanks 1 Happy Duck 1
  • Alle hier angebotenen Wege nutzen Linux, ich verwende Windows Server, welches auch auf dem neuen Server zum Einsatz kommt.
    Aber ist nicht so schlimm, soviel Arbeit ist das nicht, hätte sie mir bloß gerne gespart.

  • ich verwende Windows Server, welches auch auf dem neuen Server zum Einsatz kommt.

    Sollte man eigentlich auch im ersten Beitrag dazu schreiben. Niemand hier hat eine Glaskugel und Windows Server ist auf vServern eher unterrepräsentiert.

  • warum immer das herumgehampel mit snapshots? rsync (im recovery) ist der goldene weg imho.

    (...)

    Wenn ich kurz reinspringen darf: Danke für den Post. Das hört sich ja nicht überkomplex an und schmälert meine Sorgen bei einem Umstieg auf einen RS 1000 G11 mit Local Block Storage.


    Kannst du (oder andere) erfahrene "Serverumzieher" in etwa sagen, wie lange der Datentransfer innerhalb des NC-Netzes ungefähr dauern wird? Und mit welcher Downtime ich in etwa rechnen muss? (Vorausgesetzt es klappt relativ problemlos?) Quelle ist ein RS 1000 SAS G8 (also mit herkömlicher HDD, keine SSD) mit einem Datenvolumen von knapp unter 200GB?

  • Kannst du (oder andere) erfahrene "Serverumzieher" in etwa sagen, wie lange der Datentransfer innerhalb des NC-Netzes ungefähr dauern wird? Und mit welcher Downtime ich in etwa rechnen muss? (Vorausgesetzt es klappt relativ problemlos?) Quelle ist ein RS 1000 SAS G8 (also mit herkömlicher HDD, keine SSD) mit einem Datenvolumen von knapp unter 200GB?

    Ein RS 1000 SAS G8 hat eine 1GBit/s-Schnittstelle, allerdings kann diese Bandbreite bei Verwendung einer HDD nicht im Entferntesten ausgelastet werden. Wie schnell die Übertragung funktioniert, hängt nicht zuletzt davon ab, ob/wie die Daten komprimiert werden (können) und welche Verschlüsselung zum Einsatz kommt (in der Regel würde man rsync über ssh tunneln).

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Edited once, last by m_ueberall ().

  • Danke für die Antwort.


    Ja, den Transfer mache ich normal via rsync/ssh (wie eben im zitierten Post beschrieben)


    Aber mir fällt gerade ein, eigentlich ist es relativ wurst... Es lässt sich ja so einrichten, dass die Restlaufzeit vom G8 sich ausreichend mit der Bereitstellung vom G11 überlappen wird (sprich: ich lange genug parallel auf beide Zugriff habe). Dann ist das erstmal nicht so wild, wie lange sich der initialie Datentransfer zieht. Nach dem initialien Transfer sind's ja nur noch Änderungen, wenn der Schalter mehr oder weniger final umgelegt wird.


    (Also sorry, ich habe ein potentielles Problem gesehen, wo es praktisch gar keines gibt :) )

  • Ich hänge mich mal an diesen Thread dran, mit einer Frage:


    Ich habe zwei "identische" Server. (Ubuntu 22.04)

    Der eine ist produktiv und dort sind alle nötigen Pakete und Anwendiungen installiert. Auf dem anderen nur das Basissystem, ansonsten aber identisch zum anderen Server. (Auf beiden kein lvm)

    Nun will ich ab und an das Ganze mal rüberklonen. Übertragen per snapshot geht nicht, da Zielserver kleiner. Das komplette Programm, wie von hoedlmoser oben beschrieben, ist ja hier wohl nicht nötig, Das Zielsystem läuft ja und ist passend.


    Ich dachte an ein einfaches rsync der Verzeichnisse um Pakete, Konfiguration, Anwendungen rüberzuschieben.

    Nun die Frage(n)

    Wird das so funktionieren?

    Oder soll ich mir die Zeit sparen, das zu testen, weil es sowieso in die Hose gehen wird? ^^


    Welche Verzeichnisse sollte ich dabei ausschließen, weil sie spezifisch für den Zielserver sind?

    Was mir so einfällt:


    Gibt es dabei sonst noch was zu beachten?

  • aRaphael :

    • Warum ist /boot "spezifisch für den Zielserver", wenn man doch alle installierten Kernel-Module usw. laut Liste via rsync übertragen würde, die beim nächsten Update via dkms o. ä. von update-initramfs "angezogen" würden?
    • Was ist mit der IP-Adresse und dem Hostnamen, die sicherlich irgendwo hinterlegt sind und korrespondierende Vorkommen auf dem Zielserver überschreiben?
    • Ist vorgesehen, vor dem Klonvorgang alle laufenden Dienste, welche ihren Status auf dem Dateisystem hinterlegen, temporär herunterzufahren? Ansonsten ist natürlich mit Problemen/Inkonsistenzen zu rechnen – unabhängig vom nächsten Punkt. (Ob man damit leben kann, sollte vorher analysiert werden).
    • Ist die zugrundeliegende Überlegung, dass obiges Vorgehen eine schnelle(re) Rücksetzung/Duplizierung/Ersetzung des Quellhosts an anderer Stelle ermöglichen soll? Wenn das auf Dateibasis via rsync geschehen soll, würde ich auf dem Zielserver eher ein vollständiges chroot (initialisiert ggf. mit debootstrap) ins Auge fassen (besser noch einen LXD-Container), wenn die Nutzung von ZFS/Btrfs keine Option ist.

    EDIT: Ich sehe gerade, dass das Thema "chroot"/"Container" bereits hier adressiert wurde, allerdings in leicht anderem Kontext.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Edited 5 times, last by m_ueberall ().

  • Was ist mit der IP-Adresse und dem Hostnamen, die sicherlich irgendwo hinterlegt sind und korrespondierende Vorkommen auf dem Zielserver überschreiben?

    Außer in /etc/netplan dürfte sowas eigentlich nur noch in /etc/hosts und /etc/hostname vorhanden sein und möglicherweise in /etc/postfix

    Das waren zumindest in der Vergangenheit, die einzigen Orte, an denen ich nach Umzug per snapshot Änderungen vornehmen musste. Der hostname kann aber sowieso gleich bleiben.

    Ist vorgesehen, vor dem Klonvorgang alle laufenden Dienste, welche ihren Status auf dem Dateisystem hinterlegen, temporär herunterzufahren?

    Ja. Das Ganze soll im Rettungssystem passieren.

    Ist die zugrundeliegende Überlegung, dass obiges Vorgehen eine schnelle(re) Rücksetzung/Duplizierung/Ersetzung des Quellhosts an anderer Stelle ermöglichen soll?

    Ja. Zum einen das und zum anderen um ein identisches Testsystem zu Verfügung zu haben, um kritische Änderungen zunächst dort testen zu können.

    Warum ist /boot "spezifisch für den Zielserver", wenn man doch alle installierten Kernel-Module usw. laut Liste via rsync übertragen würde, die beim nächsten Update via dkms o. ä. von update-initramfs "angezogen" würden?

    Ist mir ehrlich gesagt ein wenig unklar, was du hiermit meinst. :/

  • OK. Ich habe das jetzt einfach mal so ausprobiert, mit obiger Exclude-Liste von einem 640GB-RS auf 160GB-VPS

    rsync läuft schnell und glatt durch, geklonter Server bootet einwandfrei und ist erreichbar. Keine Auffälligkeiten im syslog beim booten.

    Auf den ersten Blick scheint das reibungslos geklappt zu haben. :)


    Ich muss das jetzt natürlich noch intensiv durchtesten, aber falls keine großen Überraschungen mehr auftauchen, habe ich endlich mal eine Methode um auf einen kleineren Server zu klonen. :)


    EDIT:

    Auch die Webanwendungen scheinen alle zu laufen.

    Es ist allerdings keine gute Idee /var/log vom sync auszunehmen. :S Dann startet Apache2 nicht mehr.

    Das habe ich dann nachholen müssen.

  • Hier ein Rsync Beispiel, Quelle oder Ziel kann dann ein ssh Ziel sein:

    https://wiki.archlinux.org/title/Rsync#Full_system_backup


    Und hier noch ein paar Anmerkungen zu den Nacharbeiten:

    https://wiki.archlinux.org/title/System_backup

    plus "meine" Liste:


    sudoedit /etc/fstab

    sudoedit /etc/hostname

    sudoedit /etc/hosts

    sudo rm /etc/machine-id && sudo systemd-machine-id-setup

    reinstall # kernel + bootloader + initramfs

    # network

    # ssh server config