Snapshot und Speicherplatz?

    Hallo!

    Wenn ich bei einem VPS Snapshots nutze - also nur intern, nicht exportieren - wie werden die auf meinen gekauften Speicherplatz angerechnet? Und wo sehe ich das?

    Aktuell habe ich einen verschlüsselten Linux-LVM-Container auf dem System, sprich SCP sieht nur die ganzen hier benutzten 37GB, aber nicht was ggf im Filesystem noch frei ist.

    Im SCP steht nun: Speichernutzung vda: 38 GiB von 80 GiB belegt - soweit also verständlich.

    Ich habe aber auch ein Snapshot angelegt. Rechnet das nun auf die 80GB an? Und wenn ja, warum sehe ich das nicht im SCP angezeigt?

    Snapshots bei netcup (SCP) sind sogenannte Copy-on-Write-Snapshots. Das bedeutet, sie belegen zunächst kaum zusätzlichen Speicherplatz und wachsen erst dann, wenn sich Daten auf dem System ändern.

    Wichtig dabei: Die Daten des Snapshots werden nicht separat als zusätzlicher Speicher im SCP angezeigt, sondern zählen intern mit in den belegten Speicher deines Volumes hinein.

    In deinem Fall bedeutet das:

    • Die Anzeige „38 GiB von 80 GiB belegt“ bezieht sich auf den aktuellen Stand deiner vda
    • Der Snapshot selbst taucht dort nicht als eigener Posten auf
    • Zusätzlicher Speicherverbrauch durch den Snapshot entsteht erst, wenn sich Daten seit Erstellung des Snapshots ändern


    Änderst oder löschst du nach dem Snapshot größere Datenmengen, müssen die alten Daten für den Snapshot weiterhin vorgehalten werden, dadurch steigt die tatsächliche Belegung im Hintergrund.

    Dass du durch LVM + Verschlüsselung im Gast nur die belegten 37 GB siehst, ist normal – das SCP sieht nur die Blockdevice-Nutzung, nicht das „freie“ Filesystem innerhalb der VM.

    Eine direkte Anzeige, wie viel Platz ein Snapshot aktuell zusätzlich belegt, gibt es im SCP meines Wissens nach leider nicht. Man merkt es eher indirekt, wenn die belegten GiB ansteigen, obwohl sich im Gast-System nicht viel verändert hat.

    nur zur Sicherheit: Bei deiner Antwort ist berücksichtigt, daß meine 38 GB Dateisysteme in einem verschlüsselten LUKSContainer sind? Also daß es - so mein Verständnis - für netcup immer so aussieht, daß da 38 GB belegt sind? Wobei, Zusatzinfo: Ich habe inzwischen wirklich ca 38 GB Daten da drin und der Snapshot ist nach dem Runterladen (ich migriere auf einen größeren Server hier) wirklich 37 GB groß. Und trozdem steht da „38 GiB von 80 GiB belegt“?

    Zitat von stm77

    meine 38 GB Dateisysteme in einem verschlüsselten LUKSContainer sind? Also daß es - so mein Verständnis - für netcup immer so aussieht, daß da 38 GB belegt sind?

    Ist zwar für deine Frage nicht direkt relevant, aber falls Du LUKS benutzt und Dein OS ein regelmäßiges trim in dem verschlüsselten Dateisystem macht, zeigt Dir Netcup im SCP auch nur die tatsächlich benutzten Blöcke an, d.h. auch ggf. weniger als 38GB

    Damit LUKS trimmed, muss man das wollen, weil es die Verschlüsselung schwächen kann.

    | VPS: 28 | vCPU: 75 | Memory: 104 GB | Disk: 4012 GB |

    Zitat von stm77

    aaah, guter Hinweis. Wie bekomme ich das denn mit dem trim raus? Es ist ein aktuelles ubuntu-System.

    Trim wird über einen systemd timer aufgerufen, nach Installation eigentlich aktiv. Machmal ein sudo systemctl list-timers --all und halte nach fstrim.timer ausschau, auf meine Debian 13 (auch als Deb13 installiert) läuft es einmal die Woche. Ich habe allerdings noch ein paar uralte Server, die ich immer geupgraded habe, dort war es zum Installationszeitpunkt nicht mitinstalliert worden. (Vermutlich daher auch der Satz im SCP -- betrifft aber wirklich nur Installationen von 10 Jahren und älter) Bei meinem Ubuntu 24.04 ist es aktiv (ich glaube der war als 20.04 installiert).

    Zitat von daq4th

    Damit LUKS trimmed, muss man das wollen, weil es die Verschlüsselung schwächen kann.

    Ich würde mich als sehr vorsichtigen Nutzer bezeichnen, manch einer mich schon fast als Paranoid. Ich kenne das potentielle "data leakage" was Du zitiert hast, aber mal ehrlich: Netcup könnte sowieso (theoretisch) auf einen Encryptionkey im Arbeitsspeicher zugreifen, wozu sollte ich dann darauf auchten, dass ich Netcup den Füllstand meiner vda vorenthalte? Das ergibt wernig Sinn. Und "plausible deniability" geht bei Netcup eh nicht.

    Daher, denke ich, sollte man fair sein und trim auch bei LUKS anlassen, da Netcup Deinen freien Plattenplatz besser (und damit kostengünstiger(!) für alle) verwenden kann. Außerdem sterben nicht getrimmte NVMes schneller, daher habe ich es auch bei meiner eigenen Hardware immer an.

    Zitat von aRaphael

    Bist du sicher?
    Hast du dazu evtl. eine Quelle?

    Eine 100%ige Bestätigung oder Quelle habe ich dazu nicht :)

    Das Verhalten passt aber ziemlich gut zum üblichen Snapshot-Prinzip in KVM-Umgebungen, auf denen netcup ja basiert. Deshalb bin ich davon ausgegangen, dass hier ebenfalls Copy-on-Write verwendet wird.

    Zitat von SiebenG

    Ich würde mich als sehr vorsichtigen Nutzer bezeichnen, manch einer mich schon fast als Paranoid. Ich kenne das potentielle "data leakage" was Du zitiert hast, aber mal ehrlich: Netcup könnte sowieso (theoretisch) auf einen Encryptionkey im Arbeitsspeicher zugreifen, wozu sollte ich dann darauf auchten, dass ich Netcup den Füllstand meiner vda vorenthalte? Das ergibt wernig Sinn. Und "plausible deniability" geht bei Netcup eh nicht.

    Ich kenne einige Argumente für und gegen FDE bei vServern.

    Wenn du doch aber davon ausgehst, dass Netcup ohnehin auf den Key aus dem RAM zugreifen kann, was sind deine Beweggründe trotzdem FDE einzusetzen?

    Zitat von cltrmx

    Wenn du doch aber davon ausgehst, dass Netcup ohnehin auf den Key aus dem RAM zugreifen kann, was sind deine Beweggründe trotzdem FDE einzusetzen?

    Wie so manches im Leben: Risikominimierung. Sobald ich meinen Server runterfahre/ hart ausschalte, hat keiner mehr Zugriff auf meine Daten. Sollte mal ein anderer Kunde aus seinem KVM ausbrechen oder der Node von außen kompromittiert werden, sind die Daten durch einen Dritten auch nicht direkt aus dem Dateisystem auslesbar.

    Ich setze einfach darauf, dass ein möglicher Angreifer sich erst einmal bei den low hanging fruits (dh unverschlüsselte Instanzen) bedient, bevor er Speicher Abbilder erstellt oder meinen Bootprozess manipuliert, das sind bei Netcup noch mögliche Angriffsvektoren (kein secure boot, kein SEV. Beides wäre übrigens mit bestehender Hardware bei Netcup möglich)

    Ich habe auch mal yabs mit/ohne LUKS gebenchmarkt und konnte keinerlei Performanceverlust feststellen.

    FDE (Full Disk Encryption) erhoeht den Aufwand fuer alle potentiellen Angreifer erheblich, nicht nur fuer Netcup. Wir haben in der Vergangenheit ja schon diverse Exploits gesehen, mit denen die Grenzen zwischen verschiedenen VMs und zwischen VM und Host ueberwunden worden sind. Absolute Sicherheit vor Angreifern mit grossen Resourcen kann niemand garantieren, aber wenn ich die Huerden erhoehe, lohnt sich der Angriff auf mich hoffentlich nicht mehr.

    Falls es jemanden interessiert: Ich benutze FDE ueberall, wo es irgendwie geht. Aber ich lasse Trim auf die LUKS-Container zu. Der theoretische Informationsabfluss dadurch ist so minimal, dass die positiven Aspekte des Trim ueberwiegen. (Keywords "luks,discard" in /etc/crypttab)

    Zitat von heppel

    FDE (Full Disk Encryption) erhoeht den Aufwand fuer alle potentiellen Angreifer erheblich, nicht nur fuer Netcup. Wir haben in der Vergangenheit ja schon diverse Exploits gesehen, mit denen die Grenzen zwischen verschiedenen VMs und zwischen VM und Host ueberwunden worden sind. Absolute Sicherheit vor Angreifern mit grossen Resourcen kann niemand garantieren, aber wenn ich die Huerden erhoehe, lohnt sich der Angriff auf mich hoffentlich nicht mehr.

    Falls es jemanden interessiert: Ich benutze FDE ueberall, wo es irgendwie geht. Aber ich lasse Trim auf die LUKS-Container zu. Der theoretische Informationsabfluss dadurch ist so minimal, dass die positiven Aspekte des Trim ueberwiegen. (Keywords "luks,discard" in /etc/crypttab)

    So lange die Maschine laeuft, macht es keinen grossen Unterschied, ob verschluesselt oder nicht. In dem Moment, wo ein Angreifer aus einer VM ausbricht und den Hypervisor kompromittiert, hast du verloren. Generell macht man sich das Leben einfacher, in dem man nichts, was den Schutzbedarf "Normal" uebersteigt, extern betreibt. So lange das Backupkonzept steht und auch funktioniert, ist der Verlust solcher Systeme in Folge einer Kompromittierung zu vernachlaessigen. Sicherheitsluecke schliessen, Backup zurueckspielen und die Auswirkungen der Kompromittierung bewerten und Massnahmen ergreifen, bevor man wieder online geht. Full Disk Encryption wuerde ich nur bei Serversystemen mit Schutzbedarf "Hoch" in Erwaegung ziehen und auf jeden Fall ausschliesslich On-Premise betreiben.

    Bei temporaerem Austausch der eigenen personenbezogenen Daten ueber Nextcloud, Owncloud, Opencloud oder was auch immer, wuerde ich zuerst alles mit PGP verschluesseln, bevor es dort reinwandert.

    There are only 10 types of people in the world: those who understand binary, and those who don't.

    Zitat von ckd

    So lange das Backupkonzept steht und auch funktioniert, ist der Verlust solcher Systeme in Folge einer Kompromittierung zu vernachlaessigen. Sicherheitsluecke schliessen, Backup zurueckspielen und die Auswirkungen der Kompromittierung bewerten und Massnahmen ergreifen, bevor man wieder online geht.

    Das funktioniert aber auch nur, wenn man die Kompromittierung rechtzeitig erkennt (genau hier liegt das Problem) und somit ein sauberes Backup nutzen kann.