PBS Encrypted Backups und Deduplication

[BastianR]

Hallo zusammen,

wie die Deduplication beim PBS im Prinzip funktioniert, habe ich denke ich soweit verstanden.
Funktioniert das mit den shared Blocks auch noch, wenn die Encryption an ist? Entweder habe ich das im Handbuch nicht gefunden, oder es ist gut versteckt.

Danke!
Basti

 

[BastianR]

Ich hab gerade noch einen Beitrag von Fabian aus 2021 gefunden (https://forum.proxmox.com/threads/questions-about-encryption-and-backup-client.86464/post-379656)

the reason why deduplication does not work across encryption boundaries (e.g., between encrypted/unencrypted, but also between encrypted with key A and encrypted with key B) is that for a single chunk ZZZZ, not only the final chunk will be different (obviously, a plain chunk and an encrypted one can't have the same content else the latter would be unencrypted as well ), but already the digest will be different (for encrypted chunks, the digest is derived from the plain text content AND key, not just the plain text content) so that we can never mix them up accidentally either.

Wenn das noch so stimmt, ist meine Frage vermutlich schon beantwortet.

 

[aaron]

Solange der gleiche Key verwendet wird, sollte gut dedupliziert werden können. Andere Keys liefern andere Daten, die am PBS gespeichert werden. Ansonsten wäre es keine gute Verschlüsselung

 

[BastianR]

Macht natürlich sinn, vielen Dank!

 

[herzkerl]

Ich hoffe es ist okay, dass ich das aufgreife, ansonsten verschiebt den Beitrag gerne ein einen eigenen Thread

Wir sichern verschiedene Kunden-Cluster auf unseren zentralen Proxmox Backup Server und verwenden bei jedem Kunden natürlich einen eigenen Schlüssel zur Verschlüsselung. Somit kann hier natürlich keine Deduplizierung greifen – dann würde es ja auch keinen Sinn ergeben, die Backups auf einen gemeinsamen Datastore zu syncen, richtig?

Überall den gleichen Schlüssel zu verwenden ist ja auch keine Option, da dieser auf den PVE-Hosts liegen muss (logischerweise)...

 

[fabian]

in dem fall wuerde es vermutlich sinn machen, eigene datastores pro kunden zu verwenden (bringt potenziell auch mehr flexibilitaet im hinblick auf quotas, wenn das vom drunter liegenden storage unterstuetzt wird. bei ZFS z.b. leicht mittels 1 datastore == 1 dataset umsetzbar ).

 

[herzkerl]

Danke für die Rückmeldung – hast du zufällig noch einen Link zu einer Anleitung bzgl. ZFS und den Datastores mit Quota? Das klingt nach einer sehr guten Lösung!

 

[Dunuin]

Danke für die Rückmeldung – hast du zufällig noch einen Link zu einer Anleitung bzgl. ZFS und den Datastores mit Quota? Das klingt nach einer sehr guten Lösung!

Siehe "zfs set quota":
https://openzfs.github.io/openzfs-docs/man/8/zfs-set.8.html
https://openzfs.github.io/openzfs-docs/man/7/zfsprops.7.html#quota
https://docs.oracle.com/cd/E19120-01/open.solaris/817-2271/gazvb/index.html
https://linuxhint.com/setup-zfs-quotas-reservations/

 

[fabian]

sowohl quota (maximaler verbrauch) als auch reservation (zugewiesener speicher) sind interessant. beide properties lassen sich auch nachtraeglich aendern, um z.b. einem datastore mehr platz zuzuweisen. ansonstens einfach "zfs create" und PBS dann den mountpoint als neuen datastore konfigurieren lassen.

 

[herzkerl]

Danke euch für die Links und Informationen. Eine Rückfrage habe ich noch – habe trotz intensiver Suche keine Lösung gefunden (oder nicht die richtige Frage gestellt)...

Ich möchte die neuen Datastores auf dem gleichen zpool haben – also habe ich sie als dataset auf dem pool angelegt. Nun ist es aber so, dass die "neuen" Datastores für die Kunden (in PBS) als maximale Größe die derzeit freie Größe des bestehenden datasets haben. Wo liegt hier mein Denkfehler?

root@pbs:/mnt/datastore# zpool list
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
ceph-hdd   6.98T  5.52T  1.46T        -         -    29%    79%  1.00x    ONLINE  -

root@pbs:/mnt/datastore# zfs list
NAME                      USED   AVAIL     REFER  MOUNTPOINT
ceph-hdd                  5.52T  1.34T     5.52T  /mnt/datastore/ceph-hdd
ceph-hdd/kunde-1          24.3M  1.34T     24.3M  /mnt/datastore/kunde-1
ceph-hdd/kunde-2          24.3M  1.34T     24.3M  /mnt/datastore/kunde-2
ceph-hdd/kunde-3          24.3M  1.34T     24.3M  /mnt/datastore/kunde-3

Danke im Voraus!

 

[Dunuin]

Quota für Datasets setzen, siehe oben. Z.B zfs set quota=100G ceph-hdd/kunde-1 wenn kunde-1 maximal 100GiB nutzen können soll.

 

[herzkerl]

Sorry, hatte den anderen Output vergessen – aus dem oberen wurde gar nicht klar, was ich eigentlich meinte.

root@pbs:~# df -h
Filesystem                         Size  Used Avail Use% Mounted on
ceph-hdd                           6.9T  5.6T  1.4T  81% /mnt/datastore/ceph-hdd
ceph-hdd/kunde-1                   1.4T   25M  1.4T   1% /mnt/datastore/kunde-1
ceph-hdd/kunde-2                   1.4T   25M  1.4T   1% /mnt/datastore/kunde-2
ceph-hdd/kunde-3                   1.4T   25M  1.4T   1% /mnt/datastore/kunde-3

Die Dateisystemgröße wurde hier beim Anlegen nämlich auf den beim Anlegen zur Verfügung stehenden Speicher festgelegt. Sehe ich das richtig, dass das nur ein kosmetisches "Problem" ist? PBS reported diese size nämlich auch in der UI...

 

[fabian]

wenn du uns zfs get all -r ceph-hdd (oder zumindest den relevanten teil der sich auf reservations/quotas/space usage bezieht) schickst laesst sich vielleicht mehr sagen - so ist das bild etwas unvollstaendig

meine vermutung - du hast 4x 1.4T reserved (==5.6T) und zufaellig sind dann auch noch ca 1.4T frei (auf die 6.9T gesamtspeicher)?

 

[herzkerl]

Habe nun nochmal nachgelesen und kann bestätigen, dass es ein Missverständnis auf meiner Seite ist. Es ist wohl standardmäßig so, dass die nested datasets als maximalen Speicher des Dateisystems immer den aktuell maximal zur Verfügung stehenden Speicher auf dem Pool angeben – außer, es ist eine Quote gesetzt.

Aus dem TrueNAS-Forum (Quelle):

Yep, that's normal. It's due to the way ZFS handles datasets, which is to say that the total *possible* size of your Home dataset is now 469gig, which should be the current file-load of 414gig plus the 55gig that's free space on the mirror set.

Ich hatte ja bisher noch keine Quote gesetzt, d.h. der maximal zur Verfügung stehende Speicher (filesystem size) schwankt nun für alle Datasets. Ich werde demnächst noch die Daten des root datastores ebenfalls in einen nested datastore packen, gehe aber nicht davon aus, dass das daran etwas ändern wird.