Server Snapshot

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.

Zitat von huhu

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.

Zitat von huhu

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.

Zitat von aRaphael

(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.

Zitat von christianr

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.

Zitat von aRaphael

(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/Test

NTFS 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?

Zitat von christianr

Bist du dir sicher, dass das unter ext3/4 auch der Fall ist?

Ja, bin ich.

von wegen sparse...

ich entpacke gerade mein 7 GB vServer snapshot (Server benutzt effektiv 13 GB) mit unzstd ...raw.zst

Meine 1 TB Platte hat 500 GB frei. Der vServier eine 512 GB disk, die aber eben nur 13 GB enthält. Fazit Platte voll, Image nicht entpackt... Hat sich was geändert??? So ist das ja wirklich kaum zu gebrauchen. qcow2 wäre ideal als export format.

edit

lt. Doku soll man statt unzstd

zstd -d snapshot.raw.zst -o snapshot.raw

nehmen

mal schauen...

edit2: ne, der selbe Käse... Platte voll

Normalerweise sollte das gehen. Vielleicht hilft dir ein Trick, wenn du keine sparse Dateien schreiben kannst:

mkdir emptydir
mksquashfs emptydir snapshot-squashfs.img -p "snapshot.raw f 755 0 0 zstd -c -d snapshot.raw.zst" -comp zstd
rmdir emptydir

Das erzeugt ein Squashfs-Image, das als einzige Datei den entpackten Snapshot enthält. Das Image wird aber selbst mit zstd komprimiert und sollte nur wenige Kilobyte mehr Platz benötigen als der komprimierte Snapshot. Das Image kannst du dann mounten und den Snapshot darin dann ebenfalls. Bearbeiten kannst du den Snapshot so nicht, weil das Squashfs-Dateisystem nur lesbar ist. Du kannst aber qemu-img convert auf den dann lesbaren entpackten Snapshot ansetzen, um daraus ein QCOW2 Image zu machen.

Danke. Das probier ich morgen mal aus!

Zitat von PeterR

Hat sich was geändert???

Das kann durchaus sein, denn ich habe vor kurzem leider die gleiche Erfahrung gemacht:

Zitat von aRaphael

Das hat bei meinem letzten Versuch (mit Export und Download) schon beim Konvertieren nicht mehr geklappt.

Das Umwandeln des heruntergeladenen zstd-Images in qcow (über raw) ging nicht mehr. (Man kann ja nur qcow2 oder raw hochladen, das heruntergeladene zstd-Image direkt hochladen geht nicht) Ich konnte das zstd-Image nicht mehr in raw entpacken, weil "zu wenig Speicherplatz".

Das raw-Image ist zwar nominell so groß wie die zugrunde liegende Platte, aber ein sparse-File und die leeren Lücken nehmen keinen Platz weg. Bisher ging das auch immer. Beim letzen Versuch nicht mehr. Umzug über download/Upload war also nicht möglich.

Versucht es mal wie in #6 angedeutet mit zstd -c -d snapshot.raw.zst | dd conv=sparse bs=1M of=snapshot.raw status=progress

Sonst eben mit dem Squashfs-Umweg: Der braucht gar keine Sparseunterstützung und weniger Festplattenspeicher, dauert wegen der Neukomprimierung aber etwas.

(Passt mit sparse-Ausgabe auf, wenn die Ausgabe nicht in ein File sondern auf ein Device geht. Was in dem Sparse-File noch Nullen enthielt, enthält dann, was vorher auf dem Device war. Das kann den Inhalt von Dateien in einem Filesystem betreffen, das ihr schreibt!)

Nein, werde ich wohl nicht mehr versuchen. Auch nicht die Methode mit dem Squashfs. (Trotzdem danke für die Tipps )

Die unflexible, umständliche und zeitraubende Methode der netcup-snapshots nervt mich schon länger.

Seitdem das Entpacken des sparse-file nun auch nicht mehr ohne solche Klimmzüge geht (wenn überhaupt?), bin ich dazu übergegangen die Server, bei denen ich öfter mal neue Instanzen aus snapshots erstellen muss, in die Cloud beim roten H umzuziehen. Dort geht das problemlos mit wenigen Klicks.

Bei den verbliebenen netcup-Servern bin ich dazu übergegangen mit rsync zu klonen, statt über snapshots.