It may take longer during full backup but the slowdown should not be significant.Should a backup take longer when "exclude deleted file blocks" is enabled?
Does it happen during full backup? Do you have CBT enabled? Please give us some numbers for comparison.It seems to slow down to a crawl.
That does not look like an expected behaviour. What's your bottleneck statistics with BitLooker enabled?Disabling the option makes the backup much quicker and as expected?
That explains a lot.We perform a reverse incremental every night.
PTide wrote: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.
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.Without BitLooker, I'd expect the deleted 1 GB would end up in the full backup.
Correct.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.
Users browsing this forum: No registered users and 1 guest