Host-based backup of Microsoft Hyper-V VMs.
Post Reply
Daithi
Enthusiast
Posts: 78
Liked: 3 times
Joined: Oct 16, 2013 9:19 am
Contact:

Bitlooker Time

Post by 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
Product Manager
Posts: 6408
Liked: 724 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Bitlooker Time

Post by 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
Enthusiast
Posts: 78
Liked: 3 times
Joined: Oct 16, 2013 9:19 am
Contact:

Re: Bitlooker Time

Post by 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
Chief Product Officer
Posts: 31456
Liked: 6647 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Bitlooker Time

Post by 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
Product Manager
Posts: 6408
Liked: 724 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Bitlooker Time

Post by 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
Enthusiast
Posts: 78
Liked: 3 times
Joined: Oct 16, 2013 9:19 am
Contact:

Re: Bitlooker Time

Post by 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
Product Manager
Posts: 6408
Liked: 724 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Bitlooker Time

Post by 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
Veteran
Posts: 462
Liked: 133 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: Bitlooker Time

Post by mkaec »

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.
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
Product Manager
Posts: 6408
Liked: 724 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Bitlooker Time

Post by 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
Veteran
Posts: 462
Liked: 133 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: Bitlooker Time

Post by 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
Product Manager
Posts: 6408
Liked: 724 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Bitlooker Time

Post by 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
Veteran
Posts: 462
Liked: 133 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: Bitlooker Time

Post by mkaec »

OK. Thanks for confirming.
Post Reply

Who is online

Users browsing this forum: No registered users and 19 guests