v9: BitLooker Zeroing

Availability for the Always-On Enterprise

v9: BitLooker Zeroing

Veeam Logoby NTmatter » Thu Jan 14, 2016 12:26 pm

I was just reading through the BitLooker documentation. It states that BitLooker will "zero out dirty blocks on the VM guest OS before it copies VM data to the target location." Does this actually issue any I/O to the production storage, or is it cleverly ignoring/substituting the dirty blocks as it sends them to the repository?

The situation is that I'm about to switch this on for a well-churned multi-terabyte VM, prior to an Active Full backup. I'd like to figure out if I'm about to zero out a large chunk of data, extending the backup window while consuming ginormous amounts of bandwidth, giving my users a bad day.

To recap, I'm asking if BitLooker will:
a) Write zeroes to the VM's disks (and thereby production storage), snapshot the VM, then compress the blocks during transport.
b) Snapshot the VM, write zeroes to an ephemeral snapshot (which would also wind up on production storage), then compress the blocks during transport.
c) Snapshot the VM, skip (or do inline replacement of) the changed dirty blocks during transport.
d) Something completely different?

Thanks for any clarification that you can provide!
NTmatter
Influencer
 
Posts: 11
Liked: 4 times
Joined: Fri Mar 14, 2014 11:16 am
Full Name: Thomas Johnson

Re: v9: BitLooker Zeroing

Veeam Logoby PTide » Thu Jan 14, 2016 2:05 pm

Hi,

c) Snapshot the VM, skip (or do inline replacement of) the changed dirty blocks during transport.

This. Dirty blocks are just skipped and don't get transported anywhere. Blocks are skipped based on data from MFT. So there is almost no impact on production storage (only small amount of read operations to obtain MFT data).

Thank you.
PTide
Veeam Software
 
Posts: 3134
Liked: 262 times
Joined: Tue May 19, 2015 1:46 pm

Re: v9: BitLooker Zeroing

Veeam Logoby Gostev » Thu Jan 14, 2016 4:50 pm

Correct, and you should see the results (amount of data read and transferred, and smaller backup file size) instantly - as long as you have a lot of deleted data on virtual disks, which is however not so usual for server workloads.

But, keep in mind that during the incremental runs, Veeam will only process changed blocks, which are thus unlikely to belong to deleted files (otherwise, why would they be changing). So, material impact from this feature can only be seen during full backups.
Gostev
Veeam Software
 
Posts: 21503
Liked: 2379 times
Joined: Sun Jan 01, 2006 1:01 am
Location: Baar, Switzerland

Re: v9: BitLooker Zeroing

Veeam Logoby NTmatter » Mon Jan 18, 2016 9:49 am

Hooray! Sounds like it should be a big win for our environment. Would you be able to clarify this statement a little further:
So, material impact from this feature can only be seen during full backups.


Do you mean should only be seen? Or is BitLooker mutually exclusive to Changed Block Tracking?

As some background, we actually have a fair bit of churn from regular user activity (Photoshop + Atomic Save), DFS Replication staging, and Windows' Deduplication. All of this shuffling results in huge amounts of dirty blocks.
NTmatter
Influencer
 
Posts: 11
Liked: 4 times
Joined: Fri Mar 14, 2014 11:16 am
Full Name: Thomas Johnson

Re: v9: BitLooker Zeroing

Veeam Logoby Gostev » Mon Jan 18, 2016 3:01 pm

Yes, they are mutually exclusive, simply because CBT already does not "pick up" blocks belonging to deleted files. Remember that deleting a file does not change contents of any of its blocks, they remain on disk as is. Instead, only the file allocation table is updated to mark the file as deleted. This is exactly what makes undelete possible ;)
Gostev
Veeam Software
 
Posts: 21503
Liked: 2379 times
Joined: Sun Jan 01, 2006 1:01 am
Location: Baar, Switzerland

Re: v9: BitLooker Zeroing

Veeam Logoby mkaec » Mon Jan 18, 2016 5:47 pm

Hyper-V generation 2 VMs support SCSI unmap and I think VSS already causes those blocks to be skipped during backup. I'm thinking this is a great option to enable for generation 1 VMs, but won't have a big impact on generation 2 VMs (on Hyper-V).

However, I'm a bit nervous about turning it on. What is the risk of MFT corruption in the VM causing incorrect blocks to be skipped?
mkaec
Expert
 
Posts: 185
Liked: 48 times
Joined: Thu Jul 16, 2015 1:31 pm
Full Name: Marc K

Re: v9: BitLooker Zeroing

Veeam Logoby dellock6 » Mon Jan 18, 2016 6:30 pm 3 people like this post

I think that if you have MFT corruption, the skipped blocks is not the worst problem you have...
Luca Dell'Oca
EMEA Cloud Architect @ Veeam Software

@dellock6
http://www.virtualtothecore.com
vExpert 2011-2012-2013-2014-2015-2016
Veeam VMCE #1
dellock6
Veeam Software
 
Posts: 5111
Liked: 1355 times
Joined: Sun Jul 26, 2009 3:39 pm
Location: Varese, Italy
Full Name: Luca Dell'Oca

Re: v9: BitLooker Zeroing

Veeam Logoby mkaec » Mon Jan 18, 2016 6:58 pm

Not necessarily. I've seen chkdsk /f report, with regularity, that it is fixing minor things. I don't know how much, or if at all, that kind of stuff would impact bitlooker. But, if there were more serious MFT problems, would trying to make use of a backup that was damaged by MFT corruption make matters worse? Is MFT corruption detected during backup or could backups silently go on for a while before it is noticed?

I'm not trying to be negative. I am sure all this was considered during development and I'm just interested in the details.
mkaec
Expert
 
Posts: 185
Liked: 48 times
Joined: Thu Jul 16, 2015 1:31 pm
Full Name: Marc K

Re: v9: BitLooker Zeroing

Veeam Logoby Gostev » Mon Jan 18, 2016 8:12 pm

Since we will not be able to parse corrupted MFT, BitLooker processing will simply be skipped.
Gostev
Veeam Software
 
Posts: 21503
Liked: 2379 times
Joined: Sun Jan 01, 2006 1:01 am
Location: Baar, Switzerland

Re: v9: BitLooker Zeroing

Veeam Logoby NTmatter » Wed Jan 20, 2016 8:08 am

Gostev wrote:they are mutually exclusive


Apologies for the nitpicking - I'm still a bit fuzzy on this. I'm looking at the sequence of Full Backup > create file > delete file > Incremental Backup. The final MFT will have no entry for the churned blocks from the short-lived file, but the dirtied blocks will be copied into the incremental backup?

It's sounding like BitLooker is only used for Full Backups, not for Incrementals?

Thanks for all the help on this one :)
NTmatter
Influencer
 
Posts: 11
Liked: 4 times
Joined: Fri Mar 14, 2014 11:16 am
Full Name: Thomas Johnson

Re: v9: BitLooker Zeroing

Veeam Logoby PTide » Wed Jan 20, 2016 10:33 am 1 person likes this post

The final MFT will have no entry for the churned blocks from the short-lived file
And that's why those blocks won't be included into incremental backup with BitLooker enabled. If you disable BitLooker then CBT will pick up dirty blocks even if the files were deleted. In next run those blocks, unless you change them again, won't be copied since they are already present in previous backup. With both options enabled you will get all your changed blocks in your incremental except for those that do not belong to existing files (based on MFT data)
PTide
Veeam Software
 
Posts: 3134
Liked: 262 times
Joined: Tue May 19, 2015 1:46 pm

Re: v9: BitLooker Zeroing

Veeam Logoby mkaec » Wed Jan 20, 2016 1:19 pm 3 people like this post

NTmatter wrote:Apologies for the nitpicking - I'm still a bit fuzzy on this.

Let's say a backup runs and backs up a 100 MB file. Then the next day you delete the file. Because the blocks were already backed up, the next incremental will not back it up again. This is CBT at work.

Now let's say you create a 100 MB file and then delete it the same day. Normally, it would get backed up, but Bitlooker will cause it to be skipped.
mkaec
Expert
 
Posts: 185
Liked: 48 times
Joined: Thu Jul 16, 2015 1:31 pm
Full Name: Marc K

Re: v9: BitLooker Zeroing

Veeam Logoby NTmatter » Wed Jan 20, 2016 5:02 pm

Thanks, PTide and mkaec!

Crystal clear now. BitLooker + CBT + High Churn = Minimal Bloat.
NTmatter
Influencer
 
Posts: 11
Liked: 4 times
Joined: Fri Mar 14, 2014 11:16 am
Full Name: Thomas Johnson

[MERGED]: Understanding BitLooker

Veeam Logoby larry » Fri Feb 19, 2016 2:09 pm

Trying to understand what Veeam is doing with BitLooker
In the manual I read “Veeam Backup & Replication accesses the MFT file on the VM guest OS to identify deleted file blocks, and zeros out these blocks.” Does this mean Veeam is wiping my VM deleted area with zeros like a secure delete? If it does, then the first run I should expect a lot of SAN traffic on the next mirror job for that disk. I just need the first run at night if this is the case.
larry
Expert
 
Posts: 380
Liked: 89 times
Joined: Wed Mar 24, 2010 5:47 pm
Full Name: Larry Walker

Re: v9: BitLooker Zeroing

Veeam Logoby chrisdearden » Fri Feb 19, 2016 2:51 pm

no - we just write zero in the backup for it.
chrisdearden
Expert
 
Posts: 1529
Liked: 225 times
Joined: Wed Jul 21, 2010 9:47 am
Full Name: Chris Dearden

Next

Return to Veeam Backup & Replication



Who is online

Users browsing this forum: benj00, BradI, Google [Bot] and 93 guests