we migrated our environment from the VADP method to the new VBA method after upgrading to the latest version of Networker 8.1.1 and upgraded our DD620 to 126.96.36.199.
We used to have a full-inc-inc... setup but with the new method it's always a full. That's not a real problem, backup is very fast to the primary DD and we're getting a high dedup ratio but cloning is taking a real long time now. Looks like it's trying to clone the full backup again and again so going through the whole full backup and comparing the hashes with the remote DD. Is there any way to speed up this process and do the requirements of the line between the two DD's change with this VBA method?
we're using cloning from Networker using 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.
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 ?
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
Are you using the default Schedule?
This is a known Limitation with VBA / NVP Appliance / DD setup where in during Cloning it doesnt sync the Incremental data which is equivalent to Every day Full data been Cloned from Primary DD to Secondary DD (Only For cloning)
Will Provide / Post more information Soon
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.
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 188.8.131.52 GA code to give it a test run to check if this is really solving this problem.