This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Virtual Standby to ESXI are slow

Appliance: DL4300

Software Version: RapidRecovery 6.1.2.115

ESXI Version: 6.0

ESXI Server Spec: Dell R730x, 24 15k SAS Drives in RAID 6 - Adaptive Read Ahead - Write Back, 64GB RAM, Dual Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz

Problem: Exports from RR to ESXI run below 10MB/s on a 10Gb/s network. Many of our standby's are in the TB per day range, meaning most take approx 20-30 hours to complete. During this time backups of that agent do not take place, leaving the server vulnerable.

 

Troubleshooting taken with Support:

 - All software and hardware updates completed

 - Direct 10Gb/s fibre between Core and ESXI

 - Pausing all other tasks on the Core and restarting the server

 - Change RAID policy to Adaptive Read Ahead and Write Back

 

Performing an export of an agentless backup last night seemed to run in the 100MB/s+ range, however after checking the logs this morning it dropped back down to 18MB/s after an hour.

 

Any help is appreciated, and even a comment to say you are experiencing the same and info about your setup will assist.

 

James

Parents
  • Hi Phuffers,

    Many thanks for your response, there is a lot to take away from it.

    We finally got an official response from Quest yesterday afternoon after three weeks of troubleshooting, the issue is caused by fragmentation of the file system used in the repository. Unfortunately there is currently no way to resolve this other than to delete the repository and start again, which is obviously not a viable option. If space is available the archive feature can be used to export the recovery points, and then import them again after the rebuild. However, given how slow exports are, archiving 17+ TB of data from the repository would likely take weeks.

    It's surprising that this issue has not been made public by Quest despite knowing about it as we can't be the only people with large daily exports that cannot complete in a satisfactory amount of time. I understand from the support request that a tool to de-fragment the repository will be available in the next release some time next year, however this has left us having to invest further capital into another solution for our DR, be that an additional appliance to hand solely virtual standby or another solution (VEEAM).

    It's a shame really as aside from this issue AppAssure, and now RapidRecovery, has been an amazing appliance that workswww.quest.com/.../ very well.
Reply
  • Hi Phuffers,

    Many thanks for your response, there is a lot to take away from it.

    We finally got an official response from Quest yesterday afternoon after three weeks of troubleshooting, the issue is caused by fragmentation of the file system used in the repository. Unfortunately there is currently no way to resolve this other than to delete the repository and start again, which is obviously not a viable option. If space is available the archive feature can be used to export the recovery points, and then import them again after the rebuild. However, given how slow exports are, archiving 17+ TB of data from the repository would likely take weeks.

    It's surprising that this issue has not been made public by Quest despite knowing about it as we can't be the only people with large daily exports that cannot complete in a satisfactory amount of time. I understand from the support request that a tool to de-fragment the repository will be available in the next release some time next year, however this has left us having to invest further capital into another solution for our DR, be that an additional appliance to hand solely virtual standby or another solution (VEEAM).

    It's a shame really as aside from this issue AppAssure, and now RapidRecovery, has been an amazing appliance that workswww.quest.com/.../ very well.
Children
No Data