Availability for the Always-On Enterprise
lp@albersdruck.de
Enthusiast
Posts: 81
Liked: 32 times
Joined: Mar 25, 2013 7:37 pm
Full Name: Lars Pisanec
Contact:

Re: v9: BitLooker Zeroing

Post by lp@albersdruck.de » Mar 14, 2016 12:24 am

With Bitlooker enabled, if I activate shadow copies on a VM disk ("previous versions"), will Veeam backup the blocks of files that were deleted but still exist as a shadow copy?

PTide
Veeam Software
Posts: 4247
Liked: 349 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: v9: BitLooker Zeroing

Post by PTide » Mar 14, 2016 10:33 am

Hi,
With Bitlooker enabled, if I activate shadow copies on a VM disk ("previous versions"), will Veeam backup the blocks of files that were deleted but still exist as a shadow copy?
Datablocks that are included in a shadow copy are treated just as regular datablocks so if shadow copy session occurs between backup sessions all new blocks will go to the incremental backup.

Thank you.

ober72
Service Provider
Posts: 347
Liked: 44 times
Joined: Jan 24, 2014 4:10 pm
Full Name: Geoff Burke
Location: CANADA
Contact:

Re: v9: BitLooker Zeroing

Post by ober72 » Mar 15, 2016 11:34 am

Gostev wrote: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.
In the case of an upgrade from Veeam 8 to Veeam 9 and then turning on this feature with existing jobs it will though have an immediate effect on the next incremental right?

thanks
Geoff Burke
Veeam Certified Architect

PTide
Veeam Software
Posts: 4247
Liked: 349 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: v9: BitLooker Zeroing

Post by PTide » Mar 15, 2016 12:07 pm

will though have an immediate effect on the next incremental right?
Only if you've changed and deleted files between incremental runs. If only change or deletion occurred between incremental sessions then BitLooker will give no impact.

Thank you.

pauliem
Enthusiast
Posts: 26
Liked: 3 times
Joined: Oct 28, 2010 11:31 am
Contact:

Re: v9: BitLooker Zeroing

Post by pauliem » Mar 15, 2016 12:13 pm 2 people like this post

I just ran a full backup against a VM that hosts a lot of files and has a high churn rate. The size of the backup dropped from 1.3Tb to 730Gb. Very impressive.

ober72
Service Provider
Posts: 347
Liked: 44 times
Joined: Jan 24, 2014 4:10 pm
Full Name: Geoff Burke
Location: CANADA
Contact:

Re: v9: BitLooker Zeroing

Post by ober72 » Mar 15, 2016 5:41 pm

Would it make sense then in some circumstances to run active fulls to get the full space savings?

thanks
Geoff Burke
Veeam Certified Architect

skrause
Expert
Posts: 355
Liked: 62 times
Joined: Dec 08, 2014 2:58 pm
Full Name: Steve Krause
Contact:

Re: v9: BitLooker Zeroing

Post by skrause » Mar 15, 2016 7:39 pm

If you want to get the best space savings, using sdelete or some other method to write zeroes in all the free space and then running an active full will usually be your best solution to shrink your backup size.

Bitlooker is really nice for situations where there is high churn on the server (2012R2 servers with Deduplication enabled for example) so that you don't need to do the zero-out stuff as often (or at all).
Steve Krause
Veeam Certified Architect

mkaec
Expert
Posts: 259
Liked: 55 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: v9: BitLooker Zeroing

Post by mkaec » Mar 15, 2016 7:47 pm 1 person likes this post

I don't think there would be much benefit to running SDelete. That's the point of BitLooker in that it knows to exclude the non-zeroed deleted files.

And I don't think there is a benefit to running an active full. BitLooker works fine at skipping deleted files in future backups even if previous backups did include the deleted files.

Now if you are backing up to a deduplicating device, changing the BitLooker setting may cause the next active full to not dedup as well as it would have. That's something to keep in mind.

PTide
Veeam Software
Posts: 4247
Liked: 349 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: v9: BitLooker Zeroing

Post by PTide » Mar 16, 2016 10:06 am

Now if you are backing up to a deduplicating device, changing the BitLooker setting may cause the next active full to not dedup as well as it would have. That's something to keep in mind.
I'd say that enabling BitLooker will leave less stuff for appliance to dedupe :) - zeroes will be eliminated from backup by Veeam before they'll make it to appliance.

Also please keep in mind that in some cases you might get confusing results with BitLooker enabled for reverse incremental chains.

Thank you.

mkaec
Expert
Posts: 259
Liked: 55 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: v9: BitLooker Zeroing

Post by mkaec » Mar 16, 2016 12:49 pm 1 person likes this post

PTide wrote:I'd say that enabling BitLooker will leave less stuff for appliance to dedupe :) - zeroes will be eliminated from backup by Veeam before they'll make it to appliance.
That's true. But, it also changes the block arrangement. The matching algorithms may have a more difficult time matching up to the data already in the repository. I have tried this with one volume so far and the subsequent active full only deduped 2:1 instead of the more typical 10:1.

Before BitLooker - Veeam: 1.8 TB; Appliance: 100 GB
After BitLooker - Veeam: 1.6 TB; Appliance: 780 GB
Second Active Full After BitLooker - Veeam: 1.6 TB; Appliance 142 GB

Now a sample size of 1 is really small and I did have Windows dedup enabled on the volume. So, YMMV. I'm planning to turn BitLooker on some more volumes in the future. I'll report back when I've done it on one that does not have dedup running.

PTide
Veeam Software
Posts: 4247
Liked: 349 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: v9: BitLooker Zeroing

Post by PTide » Mar 16, 2016 2:41 pm

First of all - I've read my previous post one more time and I have to say that this:
zeroes will be eliminated from backup by Veeam before they'll make it to appliance.
supposed to be this:
deleted files will be eliminated from backup by Veeam before they'll make it to appliance.
Sorry for confusion.
Before BitLooker - Veeam: 1.8 TB; Appliance: 100 GB
After BitLooker - Veeam: 1.6 TB; Appliance: 780 GB
Second Active Full After BitLooker - Veeam: 1.6 TB; Appliance 142 GB
Yes, there is some impact on a dedupe ratio if there were no BitLooker option enabled before. However, after a while, your dedupe appliance will get filled with a "bitlookered" blocks of data thus dedupe ratio will become better. As a sidenote I'd like to mention that deduplicating storage is generally not a good choice for primary backup storage.

So I'm looking forward to hear about the results of a new test from you.

Thank you!

hyvokar
Service Provider
Posts: 304
Liked: 18 times
Joined: Nov 21, 2014 10:05 pm
Contact:

Re: v9: BitLooker Zeroing

Post by hyvokar » Mar 29, 2016 5:56 pm

Gostev wrote: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.
Hi! This actually explains why bitlooker isnt working as expected for me. By not using bitlooker on incremental runs, it does not apply on data changed by windows data deduplication optimization jobs. Is there any change, bitlooker could be enabled for incremental runs?
Bed?! Beds for sleepy people! Lets get a kebab and go to a disco!
MS MCSA, MCITP, MCTS, MCP
VMWare VCP5-DCV
Veeam VMCE

mkaec
Expert
Posts: 259
Liked: 55 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: v9: BitLooker Zeroing

Post by mkaec » Mar 29, 2016 6:07 pm

BitLooker is active during incremental backups. I think the text you quoted is just trying to communicate that full backups are more likely to show a more dramatic difference.

hyvokar
Service Provider
Posts: 304
Liked: 18 times
Joined: Nov 21, 2014 10:05 pm
Contact:

Re: v9: BitLooker Zeroing

Post by hyvokar » Mar 29, 2016 7:05 pm

Hmmh... My problem is, that after a full optimization on a windows 2012r2 fileserver (4th saturday, each month) my backup size (transferred data) bumps up by 150-200GB. On every other saturday (after normal optimization), backup size is 70-80GB higher than normal. On a normal day, backup size is between 10-20GB.

So can someone confirm, should bitlooker work with windows dedupe and forever reverse incremental backups ?


E: I've ugraded from v8, and only thing I changed was to check bitlooker checkbox for the job. Do I need to run active full or something like that?
Bed?! Beds for sleepy people! Lets get a kebab and go to a disco!
MS MCSA, MCITP, MCTS, MCP
VMWare VCP5-DCV
Veeam VMCE

mkaec
Expert
Posts: 259
Liked: 55 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: v9: BitLooker Zeroing

Post by mkaec » Mar 29, 2016 7:44 pm

I've also seen this with Windows dedup. I don't think there's really any way around it. If you look at the size of a deduped file, you'll actually see a really small "size on disk" value. The actual file data is stored in 1GB files in System Volume Information\Dedup\ChuknStore\<GUID>\Data. I think the incremental numbers you are seeing are related to garbage collection. When a file is deleted, its contents are left in the related CCC file. Then at some point in the future, Windows clears out the old data from the CCC file. My guess is that it creates a new CCC file with just the still-valid data and deletes the old one. But, I'm not sure of what the exact implementation is. Veeam will see the this CCC activity, rightly so, as changed blocks and back them up in the incremental.

I actually think Windows dedup and block level backup don't mix all that well. Windows dedup just causes extra changed blocks due to how it works.

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 23 guests