Veeam 8.0 restore time issues with DD4200

[$username]

Hi All,

We're running a DD4200 with Veeam 8 and have noted long restore times whether we're running file level restores or full VM restores.

As an example we're currently trying to restore a 2.8GB file from the guest and are getting 54KB/s.

We are using dedupe and compression on the DD and are just wondering how others approach restores in these situations?

We're currently investigating either building a white box or something from someone like iXSystems.

[foggy]

If you could give us more details about your setup, it would be easier to judge. Anyway, restore performance issues were reported previously, so you can search the forums for other similar topics. Also, v9 had some certain improvements in this area, so I'd recommend to consider upgrading.

Btw, what kind of compression do you mean, the one configured in the job settings?

[$username]

So the setup around this specific restore scenario is that we have our B&R server running on our vSphere environment housed inside a C7000 with a mix of BL460c-G7 and G8 blades configured with either dual Xeon X5670 or E5-2650 v2 depending on the generation. We're using forward incremental with synthetic fulls created weekly with active fulls monthly.

We have our proxy running on a DL360G9 with dual Xeon E5-2650 v3 and 40GB of RAM.

The proxy is connected to the B&R via 1Gb Ethernet with the connection to the production storage (VNX5300) and backup storage over 8Gb FC.

For the job specific settings compression is set to none with storage optimization being set to Local target (16TB+), no encryption.

Dedupe and compression is being done on the Data Domain side, we're using DDBoost for backups.

Backup times we have no problem with, it's just the re-hydration of the data that appears to be the issue.

We have plans on upgrading to v9.

[jackgarvey]

Good Luck! Data Domain is for a long term repository. We have been fighting this issue for over a year. Version 9 does improve restore speed, in the storage settings it lets you backup individual servers instead of a whole group in a job. They each have their own file. No matter what you use to restore or backup, the data Domain is always the bottleneck for rehydration. We are in a sinking ship here as our whole backup infrastructure is based upon the Data Domain, and now we have to look up an alternative for DR.

[phillbl]

i also have 4 DD4200 that we backup to, our infrastructure is based on c7000. i agree with the comment above, DD should not be used as primary restore storage. if you were to lose a SAN and you needed to restore a lot of vms then it would be a real issue. i am in that same boat but but when we raised this originally it was not flagged as an issue. well after testing i can assure you it is. i used version we originally put version 8 in and are now on version 9.

what i would say is that you should be getting better restore times than that. we get between 25 and 35mb throughput when restoring. in other places where i did not use DD i was getting 80 to 120 so its a big difference. the only difference that i see that you have is we use virtual proxy servers with virtual DD gateways. like this https://helpcenter.veeam.com/backup/vsp ... c_hiw.html

as i said above, my worry is if we lost a SAN we would be in real trouble restoring but to do a few its performs ok. my next task is to look at implementing a landing zone of fast disks in front of the DD and holding 5/7 days of vms and then copy the rest off to the DD for long term retention. also in the next release of DD coming in sept you will see cloud connect, if off site backups is on you list of things to do it looks pretty cool.

another option depending on how invested in DD you are is exagrid. i have not used them but they look pretty good. they have a landing zone built in to the appliance.