Veeam Deleted File Blocks (BitLooker) cons ?

[CaptainPistache]

Hello,

Simple question, is there any disadvantage or risk to use the "Exclude deleted file blocks" option in Veeam ?
And specifically when activating the option after the backup jobs have been used for a while ?

Thanks a lot.

Cheers,
Captain

[foggy]

Hi Captain, actually this is a recommended setting, so no disadvantages. If you switch it in the middle of the backup chain, it will take effect starting from the next job session.

[Gostev]

Additional data processing always means additional risk versus simply making a copy of an image, because more code means more places where data corruption bugs may be present. But for example, the market has eventually learnt to trust even deduplication, which has much more complex data processing algorithms behind it.

The checkbox is there because some people prefer to let any new functionality to stabilize for a few years before using it. BitLooker has been around for a while now, so it's quite mature and thus risks associated with using it are minimal... I mean, any tech that has been in use by hundreds of thousands of users for a few years is very unlikely to still contain unknown bugs

[CaptainPistache]

Thanks a lot to both of you for your answers !

Cheers,
Captain

[masonit]

Hi

Yesterday we enabled "exclude deleted file blocks" on a bunch of older backup jobs were we still use reverse incremental. I thought this would only add benefits but today we see some jobs running really slow. Some repositories says they are overloaded. I have looked at thread below but still don't understand why there would be higher load with "exclude deleted file blocks". "Exclude swap file blocks" was enabled before we enabled "exclude deleted file blocks". We don't use file exclusions.

microsoft-hyper-v-f25/bitlooker-time-t3 ... ml#p183584

\Masonit

[Gostev]

Hi

With reversed incremental backup, you should have ran an active full after enabling "exclude deleted file blocks" for two reasons:

1. Without an active full, your VBK will not reduce in size anyway (it will just mark a bunch of blocks as unused).

2. First incremental run will produce a huge VRB due to all the deleted blocks "changing" from whatever content they had to zeroed, with their former content squeezed out of VBK into VRB. And because reversed incremental backup is very I/O intensive (3 IOs per each changed block) as well as the amount of changes in your scenario, this will cause high load on backup repositories for extended time.

Thanks!

[masonit]

Thanks!

1. But all blocks marked as unused. Can't that space be used for new data without increasing the size of the VBK file?

2. Tonight backups ran fine. Maybe it was only the first run that was heavy? But what do you suggest. Should we use "exclude deleted file blocks" on jobs with reversed incremental? Right now it looks more like we use alot more repository space than we used before activating "exclude deleted file blocks". Not really what I was expecting.

*Update* Think I got it now. That extra spaced used for the first big VRB file will be freed up after that VRB file is removed from retention?

\Masonit

[Gostev]

1. Yes, it will be reused for new data as your VMs grow in size and need this extra space. But depending on how much disk space was released in VBK by enabling this option, they may never grow big enough to occupy all already preallocated VBK space, meaning that this repository space will be simply wasted. This is why active full is a good idea after enabling this option.

2. Correct. And this is also why it makes sense to do an active full instead (the only difference is that you will just have a huge VBK instead of a huge VRB, but either way they will go away based on retention).