Proxmox & deduplication?

ncage

Member
Jan 28, 2022
8
0
6
50
Right now my backups are not encrypted. I would assume deduplication works between different vm/containers? So if you have a file on multiple containers/vms it would only be stored once?

Which leads to my question....i'm thinking on encrypting my backups. If i use the same encryption key for all vm/containers will deduplication still be able to do this? Granted if there was a different encryption key i understand it wouldn't.
 
Yep, deduplication works within a datastore and also within the same encryption key. The same data, ecrypted with the same key, will result in the same chunk sent to the PBS.
Different key and the chunk sent to the PBS is different, as you expect :)
 
Right now my backups are not encrypted. I would assume deduplication works between different vm/containers? So if you have a file on multiple containers/vms it would only be stored once?
In theory yes, but in practice its not that easy. For VMs, PVE will chop that virtual disk in 4MB chunks, compress them, encrypt them and send them to the PBS. Only if every bit of those 4MB is identical it will be deduplicated. So won't help that much for small files. And then not all files are aligned to 4MB. Lets say you got a 5MB file "ABCDE" with some random data "OOO". Each letter A, B, ..., O is 1 MB of sectors:
VM1: "OABCDEOO" gets split into chunks "OABC" + "DEOO"
VM2: "OOABCDEO" gets split into chunks "OOAB" + "CDEO"

While both VMs store the same file, the resulting 4 chunks that get deduplicated will be all different and aren't deduplicatable.

So it's more useful in case you store multiple backups of the same VM or if you are working with clones created from a template.
 
Last edited:
  • Like
Reactions: used1d and _gabriel
@Dunuin @aaron So, how to encrypt backups AND dedup?
? If you use the same encryption key you will get good dedup. For example, in a Proxmox VE cluster, you will use one encryption key per storage config.
So if you have a second Proxmox VE cluster that is using the same PBS and datastore (ideally separated by namespace), you could upload the same key to it to improve deduplication.

But if you need or want different encryption keys, then that key will be a hard border across which no deduplication will happen.
 
  • Like
Reactions: Johannes S and UdoB
? If you use the same encryption key you will get good dedup. For example, in a Proxmox VE cluster, you will use one encryption key per storage config.
So if you have a second Proxmox VE cluster that is using the same PBS and datastore (ideally separated by namespace), you could upload the same key to it to improve deduplication.

But if you need or want different encryption keys, then that key will be a hard border across which no deduplication will happen.
I see. So, if one of my ZFS pools in PVE is encrypted already and I want to back it up on PBS, then are you saying that I should use that same ZFS encryption key on PBS?

(The ZFS pool is only for a particular VM, but I'd like to have encrypted backups of all other VMs and CTs, too. That's why I'm wanting the ZFS pool as well as the PBS encrypted.)
 
PVE/QEMU backup sends not encrypted data to PBS, no matter if ZFS encryption is enabled.
Hi, thanks for the info. But I'm not sure what that means... It sends "not encrypted" data..?...meaning it decrypts ZFS data then sends it unencrypted to PBS?
 
VM and the PVE/QEMU doesn't know the "Storage backend" (ZFS,Lvmthin,Ceph,QCOW2) neither if encrypted or not.
So backup of VM should be encrypted by itself , that's why exist backup encryption in PBS.
 
  • Like
Reactions: used1d
VM and the PVE/QEMU doesn't know the "Storage backend" (ZFS,Lvmthin,Ceph,QCOW2) neither if encrypted or not.
So backup of VM should be encrypted by itself , that's why exist backup encryption in PBS.
Ok cool, thanks!

To clarify, is the proper way to set it up to NOT encrypt the ZFS pool and to only encrypt the PBS? If so, how to keep safe data that is on the PVE server at rest? (In case of theft or breach..?)
 
I suspect that you are mixing up the layers. The encryption and deduplication in Proxmox Backup Server is filesystem-agnostic so it has nothing to do with the encyption you do on the ProxmoxVE host or inside a vm and especially nothing to do with ZFS.
Let's go through some scenarios:

  • You have an encrypted ZFS dataset (for a container or with some iso files) or volume (VM disc) on the Proxmox host: The backup won' backup the encrypted state, since it backups the state after you decrypted the ZFS. As explained by _gabriel qemu, ceph, lxc don't know and don'care about the encryption. For them the unlocked dataset or volume behaves like regular storage. So: As long as you use the same key for all your backups PBS deduplication will work and the backups will all be encrypted. As explained by aaron usually you will have one key one PBS configured as backup target on your ProxmoxVE single-node or cluster. If you use the same key for another cluster or single-node, the backup will still be encrypted and deduplication will still work. if however you use a different key (maybe one of your clusters is on a rented dedicated server so you don't trust it enough to use the same key) then it will still be encrypted but you will need more storage space on the datastore.
  • You have encryption inside your VMs (with ZFS or Linux LUKS): The VM will still be encrypted and saved to the PBS datastore. Since you most likely won't use the same key in any VM the deduplication will only work for every backup of one VM but not of all. Let's say you have two vms with the ids 100 und 101, both with the same linux distribution and applications. Each one has their own dedicated encryption inside the vm with a different key. You do hourly backups. So deduplication will still save space (because of all the backups of one vm, only the differences needs to be saved) but not as much as you would if the backup of VM101 and VM 100 would be able to profit from already saved contents of the other vm.
  • You don't use encryption on the ProxmoxVE host or inside the VMs at all but only on the backup to PBS: Deduplication will still work and backups will still be encrypted.
So in the end you need to decide which layer (ProxmoxVE host, VM/LXCs, backup) needs encryption and where you can live without it.

For example: In my homelab my servers and vms are all NOT encrypted: The worst which might happen is that some burglar would break in at night and take all my stuff with him. This would be quite annoying and expensive (due to the need to replace all my toys aka homelab hardware ;) but in the end I would still have my backups (more on this later) and nothing of the data is that sensible that I can't bear that some burglar goes through them and look up my questionable music/movie taste, tax records or vacation photos :) And if I throw the stuff away I would have to wipe the discs non the less.
Now what's the benefit of not having encryption: No need to enter any passphrases, easier recovery in case of an error or an update gone wrong.

My notebook and backups are a different story though: I take my notebook with me all the time, if I ever loose it I don't want anybody to access the contents. So it's encrypted and I need to enter a passphrase everytime I boot the thing. And for the backups: The raw data from my notebook and NAS is backed up to a hetzner storagebox with restic. I can't trust it too much because (although they have a good track record in terms of security) Hetzner might get hacked. Thus I use restics function for encrypted backups.

Same is true for the backup of my lxcs and vms: I have a remote PBS on a cheap vserver at netcup which pulls my local backups from the PBS in my local network . I assume that it might get hacked at any time without me even noticing it. Thus I encrypt all my vm and lxcs backups so even if some attacker might be able to access the backups on my storagebox or vserver he wouldn't be able to do much with them.

Companys also need to think of such tradeoffs: For notebooks or workstations in their office encryption is a good idea since burglars might break and take all the workstations with them. In a protected, guarded datacenter you don't need to worry much about burglars but more about your employees and anybody with datacenter access can do enough damage with or without encryption. So most of the time you don't need it and can save yourself the added complexitys and issues in case of the need for recovery. The story might be different though if some regulations you are subject too (e.g. if you are a military contractor) force you to encrypt all your stuff.

So in the end it depends on your level of paranoia and which poison you want to pick ;)
 
Last edited:
@Johannes S Thank you for that great explanation and examples. Now I believe I mostly understand. But what I still need clarification on is: I have my ZFS pool encrypted on PVE, and when I setup the target PBS datastore in PVE I selected encryption ON and it backed up to the PBS. I ran the backup a total of twice; the second time resulted in what SEEMS like it's doubling the amount of disk space taken (and it has the green lock for encryption).

For instance, the total space taken showing on the Summary page of PBS is 210 GB, but in the Content page and expanding the VMs and CTs and seeing the SIZE, it shows the entire disk size (6 TB) twice. That's why it seems as though it is not deduplicating..but you are saying that it actually IS deduplicating, and it's just showing the general size of the VM/CT from which it is backing up..? Thanks again for your clarification.
 
Last edited:
: I have my ZFS pool encrypted on PVE, and when I setup the target PBS datastore in PVE I selected encryption ON and it backed up to the PBS. I ran the backup a total of twice; the second time resulted in what SEEMS like it's doubling the amount of disk space taken (and it has the green lock for encryption).

Did you enabled the encryption after you already did a backup? Then this is expected since the data won't be identical you basically saved it one time unencrypted and one time encrypted.
For instance, the total space taken showing on the Summary page of PBS is 210 GB, but in the Content page and expanding the VMs and CTs and seeing the SIZE, it shows the entire disk size (6 TB) twice. That's why it seems as though it is not deduplicating..but you are saying that it actually IS deduplicating, and it's just showing the general size of the VM/CT from which it is backing up..? Thanks again for your clarification.
Please run a garbage collect job and post the output of "Show log" here:
1757810559595.png
 
Did you enabled the encryption after you already did a backup?
No, I initially setup the target within PVE then Datacenter > Storage > Add, and there are 3 tabs, and after finishing the General tab I selected the Encryption tab, and then I chose to Auto Generate a Client Encryption Key. I then backed up PVE to my target PBS, and then again a few days later. That is when I noticed the same amount of storage in the two backups, effectively doubling the storage taken up. (Not sure if this matters, but when I created the datastore in PBS I chose ZFS for my one HDD)

Here is a snip of how it looks in PBS my datastore's Content:
1757909351764.jpeg

Here is GC log:
Code:
2025-09-14T20:52:30-07:00: starting garbage collection on store backup
2025-09-14T20:52:32-07:00: Access time update check successful, proceeding with GC.
2025-09-14T20:52:32-07:00: Using access time cutoff 1d 5m, minimum access time is 2025-09-14T03:47:30Z
2025-09-14T20:52:32-07:00: Start GC phase1 (mark used chunks)
2025-09-14T20:52:32-07:00: marked 5% (1 of 20 index files)
2025-09-14T20:52:32-07:00: marked 10% (2 of 20 index files)
2025-09-14T20:52:32-07:00: marked 15% (3 of 20 index files)
2025-09-14T20:52:32-07:00: marked 20% (4 of 20 index files)
2025-09-14T20:52:32-07:00: marked 25% (5 of 20 index files)
2025-09-14T20:52:35-07:00: marked 30% (6 of 20 index files)
2025-09-14T20:52:35-07:00: marked 35% (7 of 20 index files)
2025-09-14T20:52:35-07:00: marked 40% (8 of 20 index files)
2025-09-14T20:52:35-07:00: marked 45% (9 of 20 index files)
2025-09-14T20:52:36-07:00: marked 50% (10 of 20 index files)
2025-09-14T20:52:36-07:00: marked 55% (11 of 20 index files)
2025-09-14T20:52:36-07:00: marked 60% (12 of 20 index files)
2025-09-14T20:52:36-07:00: marked 65% (13 of 20 index files)
2025-09-14T20:52:37-07:00: marked 70% (14 of 20 index files)
2025-09-14T20:52:43-07:00: marked 75% (15 of 20 index files)
2025-09-14T20:55:59-07:00: marked 80% (16 of 20 index files)
2025-09-14T20:55:59-07:00: marked 85% (17 of 20 index files)
2025-09-14T20:55:59-07:00: marked 90% (18 of 20 index files)
2025-09-14T20:56:01-07:00: marked 95% (19 of 20 index files)
2025-09-14T20:56:02-07:00: marked 100% (20 of 20 index files)
2025-09-14T20:56:02-07:00: Start GC phase2 (sweep unused chunks)
2025-09-14T20:56:04-07:00: processed 1% (605 chunks)
2025-09-14T20:56:06-07:00: processed 2% (1199 chunks)
2025-09-14T20:56:08-07:00: processed 3% (1792 chunks)
2025-09-14T20:56:10-07:00: processed 4% (2331 chunks)
2025-09-14T20:56:12-07:00: processed 5% (2949 chunks)
2025-09-14T20:56:14-07:00: processed 6% (3512 chunks)
2025-09-14T20:56:17-07:00: processed 7% (4097 chunks)
2025-09-14T20:56:19-07:00: processed 8% (4736 chunks)
2025-09-14T20:56:21-07:00: processed 9% (5298 chunks)
2025-09-14T20:56:23-07:00: processed 10% (5865 chunks)
2025-09-14T20:56:25-07:00: processed 11% (6432 chunks)
2025-09-14T20:56:27-07:00: processed 12% (7024 chunks)
2025-09-14T20:56:29-07:00: processed 13% (7628 chunks)
2025-09-14T20:56:31-07:00: processed 14% (8192 chunks)
2025-09-14T20:56:33-07:00: processed 15% (8755 chunks)
2025-09-14T20:56:35-07:00: processed 16% (9341 chunks)
2025-09-14T20:56:38-07:00: processed 17% (9941 chunks)
2025-09-14T20:56:40-07:00: processed 18% (10543 chunks)
2025-09-14T20:56:42-07:00: processed 19% (11076 chunks)
2025-09-14T20:56:43-07:00: processed 20% (11665 chunks)
2025-09-14T20:56:45-07:00: processed 21% (12252 chunks)
2025-09-14T20:56:48-07:00: processed 22% (12817 chunks)
2025-09-14T20:56:50-07:00: processed 23% (13402 chunks)
2025-09-14T20:56:52-07:00: processed 24% (13980 chunks)
2025-09-14T20:56:54-07:00: processed 25% (14571 chunks)
2025-09-14T20:56:56-07:00: processed 26% (15160 chunks)
2025-09-14T20:56:58-07:00: processed 27% (15742 chunks)
2025-09-14T20:57:00-07:00: processed 28% (16324 chunks)
2025-09-14T20:57:02-07:00: processed 29% (16929 chunks)
2025-09-14T20:57:04-07:00: processed 30% (17486 chunks)
2025-09-14T20:57:06-07:00: processed 31% (18062 chunks)
2025-09-14T20:57:08-07:00: processed 32% (18671 chunks)
2025-09-14T20:57:11-07:00: processed 33% (19273 chunks)
2025-09-14T20:57:13-07:00: processed 34% (19834 chunks)
2025-09-14T20:57:16-07:00: processed 35% (20433 chunks)
2025-09-14T20:57:19-07:00: processed 36% (21034 chunks)
2025-09-14T20:57:23-07:00: processed 37% (21572 chunks)
2025-09-14T20:57:26-07:00: processed 38% (22159 chunks)
2025-09-14T20:57:30-07:00: processed 39% (22754 chunks)
2025-09-14T20:57:33-07:00: processed 40% (23384 chunks)
2025-09-14T20:57:37-07:00: processed 41% (23919 chunks)
2025-09-14T20:57:40-07:00: processed 42% (24503 chunks)
2025-09-14T20:57:43-07:00: processed 43% (25059 chunks)
2025-09-14T20:57:47-07:00: processed 44% (25660 chunks)
2025-09-14T20:57:50-07:00: processed 45% (26274 chunks)
2025-09-14T20:57:53-07:00: processed 46% (26853 chunks)
2025-09-14T20:57:57-07:00: processed 47% (27470 chunks)
2025-09-14T20:58:00-07:00: processed 48% (28073 chunks)
2025-09-14T20:58:03-07:00: processed 49% (28624 chunks)
2025-09-14T20:58:07-07:00: processed 50% (29260 chunks)
2025-09-14T20:58:11-07:00: processed 51% (29878 chunks)
2025-09-14T20:58:14-07:00: processed 52% (30466 chunks)
2025-09-14T20:58:18-07:00: processed 53% (31067 chunks)
2025-09-14T20:58:21-07:00: processed 54% (31641 chunks)
2025-09-14T20:58:25-07:00: processed 55% (32233 chunks)
2025-09-14T20:58:28-07:00: processed 56% (32860 chunks)
2025-09-14T20:58:32-07:00: processed 57% (33447 chunks)
2025-09-14T20:58:36-07:00: processed 58% (34078 chunks)
2025-09-14T20:58:39-07:00: processed 59% (34656 chunks)
2025-09-14T20:58:43-07:00: processed 60% (35279 chunks)
2025-09-14T20:58:46-07:00: processed 61% (35851 chunks)
2025-09-14T20:58:50-07:00: processed 62% (36427 chunks)
2025-09-14T20:58:54-07:00: processed 63% (37015 chunks)
2025-09-14T20:58:57-07:00: processed 64% (37541 chunks)
2025-09-14T20:59:01-07:00: processed 65% (38158 chunks)
2025-09-14T20:59:04-07:00: processed 66% (38733 chunks)
2025-09-14T20:59:08-07:00: processed 67% (39287 chunks)
2025-09-14T20:59:11-07:00: processed 68% (39872 chunks)
2025-09-14T20:59:15-07:00: processed 69% (40489 chunks)
2025-09-14T20:59:20-07:00: processed 70% (41063 chunks)
2025-09-14T20:59:24-07:00: processed 71% (41665 chunks)
2025-09-14T20:59:28-07:00: processed 72% (42257 chunks)
2025-09-14T20:59:31-07:00: processed 73% (42821 chunks)
2025-09-14T20:59:35-07:00: processed 74% (43390 chunks)
2025-09-14T20:59:39-07:00: processed 75% (43983 chunks)
2025-09-14T20:59:43-07:00: processed 76% (44589 chunks)
2025-09-14T20:59:47-07:00: processed 77% (45182 chunks)
2025-09-14T20:59:51-07:00: processed 78% (45781 chunks)
2025-09-14T20:59:55-07:00: processed 79% (46378 chunks)
2025-09-14T20:59:59-07:00: processed 80% (46970 chunks)
2025-09-14T21:00:02-07:00: processed 81% (47550 chunks)
2025-09-14T21:00:06-07:00: processed 82% (48124 chunks)
2025-09-14T21:00:10-07:00: processed 83% (48679 chunks)
2025-09-14T21:00:14-07:00: processed 84% (49270 chunks)
2025-09-14T21:00:18-07:00: processed 85% (49848 chunks)
2025-09-14T21:00:21-07:00: processed 86% (50443 chunks)
2025-09-14T21:00:25-07:00: processed 87% (51055 chunks)
2025-09-14T21:00:29-07:00: processed 88% (51625 chunks)
2025-09-14T21:00:33-07:00: processed 89% (52173 chunks)
2025-09-14T21:00:37-07:00: processed 90% (52742 chunks)
2025-09-14T21:00:40-07:00: processed 91% (53300 chunks)
2025-09-14T21:00:44-07:00: processed 92% (53873 chunks)
2025-09-14T21:00:48-07:00: processed 93% (54453 chunks)
2025-09-14T21:00:52-07:00: processed 94% (54999 chunks)
2025-09-14T21:00:57-07:00: processed 95% (55608 chunks)
2025-09-14T21:01:01-07:00: processed 96% (56192 chunks)
2025-09-14T21:01:06-07:00: processed 97% (56804 chunks)
2025-09-14T21:01:10-07:00: processed 98% (57356 chunks)
2025-09-14T21:01:14-07:00: processed 99% (57955 chunks)
2025-09-14T21:01:19-07:00: Chunk cache: hits 3059039, misses 58560 (hit ratio 98.12%)
2025-09-14T21:01:19-07:00: Removed garbage: 0 B
2025-09-14T21:01:19-07:00: Removed chunks: 0
2025-09-14T21:01:19-07:00: Original data usage: 11.89 TiB
2025-09-14T21:01:19-07:00: On-Disk usage: 194.745 GiB (1.60%)
2025-09-14T21:01:19-07:00: On-Disk chunks: 58561
2025-09-14T21:01:19-07:00: Deduplication factor: 62.52
2025-09-14T21:01:19-07:00: Average chunk size: 3.405 MiB
2025-09-14T21:01:19-07:00: queued notification (id=499d5c84-0ba1-4bed-b7e0-234309fl16a0)
2025-09-14T21:01:19-07:00: TASK OK
 
Last edited:
No, I initially setup the target within PVE then Datacenter > Storage > Add, and there are 3 tabs, and after finishing the General tab I selected the Encryption tab, and then I chose to Auto Generate a Client Encryption Key. I then backed up PVE to my target PBS, and then again a few days later. That is when I noticed the same amount of storage in the two backups, effectively doubling the storage taken up. (Not sure if this matters, but when I created the datastore in PBS I chose ZFS for my one HDD)

You basically saved your data one time encrypted and one time unencrypted, thus in the end saving everything two times. As soon as every unencrypted backup is getting pruned or manually removed you should notice that the storage space occupied by them will be released.

Here is a snip of how it looks in PBS my datastore's Content:

That's the size of the VM/LXC/backup client file backup you did.
To get the amount of deduplication and used storage size you need to look in the datastore summary or the gc log:
1757919334161.png


So my backups use around 323GB on the datastore with a deduplication factor of 324.

In the gc log you will find the exact values including the amount of storage the restoed backup would take:

Code:
2025-09-15T08:54:02+02:00: Removed chunks: 415
2025-09-15T08:54:02+02:00: Original data usage: 94.86 TiB
2025-09-15T08:54:02+02:00: On-Disk usage: 299.263 GiB (0.31%)
2025-09-15T08:54:02+02:00: On-Disk chunks: 266257
2025-09-15T08:54:02+02:00: Deduplication factor: 324.59
2025-09-15T08:54:02+02:00: Average chunk size: 1.151 MiB

So all my backups together would need 95 TB storage if I wanted to restore them.

Code:
...
2025-09-14T21:01:19-07:00: Removed garbage: 0 B
2025-09-14T21:01:19-07:00: Removed chunks: 0
2025-09-14T21:01:19-07:00: Original data usage: 11.89 TiB
2025-09-14T21:01:19-07:00: On-Disk usage: 194.745 GiB (1.60%)
2025-09-14T21:01:19-07:00: On-Disk chunks: 58561
2025-09-14T21:01:19-07:00: Deduplication factor: 62.52
2025-09-14T21:01:19-07:00: Average chunk size: 3.405 MiB
2025-09-14T21:01:19-07:00: queued notification (id=499d5c84-0ba1-4bed-b7e0-234309fl16a0)
2025-09-14T21:01:19-07:00: TASK OK


Your backups use 195 GB of storage space with a deduplication factor of 62. So if you would want to restore all of them you would need 12 TB.

tldnr: Your deduplication seems to work fine, as soon as you remove all unencrypted backups it should improve even more.
 
backed up PVE to my target PBS, and then again a few days later. That is when I noticed the same amount of storage in the two backups, effectively doubling the storage
Run another backup and there will be 3 entries. :)

It's clearer when backing up a VM...all backups of a 150 GB drive are listed as 150 GB even if only 1 GB is actually used on disk, and the VM is off so isn't generating any new blocks on disk. In other words if 149 GB out of the 150 GB are "zeroes" then that can be condensed down to the 1 GB by deduplication.
 
You basically saved your data one time encrypted and one time unencrypted, thus in the end saving everything two times. As soon as every unencrypted backup is getting pruned or manually removed you should notice that the storage space occupied by them will be released.
Ok thanks! But just to be clear and make sure I really understand, you're saying dedup is working, and also the encrypted data is in the ZFS pool on PVE, and the unencrypted data is in PBS? I'm clarifying, because for the ZFS pool on PVE I need to enter the decryption passkey when I reboot the drives. So, isn't that considered "encrypted"..?

Also, you're saying that PBS backs up the decrypted data that is in PVE, and that's why the data that is then saved to the PBS is not encrypted..? (even though it has the green encrypted lock icon..?)

Or do I just have my understanding of it reversed
 
Last edited:
The backup runs against readable data, otherwise the source would be gibberish.

The data is encrypted by the job's configured encryption key, if any, and sent to PBS. PBS then stores the encrypted data chunks.

If two chunks to be stored in PBS are identical then PBS only stores that chunk once.
 
Ok thanks! But just to be clear and make sure I really understand, you're saying dedup is working, and also the encrypted data is in the ZFS pool on PVE, and the unencrypted data is in PBS? I'm clarifying, because for the ZFS pool on PVE I need to enter the decryption passkey when I reboot the drives. So, isn't that considered "encrypted"..?

I'm beginning to suspect that you are trying to troll me *sigh*

Again: Whatever you do on the ZFS layer doesn't matter for PBS. If you encrypt your ZFS datasets they will be encrypted no matter what you do on PBS. And whatever you do on PBS doesn't matter for ZFS (or anything else) on the PVE. The deduplication of PBS only works on the raw data it received from ProxmoxVE or the backup client, it doesn't care at all whether it's encrypted or not. it just looks: "Do I already have the data?" "Oh I have, fine you don't need to upload it again." "Oh I don't know these data, please upload it". That's really all.
You could try for yourself: Create a simple text file with "hello world" as it's raw content. Afterwards create an encrypted version of the file t with gpg or TrueCrypt and open both files in an editor. Are they the same? No, and the same is true for any backups of data where you saved the data's content (e.g. by encrypting it after you didn't encrpyt it before)

Also, you're saying that PBS backs up the decrypted data that is in PVE, and that's why the data that is then saved to the PBS is not encrypted..? (even though it has the green encrypted lock icon..?)

No, see above. I'm sorry but I'm not willing to repeat myself again.
Or do I just have my understanding of it reversed
I'm really not sure for me you look quite confused or like a rather elborated troll. In both cases I have not much interest left to help you.
 
  • Like
Reactions: used1d