ja klar, das sollte funktionieren. Musst dann noch ins Rettungssystem booten, die root Partition mounten und die IPs anpassen.
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;
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.
Wenn du beide Systeme parallel in Betrieb hast sollte eine Kopie der Disk mittels dd über ssh im Rettungssystem funktionieren.
Quelldiskpartitionen davor ggf. verkleinern.
https://unix.stackexchange.com/questions/503700/how-to-dd-a-local-disk-into-a-remote-disk
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.
warum immer das herumgehampel mit snapshots? rsync (im recovery) ist der goldene weg imho.
mkswap und lvm oder eine notwendige uefi partition darf sich jeder selbst dazubasteln.
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).
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:
Exclude-List:
/boot
/dev
/tmp
/sys
/proc
/run
/mnt
/etc/fstab
/etc/mtab
/etc/mdadm
/etc/netplan
/lib/modules
/etc/modules
/etc/lilo.conf
/lost+foundGibt es dabei sonst noch was zu beachten?
aRaphael :
EDIT: Ich sehe gerade, dass das Thema "chroot"/"Container" bereits hier adressiert wurde, allerdings in leicht anderem Kontext.
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. 
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
