FEATURE REQUEST: EMC Data Domain integration

[maximilian.lange]

Hello,

I have some Customers with Data Damains in separate fire sections or buildings. We backup the productive VM´s to one DD and copy these files to another with the EMC Features. Thats why we do not see these files in the B&R Console.
Is it possible to implement a control for this in B&R?
Thanks for considering my idea.

Regards Max

[PTide]

Hi and welcome to the community!

I'd suggest you to copy backup files from one DD to another using Backup Copy Job instead of direct replication between DDs because in case of direct replication no health checks are preformed so if any corruption had occurred to your primary backup it would be replicated to another DD. Also Backup Copy Job allows you to manage your copies from VBR console.

Thank you.

[maximilian.lange]

Hi,

sorry but that´s not my preferred solution. Backup Copy Jobs have a really bad scheduling and we want to transfer the data direct between DDs and not over the B&R Server. Also we have better dedup and compression at the DDs as B&R with lower bandwith utilization.

Thanks!

[PTide]

Backup Copy Jobs have a really bad scheduling

Could you please provide more details about your use case so we could try to improve backup copy job scheduling?

and we want to transfer the data direct between DDs and not over the B&R Server.

Backup Copy Job data flow goes from one repository directly to another repository or, in case of DD, the dataflow happens between gateway servers that were specified during repository configuration.

Also we have better dedup and compression at the DDs as B&R with lower bandwith utilization.

Could you share some numbers please?

Please don't get me wrong, I'm not trying to force you to use Backup Copy Job, but I still feel that I have to clarify something:

You copy backups form one DD to another because you want to have a second copy of your backups in case something goes badly wrong with your primary repo and that's a good practice. That can save you from loosing backups in case of S.H.I.G. (smoking hole in the ground) event on your primary repo site. On the other hand inter-DD replication can't help you against primary backup coruption - bad blocks will be replicated to your secondary storage and will render you backup copies useless.

Anyway your feature request has been accepted and we will look into this to see what can be done.

Thank you.

[maximilian.lange]

My use case is, when Backup Job finishes the copy should start and copy the complete new restore point like an backup to tape Job. At this moment when backup copy exceptionally needs longer that 24hours it restart and copy all data anew.

Sorry I meant the gateway servers. In our case is the B&R Server the Gateway Server. It would be better if data flow goes from one DD to another DD.

Unfortunately I did not have any numbers because my customers have not implement both scenarios

Regards Max

[PTide]

May I ask you what kind of backup mode do you use (forever-forward/reverse/forward incremental)?

<...>it restart and copy all data anew.

The backup copy job should resume data transfer during the next sync interval, copying all the blocks needed to build the new restore point. Previous restore point that has not been completed due to sync interval expiration will be left in incomplete state. Is that what is happening or your backup copy job start the whole process from the beginning?

Thank you.

[meilicke]

We have resorted to something similar, when a large VM with a very high change rate would not fit within the offsite backup copy window. For that specific VM, we use DD replication. But as PTide noted, you lose the way the backup copy job is built separately from the backup files, and block validation. To mitigate this risk, we use DD snapshots and validate the backups at the source. You can also setup a job to index the remote backups in Veeam on a daily basis. That will give you visibility in Veeam, but not the health check tools.

Other suggestions, that may or may not work:

WAN Optimization - Riverbed, Silverpeak, etc. We find using Steelheads on a 100Mbps link, direct copy without Veeam WAN Accelerators, gives us good performance, better than the Veeam WAN Accelerators. Even so, DD replication is better. I cannot find my performance testing from last year, but maybe 2x better?

If using v9, that supports Boost 3.0, which allows you to use the Boost agent over the WAN. Maybe this will be faster than Veeam proxies, and fast enough for you. In our case when we selected "automatic" for the DD gateway servers, we saw the Veeam app server moving data from the source DD, to the remote DD, and all the data went through the Veeam app server for all Backup Copy jobs. We didn't run any numbers, but it was faster than Local DD ==> Local Veeam Proxy ==WAN==> Remote Veeam Proxy ==> Remote DD. For us the Steelhead masks the differences, so we go through the proxies now to reduce load on the Veeam server.

Ensure you are following policy. Example: the customer *wants* daily offsite, but their policy only requires weekly. We have had good luck internally setting expectations in this way. Perhaps there are only some VMs that need daily, others are fine with weekly, etc.

If you have just one or two VMs with a high change rate, find out why. In our case they are storing compressed DB backups on disk. We are actively working to get something more friendly in place so we can stop using DD replication.

Get a bigger pipe. Always nice. We have found simple Internet pipes with an IPSEC VPN to be much more economical for backups than MPLS.

Good luck!

Scott

[rreed]

Use DD's built-in replication, the device will readily tell you if it has any trouble replicating. From there, add your replicated folder as a share on the remote device; like backup-rep or whatever you want to call it. Add that as a repository in Veeam and rescan it. Your replicated backups will show up in Imported Disks. I don't think those automagically rescan to stay up to date, at least ours don't, but that's fine, when we need to test restores at our remote sites we just rescan the replicated repositories as step 1. in our recovery plan.

[rreed]

There is a fly in this ointment, however. When you go to select a restore point, a given restore point might show up twice and there's no way to know from which repository you're pulling. I haven't confirmed this has been fixed in v9, I think they were supposed to at some point? I know for sure in previous B&R versions and the current VEB it's still the case. We'll have to look around in B&R v9 to see if having the same backup files in multiple repositories tells you somewhere where the file is located so you can properly pick your onsite backup or offsite backup-rep.

[rreed]

Confirmed it's still there in v9. If you try to select a different restore point from what comes up by default, you'll be present w/ two each of your given VM's restore points. If you want the default most current, just select from either Disk or Disk (imported) from your desired location. Hopefully Veeam will add the source repository or folder somewhere in selecting your restore points.

[foggy]

Confirmed it's still there in v9. If you try to select a different restore point from what comes up by default, you'll be present w/ two each of your given VM's restore points.

Could you please share a screenshot for better clarity?

[rreed]

Love to, but I don't find a way to import/attach a pic on this forum?

[PTide]

Rreed,

Just use any photo hosting of your choice.