Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE
Respected Contributor.. rsamora Respected Contributor..
Respected Contributor..
449 views

Improve Large VM Backup

Jump to solution

DP 10.20 on Windows Cell Managers

I have two VMs, similar in size, on different cells, Full backups run once a week, incrementals on the other 6 days, and here's how the Full backups run:

ServerA - 4 disks
3.2 TB - takes 31 hours
524 GB - takes 4 hours
419 GB - takes 3.5 hours
104 GB - takes 1 hour

ServerB - 3 disks
3.2 TB - Takes 68 hours
524 GB - Takes 7 hours
104 GB - Takes 2.5 hours

 

Questions:

1. How can I determine why one backup is taking twice as long as the other.  I understand there are variables like how many backups are running at the same time and cell manager untilization, but that shouldn't account for twice the time.
2. What can I do to speedup a VM backup?
3. My bosses want to see all backups complete within a 24 hour windows, obviously I've missed the mark with these two backups.  To make matters worse, one 5 TB disk has been added to one server and TWO 5 TB disks have been added to the other, the slow one at that.  Is there a better way to do this than a straight forward VM backup.

In the Filesystem world, I have a couple of servers that I've broken up into subfolders so that I can assign more drives and I've reduced backup times dramatically.  It's a manual process but it works.  I don't see any comparable option with a VM backup.  These are Windows VMs but the folder structure is such that it would be a nightmare to try to carve it up into small enough sections to make a difference.

Thanks in advance,
Randy

 

0 Likes
1 Solution

Accepted Solutions
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Improve Large VM Backup

Jump to solution

Hi @rsamora,

When looking at both session reports I can see the following items that need to be checked:

  1. The backup is performed using Transport method: NBDSSL. This is the worst option available. Try to configure SAN (if the backup proxy is a physical) or HotAdd (if the backup proxy is a VM). If both can't be used, force the backup to use NBD. If you need to use NBD backup data comes from the ESXi service console network which might be 1GbE or worse!
  2. Both backups are performed to a StoreOnce via CoFC and the backup proxy is also the Media Agent which is good! Make sure that the backup proxy has enough (fast) CPU cores and RAM while the backup is performed.
  3. There seems to be a minimal change rate in the backup according to dedupe stats, Make sure the VMs are st least VM hardware version 4 and CBT is used during the backup. Incremental or differential backups would make a big difference for you.

Regards,
Sebastian Koehler

---
Please use the Like button below, if you find this post useful.
5 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Improve Large VM Backup

Jump to solution
Hi Randy,

Most important for VM backup is the backup mode (SAN, NBD or HotAdd), connectivity between and the performance of the backup host and Media Agent and of course the backup device you’re using. I would like to see the session report of both sites to comment on your configuration and the backup specifications.

Once we’re using the right systems and ensure they are not overloaded we can look at omnirc tuning to squeeze out even more data.

Regards,
Sebastian Koehler
---
Please use the Like button below, if you find this post useful.
0 Likes
Respected Contributor.. rsamora Respected Contributor..
Respected Contributor..

Re: Improve Large VM Backup

Jump to solution

I apologize for the late response, I have been out of the office since last Wednesday.  Thank you for the response and here you go . . .

Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Improve Large VM Backup

Jump to solution

Hi @rsamora,

When looking at both session reports I can see the following items that need to be checked:

  1. The backup is performed using Transport method: NBDSSL. This is the worst option available. Try to configure SAN (if the backup proxy is a physical) or HotAdd (if the backup proxy is a VM). If both can't be used, force the backup to use NBD. If you need to use NBD backup data comes from the ESXi service console network which might be 1GbE or worse!
  2. Both backups are performed to a StoreOnce via CoFC and the backup proxy is also the Media Agent which is good! Make sure that the backup proxy has enough (fast) CPU cores and RAM while the backup is performed.
  3. There seems to be a minimal change rate in the backup according to dedupe stats, Make sure the VMs are st least VM hardware version 4 and CBT is used during the backup. Incremental or differential backups would make a big difference for you.

Regards,
Sebastian Koehler

---
Please use the Like button below, if you find this post useful.
Respected Contributor.. rsamora Respected Contributor..
Respected Contributor..

Re: Improve Large VM Backup

Jump to solution

VERY good information, thank you so much.  This gives me a lot to play with.


Thanks again,

Randy

Honored Contributor.. Gamut Honored Contributor..
Honored Contributor..

Re: Improve Large VM Backup

Jump to solution

@Sebastian.Koehler wrote:

Hi @rsamora,

When looking at both session reports I can see the following items that need to be checked:

  1. The backup is performed using Transport method: NBDSSL. This is the worst option available. Try to configure SAN (if the backup proxy is a physical) or HotAdd (if the backup proxy is a VM). If both can't be used, force the backup to use NBD. If you need to use NBD backup data comes from the ESXi service console network which might be 1GbE or worse!

Just to enhance the answer: NBDSSL is worst speed wise. If you value security on your Ethernet, don't use NBD at all as all VM data is sent in clear "text" from ESX to Data Protector.

And to partly counter this answer: Ethernet may be faster, depending on your setup. Teaming/bonding 10 Gbit Ethernet NIC's can ofcourse outperform a 8 Gbit or slower SAN infrastructure. As a rule of thumb, Sebastian is right though: SAN typically outperforms Ethernet.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.