VBA-DD-Cloning

Hi DaGrin,

           Is the clone based on  Clone based replication (CBR) feature of DD or a normal cloning process ?

Hello DaGrin,

Could you please provide more input,

Regarding cloning is this done with a policy in the the "VMware protection policy" within NetWorker ?  If not , why ?

You mention it takes "long time" how much longer compaired to VADP?

After upgrading from VADP to VBA you still use 'full every day' schedule?  One nice feature in VBA is the Avamar way of thinking "VMware incrementall forever" scedule is included with VBA with best partice to take a fullbackup of the VMware image every 42nd day and INC between.    What is the reason to backup 'full every day' other then realy nice de-dup ratios?

I have a test enviroment using the same setup as you (only difference is INC every day not Full every day)  as an example we cloned with DDboost to clonepool  156 GB in 4minutes.

Do you have the same infrasturcture between VBA server and Networker/DD  as you had in  VADP + NetWorker + DD ?

we're using cloning from Networker using DD-BOOST.

VBA=>DD (boost)

DD=>DD  (boost)

We had a look and looks like the VBA client is making one big backup file, that it's copying internally on the DD using fastcopy and then Networker is trying to clone this file using DD Boost file replication.

So looks like we end up with one big file that needs to be cloned every day.

I'ts done with the "vmware protection policy" via the VBA. It's only the cloning that's taking up a long time.

We're using the default schedule with this policy so it's using CBT to only get the changed blocks from vmware.

I think the issue is the rebuild of a full by the VBA on the DD. Our cloning used to be only the incremental data and full in the weekend but looks like it's cloneing a full every day now.

Setup is exactly the same, no changes in the setup between the VADP and VBA setup.

Where the red line starts to go straight up, that's where we start to use VBA

Yes, default schedule.

And that's exactly what we see, cloning taking up a long time compared the previous incremental clone.

We found of selves in the same situation with what seems to be a similar setup. I also found it a bit surprising, and asked advice from EMC support. They replied back that the behaviour was to be expected and as per design.

I did not get a proper explanation, but I came to think of it as the Networker server had to read the data from the DD , acting as a Networker client, before sending it to the DD clone device. (The source DD must recreate all the data, and send it to the Networker server who then use DD boost to ship duped data  to the clone DD device. This is not as optimal as when the VBA is reading directly from the source disks (that in addition have change block tracking enable)

Anyhow,  due to the bad performance and the urge to be less dependant on one single VBA node, we decided to reconfigure our Networker setup so that we instead of backup+clone (clone to offsite DD) are running two separate backup jobs using two separate VBA nodes that are pointing to two separate DD systems.

VBA1- -> DD1

VBA2 --> DD2

As the backup is so fast (we back up about 17 TB to a DD640 in about 160 minutes) and puts so little strain to the VMware hosts and network, we are now running the backup twice a day instead of only once. In this way we not only have a faster and more robust backup setup than we used to, the last backup is never older than 12 hours, compared to the 24 hours we had previously.

Rgds

Harald

That sounds like a good work-around.

I was in contact with EMC yesterday and looks like there is some special team looking into this EBR/DD "clone" issue.

Looks like they make some changes in DD OS 5.5:

Synthetic Backup-Aware Replication:

This optimization reduces the time taken to finish replication for backups created by

DD Boost virtual synthesis (Avamar, NetWorker file system backups, NetBackup

Optimized synthetics, etc) or Oracle Incremental Merge using NFS.

Asked the 5.5.0.4 GA code to give it a test run to check if this is really solving this problem.

DDOS 5.5.0.4 is not GA - it is DA as we speak. 

See previous comments.  There seems to "fix" in DDOS 5.5, but I'm not 100% sure if it applies to this (as I'm not sure if virtual synthesis is the key here).  If we assume yes, I guess this comes in DDOS 5.5 and NW 8.2 combo (it might be just DDOS 5.5 actually) so we are talking about GA in start of Q3 for DDOS? (just a guess)

I'm having the exact same issue:

• Backup  to the primary data domain is 27 mins for 23GB of new data.
• Clone to the secondary data domain should also only be 23GB, but instead it clones the entire full data set (4718GB) and takes 7.5 hours.

Nightmare.

No fix yet?

This is from the Release Notes of Data Domain DDOS 5.5.1.4

https://support.emc.com/docu56989_Data-Domain-Operating-System-5.5.1.4-Release-Notes---Directed-Availability.pdf?languag…

NetWorker users should note that the optimization done for synthetic backup-aware replication will only be effective for file system backups using virtual synthetics. VMware backups performed by the Virtual Backup Appliance (VBA) will not see any replication performance benefit

We are having the exact same issue here.  DD 5.5.1.4 NW 8.2.0.6  I am think of setting up 2 different jobs with 2 different VBAs as well.  Did anyone ever get resolution tot his?

Stan

Hello,

Is this issue fixed in recent releases? I am facing the same issue cloning jobs for the VBA taking lots of time.

Pankaj