Discussions specific to the Microsoft Hyper-V hypervisor
Post Reply
Daithi
Enthusiast
Posts: 48
Liked: 1 time
Joined: Oct 16, 2013 9:19 am
Contact:

Bitlooker Time

Post by Daithi » Mar 02, 2016 10:24 am

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

P.Tide
Product Manager
Posts: 5304
Liked: 466 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Bitlooker Time

Post by P.Tide » Mar 02, 2016 10:45 am

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: 48
Liked: 1 time
Joined: Oct 16, 2013 9:19 am
Contact:

Re: Bitlooker Time

Post by Daithi » Mar 02, 2016 11:40 am

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
SVP, Product Management
Posts: 24907
Liked: 3612 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Bitlooker Time

Post by Gostev » Mar 03, 2016 2:21 am

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

P.Tide
Product Manager
Posts: 5304
Liked: 466 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Bitlooker Time

Post by P.Tide » Mar 03, 2016 11:40 am

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: 48
Liked: 1 time
Joined: Oct 16, 2013 9:19 am
Contact:

Re: Bitlooker Time

Post by Daithi » Mar 21, 2016 3:40 pm

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?

P.Tide
Product Manager
Posts: 5304
Liked: 466 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Bitlooker Time

Post by P.Tide » Mar 21, 2016 3:55 pm

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
Expert
Posts: 323
Liked: 72 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: Bitlooker Time

Post by mkaec » Mar 30, 2016 12:39 pm

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.

P.Tide
Product Manager
Posts: 5304
Liked: 466 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Bitlooker Time

Post by P.Tide » Mar 30, 2016 1:29 pm

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
Expert
Posts: 323
Liked: 72 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: Bitlooker Time

Post by mkaec » Mar 30, 2016 1:34 pm

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.

P.Tide
Product Manager
Posts: 5304
Liked: 466 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Bitlooker Time

Post by P.Tide » Mar 30, 2016 3:18 pm

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
Expert
Posts: 323
Liked: 72 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: Bitlooker Time

Post by mkaec » Mar 30, 2016 3:20 pm

OK. Thanks for confirming.

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests