Bitlooker creates large incremental backups

[Steve_za]

Case ID: 01684674
After upgrading to v9 and enabling bitlooker, the active full is much smaller (was 900gb, now 500gb) but the next incremental is huge (300gb) when it was previously very small (5gb to 10gb). The following incrementals are back to normal size
This could have something to do with Server 2012R2 deduplication being enabled, as it doesn't seem to happening to other 2012R2 servers without dedup enabled.

Thanks

[Shestakov]

Hello Steve,
Do you observe the behavior for all jobs or it`s an individual case?
Did you perform any unusual activity, like defragmentation, copy/delete big files etc, in the day between the first two job runs?
Thanks!

[Shestakov]

We have reviewed the logs with QA engineers and it looks like bitlooker is not the case here, since all 300 GB of changes happened in the single .vmdk
So the most likely reason here is just some new data

[Steve_za]

Hi Shestakov
It is incredibly unlikely that it was changes, this is a file server, and the changes were between the active full on the Friday night, and the incremental on the Saturday night. The business was closed during this time, so there should have been no changes. If you look at the previous weeks, before the upgrade to v9, the full was much larger, about 300gb, but the following day incremental was only around 10gb
To answer your other questions, it is only for this server, but this server is the only one with 2012r2 deduplication enabled.
No There were no operations performed between the 2 jobs

Thanks
Steve

[Shestakov]

Taking that into consideration, indeed dedupication looks like the reason here.
Here is a related topic about dedupe device and bitlooker.
Thanks!

[foggy]

Check whether some sort of Windows deduplication activity was performed between the job runs (weekly garbage collection, f.e.). It is also worth to mention that without BitLooker that increment would have been even larger.

[Steve_za]

OK so the issue didn't repeat this weekend, so it doesn't look like bitlooker is the culprit.

Thanks

[Shestakov]

Thanks for updating.
Did you also have deduplication task running this week?

[Steve_za]

2012R2 dedup runs an 'incremental' dedup every night

[Shestakov]

So probably dedupe did a lot of work that time, so the backup increment became significant.
Let`s observe it for a longer time. Cheers.

[mkaec]

Windows Server dedup is great, but the garbage collection routine can periodically cause the size of Veeam incremental backups to spike. I've set the "Deduplicate files older than" setting to 60 days on our servers to try to minimize the amount of churn in the dedup file store.