deduplication works on different policies of same client?

[jeorainc]

Hi All,

Platform: NBU applicance 2.6.0.2, master+media server + MSDP

I am confused about deduplication and accelerator. 

Assume I have 2 policies, A and B. Both policy are the same. Policy type VMware, backing up only 1 VM and is the same VM.

Accelerator enabled. To MDSP pool. 

Assume there is a successful full backup done by policy A.

If I now run a manual full backup using policy B, will it reference to the full backup at policy A for deduplication and accelerator?

Another question about san and nbd. Assume I use policy A and performed a successful "nbd" full backup.

If I now enforce policy A to use "san" only, will deduplication and accelerator works as usual?

Please kindly help! thanks a lot! 

[RiaanBadenhorst · Accepted solution]

Q1: If I now run a manual full backup using policy B, will it reference to the full backup at policy A for deduplication and accelerator?

A1: Will it reference to the full backup at policy A

     for deduplication =  Yes

     and accelerator? = No

Q2: If I now enforce policy A to use "san" only, will deduplication and accelerator works as usual?

A2: Yes

[sdo · Accepted solution]

Accelerator is client side and policy name based.  Therefore a plain client accelerator based policy and a VMware accelerator based policy will not use each others discovered file lists.

Deduplication is global within the MSDP pool.  Therefore any data from any client (even the same client) will always de-dupe against each other.  However, blocks being blocks, I would expect that if a client were to be backed-up using plain client and then backed-up again as a VM, then the dedupe might not be as great, but should still be good. 

[jeorainc]

Thank you that's clear.

One more question regarding change of vmdk size.

Assume I have a 4TB vmdk.

I performed a full backup at the size of 4TB.

And then I increase the vmdk size by 1GB to 4097GB.

After that, I perform a differential backup.

1. Will this differential backup behaves as full backup?

2. Will accelerator and deduplication works as usual?

Now I am having an issue that after increasing the vmdk size by 1GB. both san and nbd backup is very slow... 

I decided to rebuild a new policy and perform a full backup again for this VM, but I still want the answers of above questions :p

[RiaanBadenhorst]

I have not come across this scenario so not certain. But remember, we get the information and the data from VDDK so if it decides everything changed because of the increase then we can't do much about (i think )

[sdo]

I would have thought that increasing a VMDK is a bit like increasing the size of a LUN from a storage array presented to a physical server.  i.e. the guest VM just sees a bigger LUN - and so, the guest OS then has to use file system tools to increase the size of the volume or partitions within the LUN - so, from a VMware VADP VDDK API perspective I would have expected not much size increase of backup nor much speed change for a BLIB/CBT aware backup - because the extended space should not yet be referenced by the virtualised file system within the guest OS.

Your symptoms lead me to think that your VM is of an OS type/version, or is using a file system type/version... either of which does not support both mapped and BLIB level VM backups.  True?

[jeorainc]

my client to backup is a pure VM with VMDK. No RDM.

One more thing I'd like to ask,

As guided by Symatnec TSE they asked me to disable the CBT of VM.

Will that affect VMware backup performance? Should we disable this CBT feature of VM?

the VM consist of a 60GB vmdk as C:\, and 4*4TB vmdk as data drives.

[sdo]

I'd get the Symantec TSE to justify his statement - i.e. why disable CBT ?  Yes, disabling it will have an impact - a positive benefit for the normal running of the VM because vSphere ESX will no longer have to maintain a meta-base tracking which blocks are used - but a negative impact on backups (i.e. longer duration) because more data will have to be read and moved - and more will have to be de-duped - and because the backup takes longer, then the snapshot is held open for longer, and so more pending writes will accumulate within the snapshot, and so when the backup completes then there will be more data to be 'consolidated' (writes merged) from the snapshot back in to the actual VMDK files - and so more CPU and more IO at the vSphere ESX and storage array levels.

We can't have it all.  There's always a trade off.

4 * 4TB is a big VM - and big a VM usually = big headache for backup admins.