How does PBS handle reassigned container volumes?

[crash]

I currently have a container that has an additional volume for persistent data storage, which has about 80G of data on it. This container and the additional volume are backed up by PBS.

mp1: local-zfs:subvol-100-disk-1,mp=/opt,backup=1,size=100G

I am planning on replacing this container with a new one and reassigning the additional volume to the new container, as described here.

pct move-volume 100 mp1 --target-vmid 200 --target-volume mp1

My question is how will PBS handle this reassignment when backing up the new container? Will it see the new VMID and blindly copy everything over? Or will it somehow realize that the data between vmid 100 and 200 are almost entirely the same? If it's the former, is there a way around this?

Thanks.

 

[fba]

PBS uses deduplication for storing backups. All data is stored in chunks. Making a backup, hashes of new chunks are compared to hashes of existing chunks. Only chunks with a not-yet-stored hash are transfered and stored on PBS.
Therefore no extra data copying.

 

[crash]

can confirm that is exactly how it worked

 

[fabian]

that's not 100% correct - there's two ways chunks can be detected as duplicate, either by the client or by the server.

when creating a backup, the client only knows about the chunks referenced by the previous snapshot in the same group, and can therefor only deduplicate against those.

in the case the deduplication is not between previous snapshot and currently created snapshot, but between backup groups (like when changing VMID), the chunk will still have to be transferred to the PBS host, but it will be recognized as duplicate and discarded there (server-side deduplication), and not take up additional space server-side afterwards.