Diskeeper V-locity 2 effects on Block Level Change

The product that I’m reviewing in this article is Diskeeper’s V-locity 2 product, which can be found here. This will not be a post about how much faster a fragment free drive will make your VM, instead this is about what effects this product has on the number of blocks that change in a VM. Why do you care? Well if you use a backup technology like Veeam, or anything else that uses CBT it makes a huge difference.

This post was started in February, now its the middle of June…funny how time flies. It should be noted that although I started testing in February I wanted to recheck the results because I didn’t feel that the way I was testing was proper. This time I created a Windows 2008 R2 VM, put the page file on to a second drive and activated Windows. Then I created a Veeam Backup of the systems, I excluded the drive with the swap file on it to minimize the amount of change blocks due to the swap file. It should be noted that I had not yet installed v-Locity 2 on the one VM yet, so the Veeam backup size of the two VM’s are identical. Also the backup job is scheduled to run every 12 hours on both machines.

Phase 1: Auto Defrag turned off

After installing v-Locity 2 on the one VM and booting up the other, I made sure to uncheck the “automatic defragmentation” box while installing. Basically V-Locity 2 has two ways to optimize your disk… intelligent writing of new data … and second… defragmenting the data that is already on the disk. During this first stage I installed some Windows 2008 Roles on both of the virtual machines and just let them run for a couple of days. The results were pretty much right on to what I expected: The Veeam backup files of the VM with V-Locity installed is almost exactly the same as the the backup files from the VM without V-Locity.

(Click to enlarge)

So without auto defragmentation turned on I see no reason why you couldn’t use this product and still maintain good replication and backup sizes, as it doesn’t look like it causes too much extra block movement. Again … this article isn’t about how much actual improvement you will get with the inteligent write feature alone… but the reporting from V-Locity seems to think its helping.

Phase 2: Auto Defrag turned on

As with the last section, the results of turning automatic defrags back on was pretty much spot on to what I figured. You can pretty much tell exactly when the defrag process ran as the size of the Veeam backup file on the V-Locity VM is MUCH higher then the one without. (Again remember any change that was preformed on one VM I replicated the steps on to the other VM). Check out these results… several times the V-Locity VM is a few gigabytes larger then its sibling.

Recommendations

So my recommendation for users of the Disk Keeper V-Locity 2 product, who also leverage change block tracking to make backups smaller and faster, is to turn OFF automatic defragmentation. To do this click on the Properties button on the V-Locity 2 console and select the drives in your server and click on the auto defrag button on the left, then uncheck the box on the right. Also you will notice that there is a boot time defrag setting too. Make sure that is off as well unless you can accomidate a larger amount CBT data when the Vm is rebooted.

Share This Post

5 Responses to "Diskeeper V-locity 2 effects on Block Level Change"

  1. Thanks so much. Not sure why I never thought about diskeeper changing blocks and making backups longer due to cbt. (im using the classic ver)

    quick question:

    Are you finding the pagefile to really add data to your veeam backup? It seems if you are using a dedup appliance like your exagrid it wouldnt be that much.

    Also how are you dealing with instant recovery or restores in Veeam when the machine you are brining back has no page file.

    thanks

  2. I would like to here about veeam instant revocery or booting windows without the pagefile also.

    Or did you just do this as a test to exclude the page file. Do you usually back a vm including its page filep?

  3. It depends… if the client wants to replicate the VM offsite alot of times we will push the page file to a different drive and then exclude that drive from the Veeam Replication job… this will cut down on the size of the data that will get replicated. However if the client is just backing up the VM and space isn’t an issue we will usually leave it alone just for simplicity and easy of use for the client.

  4. Thanks for testing this. You just saved me a world of pain. I was getting very poor dedupe of VMs AFTER installing V-locity 3 with auto defrag enabled. I was scratching my head cause I could tell the changed blocks where greater then they should have been and data wasnt growing that fast across my datacenter but I think you just gave me the answer as to why!

Leave a Reply