Bitlooker Time

[Daithi]

Hi folks,

Should a backup take longer when "exclude deleted file blocks" is enabled? It seems to slow down to a crawl. Disabling the option makes the backup much quicker and as expected?

Thanks

[PTide]

Hi,

Should a backup take longer when "exclude deleted file blocks" is enabled?

It may take longer during full backup but the slowdown should not be significant.

It seems to slow down to a crawl.

Does it happen during full backup? Do you have CBT enabled? Please give us some numbers for comparison.

Disabling the option makes the backup much quicker and as expected?

That does not look like an expected behaviour. What's your bottleneck statistics with BitLooker enabled?

Thank you.

[Daithi]

We perform a reverse incremental every night. Last Active Full was done two weeks ago. We have CBT enabled.
I'll do some investigation once I've a "clean" backup done.

Just wanted to check if it did seem a strange at first glance.

[Gostev]

Yes, backup will take longer when "exclude deleted file blocks" is enabled.

Here are some processing overhead numbers from our testing for file exclusions functionality, which has a comparable processing overhead:

Files to exclude: 10,000
Extra processing time: 8 sec
Extra RAM consumption by data mover: 50 MB

Files to exclude: 100,000
Extra processing time: 2 min
Extra RAM consumption by data mover: 400 MB

Files to exclude: 1,000,000
Extra processing time: 25 min
Extra RAM consumption by data mover: 1.4 GB

[PTide]

We perform a reverse incremental every night.

That explains a lot.

Scenario A: Consider that you have a 1Gb file that has been deleted not long before reverse increment. CBT is enabled, Bitlooker is not enabled:
CBT reports that almost nothing has changed in that file as it still exists on a block level though it's deleted in MFT. So that 1Gb will not be put into .vrb rollback file.

Scenario B: Now consider almost the same situation except that BitLooker is enabled:
CBT reports that almost nothing has changed in that file as it still exists on a block level though it's deleted in MFT. Now BitLooker reports that according to MFT table data the file has been deleted so we need to include that file into .vrb rollback. This is how we get extra 1Gb of data in the restore point on your target repository.

Did you perform a massive file deletion prior to backup session?

Also, do you have any file exclusions enabled by a chance?

Thank you.

[Daithi]

Thanks. That provides some clarity.

We have enabled MS Deduplication on three of our file servers. How does dedup work with reverse incrementals and bitlooker?

[PTide]

How does dedup work with reverse incrementals and bitlooker?

Please take a look at he discussion that has started from this post.

Thank you.

[mkaec]

Scenario B: Now consider almost the same situation except that BitLooker is enabled:
CBT reports that almost nothing has changed in that file as it still exists on a block level though it's deleted in MFT. Now BitLooker reports that according to MFT table data the file has been deleted so we need to include that file into .vrb rollback. This is how we get extra 1Gb of data in the restore point on your target repository.

If the 1GB is included into the .vrb rollback file, is it removed from the full backup at the same time. That way it repository space usage would be net zero. If not, then it would seem like BitLooker could be counter-productive in some scenarios.

[PTide]

If deleted file's blocks are included into the .vrb then the space in the full backup will be marked as free and can be reused during next backup session.

[mkaec]

OK. So then what if a 1GB file were both created and then deleted before the next incremental?

Without BitLooker, I'd expect the deleted 1 GB would end up in the full backup.

With BitLooker, I'd expect that the deleted 1 GB would be completely ignored and not go into the full backup or the .vrb rollback file.

[PTide]

Without BitLooker, I'd expect the deleted 1 GB would end up in the full backup.

Assume that 30% of your 1Gb file has occupied blocks that were previously zeroes. After file deletion and reverse increment those 30% will go to .vrb as sparse blocks (almost zero space needed) and will be written into .vbk. The other 70% of blocks will be put into the .vrb and will consume space because their values has changed since last increment.

With BitLooker, I'd expect that the deleted 1 GB would be completely ignored and not go into the full backup or the .vrb rollback file.

Correct.

[mkaec]

OK. Thanks for confirming.