Du kannst das image mit nbdkit und entsprechenden zstd plugin on-the-fly bei der verwendung entpacken lassen. Dann musst du es nicht als entpacktes Image auf dem System speichern, sondern hast das image als Netzwerkblockgerät.
Entpacken ist für mich keine Option bei einem 960GB netcup-Laufwerk und einer 1TB lokalen SSD.
Entpacken ist in der Regel kein Problem, selbst wenn das Image-Laufwerk größer ist als dein lokales Laufwerk
Der raw-FIle ist ein sparse-File. Das Dateisystem wird dir dann für das entpackte Image zwar 960 GB anzeigen, aber es wird nur der tatsächlich belegte Platz auch benötigt. DIe "Löcher" werden nicht mitgespeichert. (Zumindest unter Linux. Ob das unter Windows auch so ist, weiß ich nicht)
Ich konnte z.B. vor kurzem problemlos eine 640 GB Paltte auf einem 320 GB-System entpacken, weil effektiv nur ca 30 GB genutzt wurden.
Wenn du allerdings die gesamten 960 GB voll mit Daten hast, dann wird es wohl nicht mehr gehen.
Ein funktionierendes, persönliches Backup ist für mich sehr wichtig. Wenn ich das Backup nicht mehr einfach überprüfen kann, dann macht der Server nicht mehr viel Sinn für mich.
Ich mache das immer so:
snapshot exportieren und herunterladen, mit zstd entpacken und mit qemu-img in qcow2 umwandeln
VPS (groß genug) mit stündlicher Abrechnung ordern, qcow2 hochladen, Server daraus wieder aufbauen, Netzwerk-Settings anpassen und grob durchtesten. Server wieder kündigen.
Dann habe ich nicht nur das Image überprüft, sondern auch den Wiederherstellungsprozess.
Und so teuer ist so ein stundenbasierter vServer, selbst für einen Tag, ja nicht.
(OK. Für ARM geht das so leider noch nicht, da gibt es noch keine stundenbasierten Server)
und noch am Rande:
Ein snapshot ist in meinen Augen allerdings kein wirklich guter Ersatz für ein Datenbackup.
Ich persönlich sichere per snapshot immer nur das Grundsystem, nach der kompletten Installation, Konfiguration, Absicherung und evtl. Installation der Anwendungen, um im worst case nicht wieder ganz von vorne anfangen zu müssen. Danach gibt es nur noch "normale Backups" aller Daten, Anwendungen und Konfigurationen. (täglich, auf zwei andere Standorte) Dann habe ich auch kein Problem mit der Größe des snapshots.
(Zumindest unter Linux. Ob das unter Windows auch so ist, weiß ich nicht)
Bist du dir sicher, dass das unter ext3/4 auch der Fall ist? Kann ich mir schlecht vorstellen.
Auf meinen System mit btrfs und aktivierter zstd 10 komprimierung wird das image "entpackt" dann vermutlich kleiner sein, als auf den Netcup Servern - wegen der komprimierung. Da ext so etwas jedoch nicht bietet, glaube ich nicht, dass eine Möglichkeit besteht, das Image dann anders, außer bit-weise, zu speichern.
Unter Windows würde eine aktivierte NTFS komprimierung wohl ähnliches machen.
Bist du dir sicher, dass das unter ext3/4 auch der Fall ist? Kann ich mir schlecht vorstellen.
Ext3/4 unterstützt Sparse Files. Es geht nicht um Kompression sondern darum, dass "leere" Blöcke in dem Image nicht gespeichert werden müssen. Das muss nicht nur das Dateisystem sondern auch das Programm unterstützen, das die Datei schreibt: Wenn man in eine Datei auf einem Dateisystem mit Sparse-Unterstützung einen Haufen Nullen schreibt, wird die Datei diese Nullen tatsächlich enthalten und den Platz dafür belegen. Der Entpacker muss clever genug sein, solche Stellen zu überspringen, indem der Schreibcursor bewegt wird, ohne Daten zu schreiben. Wenn das Programm das nicht kann, bietet sich an, die Daten nicht direkt in die Datei zu schreiben sondern durch dd mit der Option conv=sparse zu schicken.
(Zumindest unter Linux. Ob das unter Windows auch so ist, weiß ich nicht)
Ich teste ja gerne selber, wenn ich die Möglichkeit dazu habe, anstatt mich auf gefundenes im Internet zu verlassen. Und weils mich gerade selbst interessiert hat.
$ df -h .
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/loop0p1 10G 52M 10G 1% /media/gtazoccer/Test
$ fallocate -l 1G test.file
fallocate: fallocate failed: Die Operation wird nicht unterstützt
$ truncate -s 1G test.file
$ truncate -s 100G test2.file
$ du -hs *
0 test2.file
0 test.file
$ du -hs --apparent-size *
100G test2.file
1,0G test.file
$ df -h .
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/loop0p1 10G 52M 10G 1% /media/gtazoccer/TestNTFS hat damit kein Problem. Wenn auch fallocate hier anders arbeitet (vllt auch nur anders Prüft und zu falschen Ergebnissen kommt?) als truncate.
Bildschirmfoto vom 2024-02-24 12-42-17.png
Und Windows hat hier auch kein Problem mit.
Seit wann sind die virtuellen Platten eigentlich wieder als RAW gespeichert, wo doch erst vor ein paar Jahren unter großen Tam-Tam auf QCOW2 umgestellt wurde? Ich wurde heute beim Export davon überrascht. Gab's irgendwo eine Ankündigung, dass das Format geändert wird, oder auch nur, dass der Download nicht mehr mittels FTP möglich ist, oder hielt es Netcup nicht für nötig seine Kunden auf irgendeinem Weg zu informieren? 
Bist du dir sicher, dass das unter ext3/4 auch der Fall ist?
Ja, bin ich. 
