Knowledgebase

Overview

Quick Glossary:

• In rsync terms, the SENDER is the source server transferring files via rsync. The RECEIVER is the remote destination server receiving those files. 
• In this article, we refer to the remote SSH destination as "destination" or "ssh destination". Please be sure you take note whether the recommendations apply to the destination or source server. 

Symptoms:

Some users may encounter "Failed" Account Backups with the error below when using SSH (Legacy) destinations:

rsync: [receiver] failed verification -- update discarded (will try again).

After investigation, this issue appears related to a recent upstream rsync regression introduced through Linux distribution package updates and security backports on the remote ssh destination (Receiver) in 3.4.3. Rsync 3.4.4 was released to fix those regressions. Although JetBackup’s bundled rsync binary did not recently change, rsync operates on both the sender and receiver side. As a result, updates to the rsync package on the remote SSH destination server can trigger this behavior.

Latest Status:

2026-06-10 17:00:00 UTC:

rsync 3.4.4 has now been officially released by the upstream rsync project to address regressions introduced in the rsync 3.4.3 security release. Based on our findings, this issue is most heavily dependent on the rsync version running on the receiver, which in JetBackup SSH destination workflows, is the remote SSH destination server.

For affected environments, the now recommended resolution is to update rsync on the remote SSH destination server to rsync 3.4.4 once it is available through your operating system vendor, package repository, or supported manual installation method.

Updating rsync on the JetBackup source server will not resolve this issue if the destination server continues running effected rsync build 3.4.3 or distro backport based on 3.4.3 (example: 3.2.7-1+deb12u5).

Please note that while rsync 3.4.4 is now available upstream, Linux distributions such as Debian, Ubuntu, AlmaLinux, Rocky Linux, CloudLinux, and RHEL may take additional time to publish updated packages or backport the relevant fixes into their supported rsync versions. Administrators should check the package availability for their specific operating system and update the rsync package on the SSH destination when available, or contact their storage destination provider.

Option 1 - Update rsync on the SSH Destination to 3.4.4 (Recommended)

The recommended resolution is to update rsync on the remote SSH destination server to rsync 3.4.4 or to a distribution-provided rsync package that includes the upstream regression fixes from rsync 3.4.4: https://download.samba.org/pub/rsync/NEWS#3.4.4

This should be performed on the receiver/destination side, not on the JetBackup source server.  The reported failed verification -- update discarded behavior is strongly tied to the receiver-side rsync, so the destination-side rsync package should be updated. After updating rsync on the SSH destination, verify the installed version by running the following command directly on the destination server:

rsync --version

Then rerun the affected JetBackup backup job and confirm whether the account backup completes without the following error: failed verification -- update discarded

If rsync 3.4.4 is not yet available from your operating system repositories or storage destination provider, you may either wait for your distribution or storage provider to publish an updated package or continue using the JetBackup mitigation patch listed below as a temporary workaround.

If your storage destination provider has not updated to rsync 3.4.4, please contact them for assistance in updating your storage server. 

Option 2 - Apply the Patch for case #JB5-SSH-60

If rsync 3.4.4 is not yet available on the SSH destination, or if you are unable to update rsync on the destination server at this time, you may apply the JetBackup 5 mitigation patch under internal case #JB5-SSH-60. See below for the patch instructions. 

Earlier updates:

Cause

Several Linux distributions recently backported rsync security and behavioral changes into existing package versions.

Update: The affected rsync versions introduced security fixes that also caused regressions in certain workflows, including use cases utilized by JetBackup. We reported our findings to the rsync development team with Rsync case #928, and the issue has since been acknowledged and addressed in the upstream rsync project under issue #953. While the fix is now available upstream, we cannot provide a timeline for when Linux distributions such as Ubuntu and Debian will package or backport these changes into their supported rsync releases.

In parallel, we are actively working on adjustments to JetBackup 5's SSH Destination implementation to help mitigate the impact of this issue. Because these changes affect core backup functionality, they are being evaluated carefully to ensure that any workaround does not introduce additional regressions or unintended side effects.

Examples include:

• Debian security backports:
  • Debian rsync security update tracker
• Ubuntu rsync package updates:
  • Ubuntu rsync package history

The following rsync package builds have been observed in affected environments:

This issue appears most commonly during incremental or delta-based transfers involving:

• --link-dest incremental backup operations
• Certain file path structures
• Existing delta chains built before the rsync package update

Because JetBackup uses rsync incremental functionality for SSH destinations, these upstream rsync regressions may surface during backup operations.

How do I know if I'm affected?

You aren't affected unless you're seeing "Failed" backups with the failed verification -- update discarded error. The error causes failed account backups for one or more accounts. 

Additionally, if you are using any destination type other than SSH Legacy, you will not be impacted, as these destinations do not use rsync. We have not received any reports of Local Legacy destinations seeing this issue. 

If you're using JetBackup for WordPress, you are not affected because this only impacts JetBackup 5 when using an SSH destination. 

Check the rsync Version

Please note that there are 2 different rsync versions on your server. The first is bundled with your OS distro and may or may not be installed by default, and the 2nd is "jetrsync" bundled with JetBackup, which is installed and set as the default. The rsync binary that JetBackup 5 uses is set in "JB5 > Settings > Binary Locations", and may vary if you've changed from the default jetrsync. 

You can check the local version using:

rsync --version

/usr/local/jetapps/usr/bin/rsync --version

Then, check the rsync version on the destination. This error is heavily dependent on the version of rsync on the destination side, due to backported changes from rsync-3.4.3 in older rsync. 

Option 2 - Apply the Patch for case #JB5-SSH-60 (Not Recommended) 

Our Development Team has prepared a mitigation patch for this issue under internal case #JB5-SSH-60. This patch adjusts JetBackup 5’s SSH destination handling to pass an absolute path to --link-dest during incremental rsync operations. Based on our testing and reviewed reports, this helps mitigate the affected rsync behavior where relative --link-dest paths may trigger failed verification -- update discarded errors during SSH destination backups.

This patch is still undergoing validation before being included in an official JetBackup release. However, it can be applied to affected source servers running JetBackup v5.3.19 or newer (including v5.4.X on ALPHA/EDGE).

1. Before applying the patch, please ensure that no JetBackup tasks are currently running. Restarting the JetBackup daemon will abort active backup, restore, download or cleanup tasks.

2. Then, run the patch script below. This will detect whether v5.3.19 or v5.4.X is installed and install the corresponding patch file for that version. 

Important:
This patch should be applied on the source server where JetBackup 5 is installed, not on the remote SSH destination server.

bash <(curl -LSs https://repo.jetlicense.com/patches/jetbackup5/Issue-SSH-60-Patch.sh)

3. Restart the service with systemctl restart jetbackup5d

Additional Resolution Options (Not Recommended)

If downgrading rsync is not possible or the existing backup chain remains affected, the following recovery methods may help. However, this issue appears to be a regression in rsync - so some of the solutions below have had inconsistent results reported to us. 

Option 3 - Downgrade rsync on the SSH destination (Not recommended)

If you cannot apply the patch above, you may temporarily downgrade rsync on the affected remote SSH destination server to the previous working package version and place the package on hold until the operating system vendor releases a corrected backport or updated package.

This is currently the most consistently successful recovery path reported in affected environments at this time.

apt install rsync=3.2.7-1ubuntu1
apt-mark hold rsync

Downgrading packages should only be performed by administrators comfortable managing OS package versions and understanding the associated security implications.

Option 4: Start a New Backup Chain (Not recommended) 

Create a duplicate backup job and allow JetBackup to generate a fresh backup chain. This avoids reusing previously affected delta data, but only solves the issue in some cases. 

Option 5: Delete the Problematic Snapshot (Not recommended)

On JetBackup v5.3 or later, deleting the affected snapshot using the deleteAccountSnapshots command may allow rsync to rebuild the affected data path during the next backup run.

This depends on which snapshot or delta segment triggered the verification failure.