11-07-2016 08:35 AM
After moving some clients (vmware) to another policy, my msdp size growed up by 8 TO....
I don't understand what is "global dedup"...
Does anyone can explain that?
11-07-2016 09:36 AM - edited 11-07-2016 09:42 AM
MSDP are islands of dedupe. Thus, the 52xx and 53xx range of NetBackup Appliances are each islands of dedupe. But they are "global" in the sense that any backup sent to an MSDP storage unit is a candidate for dedupe by that island of MSDP no matter what the source.
The term global dedupe is sometimes misused these days. There used to be a range of appliances, the 50x0 NetBackup Deduplication Appliance range which could be configured for global dedupe, but these have been discontinued. These 50x0 Appliances were also sometimes referred to as PDDO Appliances.
It sounds to me as if you have caused a change in target - and so perhaps you have multiple MSDP storage units, and you have now caused the backups to be written to another different MSDP storage unit.
Those of us with multiple MSDP storage units will usually be quite careful in our configuration of storage unit groups - so that backups always go to a specific MSDP storage unit, but so that we can also quickly cause multiple backups to go to a different storage unit, if the need should arise, without having to change multiple backup policies or multiple schedule or even multiple SLPs - but we are always mindful of perhaps your experience and do our best to minimise what has hapenned in your case.
I assume your have only NetBackup Appliances? Or do you have other vendor deduplication devices instead, or as well as?
What model are your Symantec/Veritas applliances? 50xx or 52xx or 53xx ?
How many MSDP storage units do you have?
11-08-2016 12:40 AM
I have 2 5230 appliances, and 2 msdp on windows servers.
I have backed up on the same stu, the only change is the vmware policy name, and the accelerator unchecked.
11-08-2016 05:32 AM
take a look at this scrennshot from opscenter
You can see the job size of one of my client that i moved policy.
11-08-2016 06:22 AM
It seems more than just policy was changed.
Without knowing what was in Backup Selection before and after the change, there is no way of telling why more data is getting backed up by the new policy.
Maybe browse backup of 3 Nov?
And then compare with browsing of 5 Nov backup?
11-08-2016 06:39 AM
Another idea, i'm using a backup proxy with client dedup enabled, so the backup was not made by the medi server directly.
So, new policy, new fingerprint...
11-11-2016 04:42 AM
AFAIK, fingerprint is based on the actual content of the backup data blocks, not on policy name, nor schedule name, nor SLP name, nor client name, nor VM name, nor file name, no folder name, nor volume name.
11-14-2016 01:13 AM
After a support call:
It's working as inteded, when you move a client to another policy, you create a new image on the msdp.
The dedup is not global.
So for exemple the same client in 10 policy make 10 times the data on msdp...
11-14-2016 04:06 AM
After some test on my side:
1 client and dedicated msdp, mutiple policy for this client, source and target dedup,with and without accelerator,
full and inc schedule.
I was not able to reproduce the problem....
I'll reopen the case.