Serverumzug per Snapshot möglich?

Guten Morgen,

interessieren würde mich die Funktion/Wichtigkeit des Ordners nach wie vor, aber ich habe einfach nochmal frisch angefangen und bei rsync auch diesen Ordner excludiert.

DNS Änderungen sind auch durch. Froxlor brauchte noch eine Anpassung in der DB direkt, bei resolved war was verhakelt (in der 50-cloud-init.cfg waren, auch nach einer frischen Debian-minimal-Image Installation) keine DNS eingetragen, daher war die leer). Ansonsten schaut's auch hier so aus als hätte die Migration gut funktioniert.

Zitat von swh

ich nutze gerade die rsync-methode mit etwas angepasster exclude-Liste. Ich bin jetzt über /var/lib/cloud/instances/<quellserverhost>-<noch-mehr-zeichen>/* gestolpert.

Weiß jemand:

* Für was ist der gut?

* Hätte ich das besser auch excludet?

* Ist der Ordner egal?

Den Ordner hatte ich noch nie bemerkt. (Wie bist du denn auf den gestoßen?)

Insofern habe ich ihn auch nie exkludiert.

Da meine Spiegelungen aber alle reibungslos laufen, scheint er mir keine kritische Sache zu sein.

Ich vermute, der wurde bei der Installation des ursprünglichen Images angelegt.

Zitat von swh

… /var/lib/cloud/instances/ …

https://cloudinit.readthedocs.io/en/21.1/topics/faq.html

Olivetti Danke. (Meine eigenen Suchen waren nicht so ergiebig)

aRaphael Grep nach der alten IP im var-Ordner hat die obj.pkl im genannten Ordner mit ausgespuckt

Ich nutze ja (wie weiter oben beschrieben) rsync für das Serverkloning

Funktioniert meistens, aber leider nicht immer einwandfrei.

Deshalb würde ich das Cloning per dd über ssh nochmal antesten.

Dazu zwei Fragen:
1) Funktioniert das auch, wenn das Zielsystem kleiner ist? z.B. von RS 4000 auf RS 2000? Worauf muss ich da achten?

2) Welche Anpassungen (neben Netzwerk) sind denn danach noch zu tätigen? Insbesondere um das bootfähig zu machen. (Gerne auch detailliert )

Hübscher Link. Hat leider mit meiner Frage (Cloning mit dd) nicht viel zu tun.

Zitat von aRaphael

Hübscher Link. Hat leider mit meiner Frage (Cloning mit dd) nicht viel zu tun.

Hat sich auf die erste Frage bezogen.

Dass ich snapshots beim Umzug auf ein gleich großes oder größeres System nutzen kann, ist mir klar. Mache ich auch auch (gelegentlich)

Ich suche eine zuverlässige Methode um auf eine kleinere disk umzuziehen

Zitat von aRaphael

Dazu zwei Fragen:

1) Funktioniert das auch, wenn das Zielsystem kleiner ist? z.B. von RS 4000 auf RS 2000? Worauf muss ich da achten?

2) Welche Anpassungen (neben Netzwerk) sind denn danach noch zu tätigen? Insbesondere um das bootfähig zu machen. (Gerne auch detailliert )

1. nein, da das komplette Datensystem übertragen wird

2. Eventuell musst du Grub (wenn vorhanden) neu installieren (bin ich mir aber nicht 100%) sicher.

Zitat von Hille

1. nein, da das komplette Datensystem übertragen wird

OK. Danke.

Dann ist das sowieso raus und ich muss mich erst gar nicht weiter damit beschäftigen. (Auch was wert )

Wie das genau geht, hängt vom Dateisystem ab. Aber die Schritte sind kurz gesagt: Anderes System booten, weil Dateisysteme verkleinern nicht gemountet geht. Dateisystem so verkleinern, dass es ganz sicher in die neue Partition passt, Partition so verkleinern, dass die neue Festplatte ganz genutzt wird, Dateisystem auf die Partitionsgröße erweitern. Dann steht dd nichts mehr im Weg. Wenn eine GPT-Partitionstabelle genutzt wird, muss die danach repariert werden, weil die Kopie am Ende der Platte verloren geht. Schritt 0, Backup, nicht vergessen.

Zitat von NaN

Partition so verkleinern, dass die neue Festplatte ganz genutzt wird

kommt natürlich immer auf den konkreten fall an,

aber ich schrumpfe vorher das source volume meist auf das minimum+kleiner puffer, klone und vergrößere anschliessend das target volume auf maximum/whatever.

theoretisch könnte man auch vorher das source volume »leerbereichsnullen« und ssh beim übertragen durch die kompression zeit sparen.

evtl. hat das schon jemand gemacht und kann berichten, was schneller läuft.

Zitat von Hille

1. nein, da das komplette Datensystem übertragen wird

wenn die target disk kleiner ist, kannst du eh nicht die ganze disk klonen.

-> wie von NaN beschrieben *, partition(en) verkleinern, bootsektor und partitionlayout sichern und auf ziel einspielen, partitionen klonen, vergrößern, fertig.

* NaN frage (weil nach nochmaligem lesen doch zweifel): klonst du mit deiner anleitung z.b. /dev/sda und läßt dd in den abbruch laufen (weil die target disk ja kleiner ist) oder klonst du die einzelnen partitionen?

Zitat von aRaphael

[…] Deshalb würde ich das Cloning per dd über ssh nochmal antesten.

1) Funktioniert das auch, wenn das Zielsystem kleiner ist? z.B. von RS 4000 auf RS 2000? Worauf muss ich da achten? […]

Dazu müßte man vorher das Dateisystem (und ggf. die Quellpartition) verkleinern können, damit es nicht größer ist als die Zielpartition, da nicht sichergestellt ist, "dass der leere Platz des Dateisystems am Ende der Partition liegt". resize2fs kann das mittlerweile für extN-Dateisysteme. Natürlich empfiehlt sich vorher ein Backup wie üblich.

Bei Verwendung von Btrfs/ZFS ist ein "Umweg" über dd hingegen nicht nötig, da hier die eingebaute "send/receive"-Funktionalität nur die Inhalte, aber keine 1:1-Abbilder der Sektoren überträgt (somit können die Größen der logischen datasets zwischen Quell- und Zielseite abweichen).

Ich hoffe das ich es nicht überlesen habe aber ich plane meinen VPS auf einen größeren (vor allem Platz Gründe) umzuziehen. Hat jemand eine Anleitung für Dummies wie ich das die Partitionen vergrößern kann?

Das ist eigentlich recht einfach. Dazu von einem Live ISO z.B. grml booten

1. cfdisk /dev/vda

Dort die entsprechende Partition per "Resize" vergrößern. Mit "Write" die Änderungen speichern.

2. resize2fs /dev/vda2

vobei vda2 die Partition ist, die vergrößert wurde.

Ich bleibe dann doch bei meiner rsync-Methode.

Mir ist jetzt auch klar geworden, woran es lag, dass es in einigen wenigen Fällen Probleme gab (Hatte die boot-Partition unsauber behandelt)