VMware backup issue [61:1005] Got unexpected close from OB2BAR Backup DA on backuphost1

1 Likes
over 1 year ago

Symptoms

the problem appears mostly for incremental backup

[Critical] From: VEPALIB_VMWARE@backuphost1 ""  Time: 04/15/2020 03:49:32 AM

               Backup of object failed.

                              Name: vm1

                              Path: /dc/vm1

                              InstanceUUID: xx.xxx.xx.xx

 

[Major] From: BSM@cellmanager "backup1"  Time: 4/15/2020 3:49:33 AM

[61:1005]            Got unexpected close from OB2BAR Backup DA on backuphost1

Diagnosis

Whenever we got “expected close”, we should think about the software’s crash. In this case, vepa_bar is the crashed one.

 

The reason for the crash is various. However, we would focus on the resources supporting the backup host.

I notice the failed session report is incremental backup which sometime stress CPU and other resources to calculate the CBT.

 

However, in some special cases, there are things that we cannot fully understand where problem comes from, DP or not DP.

So we need to isolating things out, step by step.

Solution

From DP end, there are several tuning parameters for this module. Probably the most appropriate one in omnirc is:

OB2_VEAGENT_DISK_CONCURRENCY

# OB2_VEAGENT_DISK_CONCURRENCY=<vm disk concurrency>

#     Default: 10

#     This setting is used to calculate a safe number of disk threads to be started

#     in parallel. This is the total number of disks that can be run in parallel at any

#     given time. The disks selected are from any of the running VM threads.

#     Number of disk threads = VM disk concurrency - 10% (but at least one thread)

#     Each of the disk thread creates the connection to the vCenter apart from the running

#     VM thread. Also take into account that each vSphere Client opens a connection too.

 

By lowering the disk threads, like =5 on both backup hosts, problem gone away.

Labels:

Support Tip
Comment List
Anonymous
Related Discussions
Recommended