vCenter File-based backups fail intermittently with "ERROR: rc: 2, stderr: b'curl: (2) Failure establishing ssh session: -43, Failed getting banner\n'"
search cancel

vCenter File-based backups fail intermittently with "ERROR: rc: 2, stderr: b'curl: (2) Failure establishing ssh session: -43, Failed getting banner\n'"

book

Article ID: 441870

calendar_today

Updated On:

Products

VMware vCenter Server 8.0

Issue/Introduction

The issue typically occurs when multiple vCenter Server instances are scheduled to back up to the same SFTP target server at the same time.

You see messages indicating a communication failure during sub-component backups (frequently during LotusBackup or VCDBBackup processing), followed by a broken pipe error:

/var/log/vmware/applmgmt/backup.log

ERROR: rc: 2, stderr: b'curl: (2) Failure establishing ssh session: -43, Failed getting banner\n' ERROR: Failed to write file to server /usr/bin/tar: -: Cannot write: Broken pipe util.Common.BackupRestoreError: Failed to backup Lotus DB

Environment

  • VMware vCenter Server 8.X

Cause

This issue occurs due to concurrency limits on the target SFTP server, specifically the OpenSSH MaxStartups parameter.

When a vCenter Server file-based backup initializes, it splits the internal data into multiple architectural components (such as VCDB, VTSDB, Lotus, and StellarDB) and streams them concurrently to minimize the duration of database snapshots. According to official guidelines, each vCenter Server requires a minimum of 10 simultaneous connections to the backup target.

The MaxStartups parameter on Linux-based SFTP targets controls the number of simultaneous unauthenticated connection requests allowed. Connections are considered unauthenticated during the initial SSH handshake and key exchange protocol.

If multiple vCenter Servers attempt to start their backups simultaneously (e.g., scheduled at exactly midnight), they create a massive burst of concurrent SSH initialization requests. If the default OpenSSH threshold (10:30:100) is exceeded, the SFTP server randomly drops incoming handshakes before the authentication banner can be processed, leading to a Failed getting banner error in vCenter.

Resolution

To resolve this issue, the MaxStartups parameter on the target SFTP server must be configured to accommodate the total cumulative simultaneous connection requests from all vCenter Servers.

Procedure to Modify the SFTP Server

  1. Log into the destination SFTP Server via SSH or console as root or an administrator with sudo privileges.

  2. Open the OpenSSH daemon configuration file using a text editor (such as vi or nano):

    sudo nano /etc/ssh/sshd_config
    
  3. Locate the MaxStartups directive. If it is commented out with a #, remove the #.

  4. Modify the first value of the triad to match your calculated infrastructure requirement while leaving the default scaling behavior intact. For an environment with 5 vCenters, update it to:

    MaxStartups 50:30:100
    
  5. Save and close the file.

  6. Restart the SSH service to apply the configuration changes:

    • Ubuntu/Debian: sudo systemctl restart ssh

    • RHEL/CentOS/SLES: sudo systemctl restart sshd


Workaround

If modifying the configuration of the SFTP target server is not permissible, stagger the schedules of the file-based backups in the vCenter Appliance Management Interface (VAMI) so that no two vCenter Server instances initiate their backup windows at the same time. Allow a buffer of at least 30 to 60 minutes between schedules depending on your database sizes.