Are there any caveats on using "Metadata Detection Mode"?

[GrafZahl]

Hi there,
I am running PBS to backup some CTs and VMs running ob PVE. As the storage has over 1.5TB and is placed on classical, rotaing hdds a backup-jobs runs nearly 6 hours. I used the default settings for the backup-job and used "Default" as "Change detection mode".
Now I tried "Metadata" as change detection mode and the backup was (with the second run) extremely faster.

This brings me to the question if using "Metadata" as change detection mode is save or if there are any caveats that could kill my backups? As this seems to be much better, from the perspection of speed, I wonder if it could be a loss not reading all blocks.

Can you give me an hint on that? Thanks a lot!

 

[Chris]

Hi,

This brings me to the question if using "Metadata" as change detection mode is save or if there are any caveats that could kill my backups? As this seems to be much better, from the perspection of speed, I wonder if it could be a loss not reading all blocks.

there is no danger in "killing" your backup. But there are some caveats:

• Files might be reused instead of re-encoded if the file data changed, but the metadata did not. E.g. if a file was edited, but the file size remained the same and the mtime of the file was restored after the change, the change detection mode will see this as unchanged file and reuse it. That is why we also provide the change-detection-mode data, which always reads all files again.
• The change detection mode might reuse existing chunks partially, leading to some padding. E.g. a file contained within a single chunk vanished in-between backup runs, but the chunk is reused. This additional padding can become wasted space if the previous snapshot actually referencing that file is pruned. This also has implication for sensitive data, please see the notes in https://pbs.proxmox.com/docs/maintenance.html#pruning. The client tired to minimize this by aligning chunk boundaries with file boundaries when possible and re-encode smaller files in some situations although they might not have changed.
• Restore times can be slower, if there is additional padding which is downloaded by the client in any cases because part of a chunk.