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). Simultaneously, a fix for that regression requires a newer Linux Kernel to be installed on the local server (Sender) to fully work. 

We are happy to announce that the jetrsync package has been updated to version 3.4.3 and released to all tiers with JetBackup v5.3.19.2 and v5.4.0.3. Although this issue was confirmed as an upstream rsync regression, we now have a JetBackup 5 mitigation patch available that adjusts SSH destination handling to use absolute --link-dest paths instead of relative paths, bypassing the problematic relative path behavior in affected rsync versions.

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.

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.1 in older rsync. 

Debian / Ubuntu

Run:

rsync --version
apt list -a rsync

AlmaLinux / Rocky Linux / CloudLinux / RHEL

Run:

rsync --version
dnf history rsync

Option 1 - Apply the Patch for case #JB5-SSH-60 (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 2 - Downgrade rsync on the SSH destination 

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.

Example Ubuntu Downgrade

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 3: Start a New Backup Chain

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 4: Delete the Problematic Snapshot

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.

JetBackup Status

JetBackup itself did not recently update the bundled rsync binary associated with these reports. However, because rsync transfer operations involve both the source and destination systems, updates applied to the destination server's rsync package may still trigger this behavior.

JetBackup is actively reviewing the integration of updated rsync builds under the internal case:JB5-Base-2530

We will continue monitoring upstream rsync fixes and Linux distribution package updates as they become available.