Snapshot auf Server mit geringerem Speicherplatz einspielen

  • Hi zusammen,


    ich möchte einen Snapshot, den ich von einem netcup vServer mit 750 GB Speicherplatz erstellt habe, auf einem netcup vServer mit 320 GB Speicherplatz installieren. Der tatsächlich belegte Speicherplatz des alten Servers beträgt etwas über 50 GB. Ich habe mich schon ein wenig durch's Forum gewühlt und dabei auch den einen oder anderen Beitrag zum Thema gefunden. Allerdings kriege ich es noch immer nicht zum Laufen.


    Was habe ich gemacht?


    1. Den alten Server mit dem Rettungssystem gestartet und die größte Partition /dev/sda3 von ca. 750 GB auf 100 GB verkleinert:

    Code
    resize2fs /dev/sda3 100G

    2. Den alten Server neugestartet und getestet, ob noch alles funktioniert.

    3. Den alten Server heruntergefahren, einen Snapshot erstellt und exportiert.

    4. Den Snapshot bereinigt (ich bin mir nicht sicher, ob das nötig ist):

    Code
    virt-sparsify snapshot.qcow2 snapshot2.qcow2

    5. Den Snapshot ins RAW-Format konvertiert:

    Code
    qemu-img convert -O raw snapshot2.qcow2 snapshot2.raw

    6. Die Virtual Disk Size verkleinert:

    Code
    qemu-img resize -f raw --shrink snapshot2.raw 320G

    7. Den Snapshot zurück ins QCOW2-Format konvertiert:

    Code
    qemu-img convert -O qcow2 -o compat=1.1 snapshot2.raw snapshot3.qcow2

    8. Den Snapshot im SCP hochgeladen und auf dem neuen Server eingespielt.

    9. Beim Starten des Servers kommt die Meldung:

    Code
    Gave up waiting for root file system device.  Common problems:
    - Boot args (cat /proc/cmdline)a372-fa683b4f2929
      - Check rootdelay= (did the system wait long enough?)
    - Missing modules (cat /proc/modules; ls /dev)
    ALERT!  UUID=24223d7c-5e1a-47ef-af47-97f1857da6db does not exist. Dropping to a shell!

    Tatsächlich habe ich auch testweise schon die Schritte 4 und 5 getauscht, sprich: Den Snapshot erst ins RAW-Format konvertiert und dann mit virt-sparsify bereinigt.


    Zur Info: qemu-img info liefert für den Original-Snapshot folgendes:

    Code
    image: snapshot.qcow2
    file format: qcow2
    virtual size: 750G (805306368000 bytes)
    disk size: 48G
    cluster_size: 65536
    Format specific information:
        compat: 1.1
        lazy refcounts: false
        refcount bits: 16
        corrupt: false

    ...und für das Ergebnis folgendes:

    Code
    image: snapshot3.qcow2
    file format: qcow2
    virtual size: 320G (343597383680 bytes)
    disk size: 48G
    cluster_size: 65536
    Format specific information:
        compat: 1.1
        lazy refcounts: false
        refcount bits: 16
        corrupt: false


    Hat jemand einen Tipp für mich? Was mache ich falsch?


    VG

  • […]

    8. Den Snapshot im SCP hochgeladen und auf dem neuen Server eingespielt.

    9. Beim Starten des Servers kommt die Meldung:

    Code
    […] ALERT!  UUID=24223d7c-5e1a-47ef-af47-97f1857da6db does not exist. Dropping to a shell!

    Ich würde vermuten, dass ggf. bei einem der Konvertierungsschritte während einer Formatänderung auch die Partitions-UUID(s) geändert wurden. Das lässt sich einfach überprüfen und korrigieren, indem man entweder das Rettungssystem oder ein dediziertes ISO-Abbild für das verwendete System (entsprechend der Distribution/dem Release) bootet und die Ausgabe von ls -l /dev/disk/by-uuid mit den Einträgen in /etc/fstab usw. abgleicht.

    Danach das initramfs neu erzeugen und die Grub-Bootmenü-Einträge aktualisieren, sofern dort ebenfalls Partitionsreferenzen enthalten sind.

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

  • Vielen Dank, m_ueberall, für die Tipps. Leider komme ich trotzdem nicht weiter. Eine Standard Debian 10 Installation liefert bei ls -l /dev/disk/by-uuid folgendes:


    Code
    # ls -l /dev/disk/by-uuid
    total 0
    lrwxrwxrwx 1 root root 10 Jun 19 22:26 24223d7c-5e1a-47ef-af47-97f1857da6db -> ../../sda3
    lrwxrwxrwx 1 root root 10 Jun 19 22:26 9872eabf-5cc6-416c-a122-518ef7f6fd05 -> ../../sda2

    Da wäre also schon mal die UUID, die beim Booten nicht gefunden wird. Allerdings erschließt sich mir nicht, wie ich an die Einträge in /etc/fstab herankomme. Sobald ich das Rettungssystem starte, erhalte ich mittels cat /etc/fstab ja die Einträge des Rettungssystems, oder?

    Und /dev/sda3 existiert gar nicht erst - auf dem alten Server kann ich es natürlich aus dem Rettungssystem mounten.


    Kann es sein, dass die Partition beim Verkleinern mittels qemu-img resize zerstört wird?


    VG

  • Allerdings erschließt sich mir nicht, wie ich an die Einträge in /etc/fstab herankomme.

    Du musst die Partition mounten z.B. nach /mnt und dann hast du über /mnt/etc/fstab dein fstab - sofern sda3 auch die Betriebssystempartition ist - und nicht eine andere Partition.



    Und /dev/sda3 existiert gar nicht erst

    lrwxrwxrwx 1 root root 10 Jun 19 22:26 24223d7c-5e1a-47ef-af47-97f1857da6db -> ../../sda3

    Klar existiert die, sonst würdest du die UUID dazu nicht angezeigt bekommen. Welche Fehlermeldung erhälst du denn?

  • Hi H6G,


    die Ausgabe lrwxrwxrwx 1 root root 10 Jun 19 22:26 24223d7c-5e1a-47ef-af47-97f1857da6db -> ../../sda3 stammt, wie von m_ueberall empfohlen, von einem fabrikneuen Debian. Auf dem Rettungssystem schlägt ls -l /dev/disk/by-uuid fehl. Dort liefert aber aber

    ls -l /dev/disk/by-id folgendes:

    Code
    # ls -l /dev/disk/by-id  
    total 0
    lrwxrwxrwx 1 root root 9 Jun 20 20:29 ata-QEMU_DVD-ROM_QM00003 -> ../../sr0
    lrwxrwxrwx 1 root root 9 Jun 20 20:29 scsi-0QEMU_QEMU_DVD-ROM_QM00003 -> ../../sr0
    lrwxrwxrwx 1 root root 9 Jun 20 20:29 scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-0 -> ../../sda
    lrwxrwxrwx 1 root root 9 Jun 20 20:29 scsi-1ATA_QEMU_DVD-ROM_QM00003 -> ../../sr0

    Wie schon geschrieben, ist auf dem Rettungssystem /dev/sda3 gar nicht erst vorhanden:

    Code
    # ls -l /dev/sd*
    brw-rw---- 1 root disk 8, 0 Jun 20 20:29 /dev/sda

    Deshalb kann ich es auch nicht mounten.


    Das Rettungssystem des Servers, auf dem ich den Snapshot ursprünglich erstellt habe, sieht das anders aus:

    Code
    # ls -l /dev/sda*
    brw-rw---- 1 root disk 8, 0 Jun 21 08:38 /dev/sda
    brw-rw---- 1 root disk 8, 1 Jun 21 08:38 /dev/sda1
    brw-rw---- 1 root disk 8, 2 Jun 21 08:38 /dev/sda2
    brw-rw---- 1 root disk 8, 3 Jun 21 08:38 /dev/sda3

    VG

  • Wie sieht es denn aus, wenn du mit den üblichen Verdächtigen wie cfdisk o.Ä. dir einmal die Partitionstabelle anguckst.

    Da sieht es auf dem neuen System so aus:

    Code
    Disk: /dev/sda
                    Size: 320 GiB, 343597383680 bytes, 671088640 sectors
                             Label: dos, identifier: 0x00000000
    
        Device        Boot       Start           End      Sectors    Size   Id Type
    >>  /dev/sda1                    1    1572863999   1572863999    750G   ee GPT

    hier könnte auch das Problem zu sehen sein: /dev/sda1 ist 750 GB groß - was gar nicht sein kann, da der Server ja nur 320 GB Speicherplatz besitzt.


    Auf dem Quellsystem sieht das übrigens so aus:


    Code
    Disk: /dev/sda
                    Size: 750 GiB, 805306368000 bytes, 1572864000 sectors
                Label: gpt, identifier: 744D726A-2AC1-7744-89B3-072E6920B57A
    
        Device             Start           End       Sectors     Size Type
    >>  /dev/sda1           2048          6143          4096       2M BIOS boot          
        /dev/sda2           6144       2103295       2097152       1G Linux filesystem
        /dev/sda3        2103296    1572863966    1570760671     749G Linux filesystem
  • Hi,


    Du hast im ersten Schritt ganz oben das filesystem mit resize2fs verkleinert. Davon unbeeindruckt ist aber die darunter liegende Parition - die Du in deinem letzten Post mit cfdisk anschaust.

    Die meisten Scenarien sprechen von Erweiterungen, aber schau doch mal nach parted. Wäre auch spannend ob growpart zum shrinken nutzbar ist, ob das geht habe ich aber auf die Schnelle nicht gefunden. Das es eine Try Run Option gibt solltest Du das aber schnell herausfinden können.


    ItsMee