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.

    Quote from 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.

    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 ;))

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    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

    Quote from 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.

    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.

    Quote from 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.


    Quote from 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?

    »Hauptsache BogoMIPS!«

    Fleischfresser

    »Sämtliche Cyberrisikomanagementmaßnahmen wurden übererfüllt!«

    Volksfront DLT #60Ksplit

    Edited 6 times, last by Olivetti ().

    Quote from 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).

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    Edited 4 times, last by m_ueberall ().

    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.