Snapshot Export: ZST vs. QCOW2

    Hallo zusammen,

    Letztes Jahr wurde unser Snapshot als QCOW2 via FTP exportiert (51 Gig), was gut funktionierte.

    Heute wurde unser Snapshot als ZST via Browserdownload exportiert (21 Gig), was nicht so gut funktionierte.

    Das neue Image ist wesentlich kleiner. Wie ist dieser Unterschied zu erklären? Was genau ist der Unterschied der Formate?

    Selbstverständlich ist der belegte Speicher unseres Servers über die Zeit eher gewachsen als geschrumpft (aktuell laut SSH ca. 60 Gig, inkl. Snapshot).

    Vielen Dank

  • Zur hilfreichsten Antwort springen
    • Hilfreichste Antwort
    Zitat von neoda

    Heute wurde unser Snapshot als ZST via Browserdownload exportiert (21 Gig), was nicht so gut funktionierte.

    Ich würde dir empfehlen, das nicht über den Browser zu machen, sondern im SCP die Möglichkeit zu nutzen, dir eine Download-URL erstellen zu lassen, um das dann mit wget oder curl herunterzuladen Das ist zuverlässiger als über den Browser.

    Zu beachten:

    Bisher war es aber nicht möglich die heruntergeladene zst-Datei wieder hochzuladen, um den spapshot zurückzuspielen!

    Die musste vorher lokal entweder in das raw-Format entpackt werden oder in qcow2 umgewandelt. Nur raw oder qcow2 konnte hochgeladen werden.

    Keine Ahnung, ob sich das inzwischen geändert hat. (Ich selbst nutze bei netcup keine snapshots mehr, sondern spiegele direkt mit rsync)

    Zitat von neoda

    Das neue Image ist wesentlich kleiner. Wie ist dieser Unterschied zu erklären? Was genau ist der Unterschied der Formate?

    Selbstverständlich ist der belegte Speicher unseres Servers über die Zeit eher gewachsen als geschrumpft (aktuell laut SSH ca. 60 Gig, inkl. Snapshot).

    zstd komprimiert stärker. Mit der Standard-Kompressionsstufe wird ein durchschnittliches zst-Image nur (grob) ca 1/3 der Größe eines qcow2-Images haben.

    Dafür dauert die Komprimierung aber auch länger. Bei hohen Kompressionsstufen muss man da schon viel Geduld mitbringen. ;)

  • neoda 26. August 2024 um 18:14

    Hat einen Beitrag als hilfreichste Antwort ausgewählt.

    @aRaphael Vielen Dank, das bringt doch schon einiges Licht ins Dunkel! Ich habe jetzt die ZST File entpackt und die RAW Datei ist ganze 140 Gig groß. Also genau so groß wie die Festplatte des Servers Das ist natürlich furchtbar, wenn man das Backup im Notfall tatsächlich hochladen muss. Ich habe jetzt auf die Schnelle auch keine Möglichkeit gefunden eine Konvertierung ins QCOW2 Format unter Windows vorzunehmen. Und überhaupt kann bei einer Konvertierung auch einiges schiefgehen, ohne dass man es zunächst bemerkt.

    Ich werde mich nochmals direkt an den Netcup Support werden. Der Backup-Prozess wurde durch diese Umstellung definitiv verschlechtert. Die Lösung wäre doch, dass man direkt die ZST hochladen kann oder wahlweise im alten QCOW2 Format exportiert.

    Zitat von neoda

    ...und die RAW Datei ist ganze 140 Gig groß. Also genau so groß wie die Festplatte des Servers

    Das ist kein Problem. Das ist ein sogenannter Sparse-File. Der wird nur von deinem Dateisystem so groß angezeigt. Die vielen Löcher (Nullen), die da drin sind, nehmen keinen Platz weg. Ich suche dir mal die Infos raus, die ich dazu hier schonmal gepostet habe.

    EDIT: Hier z.B.: https://forum.netcup.de/administration…hot/#post217987

    Man sollte eigentlich auch unter Windows raw in qcow2 umwandeln können.

    Auf jeden Fall klappt das prinzipiell problemlos und ich habe das schon öfter gemacht. (Allerdings auf Linux): zst zu raw entpackt und das dann in qcow2 umgewandelt. Lies sich problemlos wieder hochladen und installieren.

    Zitat von Interessent

    Kannst du dazu mehr sagen? Spiegelst du alle Dateien? Oder wie machst du das?

    Poste ich gleich mal. (Nach dem Essen ^^ )

    Danke. :)

    So mache ich das seit einiger Zeit:

    Webserver runterfahren und dann den kompletten Server in ein Unterverzeichnis eines anderen Server spiegeln, unter Ausschluß der "serverspezifischen" Dateien. z.B.:

    rsync -axHAXvP --numeric-ids --delete --exclude-from=exclude.txt / root@BACKUPSERVER:/opt/mirror

    Der Inhalt der exclude-Datei (Für Ubuntu. Bei Debian o.a. netzwerkspezifisch anpassen):

    Das wars schon. :)

    Das lässt sich dann alles jederzeit wiederherstellen, auf einem anderen Server mit dem gleichen OS.

    Auch auf einem der kleiner ist als der usrprüngliche! (Was ja bei einem snapshot nicht geht) Das war auch meine Motivation es mal so zu probieren.

    Das Zurückspiegeln geht folgendermaßen:

    Neuen Server (gleiche Architektur) aufsetzen, mit dem gleichen Basisbetriebssystem.

    Das ist natürlich ein zusätzlicher Aufwand, aber es langt ja, wenn man ein Standard-Image aufspielt.

    Man muss nur darauf achten, dass es die gleiche Version des OS ist, wie auf dem Ursprungsserver.

    Das Zurückspielen mache ich zur Sicherheit immer im Rettungssystem des Zielservers:

    Zielserver in das Rettungssytem booten und die OS-Partition mounten, z.B.:

    mkdir /mnt/target

    mount /dev/vdb3 /mnt/target

    (Muss natürlich nicht vdb3 sein. Die Systempartition kann man mit fdisk -l rausfinden)

    Dann im Quellserver

    rsync -axHAXvP --numeric-ids --delete --exclude-from=exclude.txt /opt/mirror/ root@ZIELSERVER:/mnt/target/

    (Nicht den slash am Ende des Quellverzeichnisses vergessen, sonst wird nur das Verzeichnis in die root des Zielservers kopiert)

    Rettungssystem abschalten und erfreut zusehen, wie der Server bootet. :) (Oder ein langes Gesicht machen, weil man was falsch gemacht hat ^^ )

    (Ich muss dann nur noch die ip in /etc/hosts ändern, weil ich die Dateien, die den hostname betreffen nicht ausschließe. Kann man aber natürlich auch anders machen)

    Die Methode klingt zunächst umständlich, hat aber einige Vorteile.

    Ich habe das permanent im Einsatz und keiner der wiederhergestellten Server zeigt Auffälligkeiten.

    (Anfangs habe ich immer das syslog nach dem ersten booten akribisch überprüft, aber mittlerweile habe ich Vertrauen in diese Methode)

    Danke, dass muss ich mal probieren. Geht ja bestimmt auch auf die NAS zum Test...

    Zitat von aRaphael

    (Ich muss dann nur noch die ip in /etc/hosts ändern, weil ich die Dateien, die den hostname betreffen nicht ausschließe. Kann man aber natürlich auch anders machen)


    Vll. verstehe ich es auch nur falsch, aber wenn Du /etc/hosts nicht auschließt, dann werden doch diese Dateien mit rsync auf den Zielserver übertragen und von dort dann auch wieder zurück auf den Quellserver. Damit sollte doch alles passen, oder?

    Zitat von hoedlmoser

    hm? Du installierst am zielsystem ein komplettes OS.

    Ja, aber in der Regel installiere ich einfach, mit wenigen Klicks ein vorgefertigtes Image im SCP.

    Das alles muss ich dann z.B. nicht mehr machen:

    "partitionen erstellen und filesysteme initialisieren (...) grub installieren (...) in der /etc/fstab ie uuids aus blkid anpassen (...) /etc/mdadm/mdadm.conf anpassen (...) die IP adresse anzupassen, die stellen findet man mit fgrep (...) boot-fähig machen"

    Verstehe mich nicht falsch. Ich sage nicht, dass deine Methode schlechter ist. Beide Methoden sind brauchbar. Ist halt ein wenig Geschmacksache wie man vorgeht und hängt auch von Einzelfall ab. Wenn man z.B. gar nicht die Möglichkeit hat, vorher die exakt gleiche OS-Version auf dem Zielserver zu installieren, dann geht das so wie ich es mache halt nicht.

    Zitat von Interessent

    Vll. verstehe ich es auch nur falsch, aber wenn Du /etc/hosts nicht auschließt, dann werden doch diese Dateien mit rsync auf den Zielserver übertragen und von dort dann auch wieder zurück auf den Quellserver. Damit sollte doch alles passen, oder?

    Ja, wenn alles wieder auf den Ursprungsserver wiederhergestellt wird. Falls es aber ein anderer ist, dann hat der ja andere ips. Deshalb schließe ich ja auch die Netzwerkkonfiguration (Bei Ubuntu /ect/netplan) aus, damit ich das nicht manuell anpassen muss. Durch die vorherige Installation des OS passt die ja schon.

    Zitat von aRaphael

    Ja, wenn alles wieder auf den Ursprungsserver wiederhergestellt wird. Falls es aber ein anderer ist, dann hat der ja andere ips. Deshalb schließe ich ja auch die Netzwerkkonfiguration (Bei Ubuntu /ect/netplan) aus, damit ich das nicht manuell anpassen muss. Durch die vorherige Installation des OS passt die ja schon.

    Ok, jetzt ist es klar. Mir geht es jetzt primär nur um Wiederherstellung auf die gleiche Maschine.