Fix JetBackup SSH Destination Rsync Verification Failures

JetBackup 5 SSH (Legacy) destinations can encounter failed verification -- update discarded during an rsync transfer. Treat the backup as failed until its job log and recovery checks establish otherwise. The message alone does not prove which package, file or server caused the problem.

Confirm the affected path

Record the JetBackup release, destination type, failing account, timestamp and full surrounding error. Identify the rsync executable selected in JetBackup’s Binary Locations settings and the rsync package on the receiving SSH destination. The source’s system rsync may differ from JetBackup’s bundled executable.

rsync --version

This read-only command reports the executable found by that shell. Run the applicable executable on each authorized host; it does not prove which binary a different service actually invokes. Also inspect disk/inode capacity, source-file changes during backup, permissions and storage errors rather than assuming every verification failure has the same cause.

Use the current vendor resolution

JetBackup’s current advisory attributes a particular SSH-destination failure to receiver-side rsync regressions, including distribution security backports. It recommends rsync 3.4.4 or a supported distribution package containing the corresponding fixes on the destination. Updating only the source does not fix an affected receiver. Package release suffixes and vendor advisories matter; an older-looking upstream version may contain backported fixes.

If that update is unavailable, ask JetBackup or the storage provider whether mitigation case JB5-SSH-60 applies to the installed release. Its source-side patch has version and task-stoppage requirements. Do not paste a remote script into a privileged shell without inspecting it and confirming vendor support. Do not install an unofficial repository presented as an official operating-system fix.

Protect the existing recovery chain

Do not delete snapshots, downgrade security fixes, disable verification or discard the old chain as a first response. Coordinate any approved change with the administrator, preserving rollback and known-good recovery points. Rerun a controlled affected job, inspect the complete result and test representative restoration before trusting the destination again. A connection test alone does not validate backup contents.

For escalation, provide redacted logs, both package builds, the selected binary paths, destination type, recent updates and storage diagnostics. Never attach SSH private keys, passwords or customer archives.

References: JetBackup’s current advisory and mitigation conditions and upstream rsync issue 928.

Reviewed October 15, 2026. The advisory was checked; no affected JetBackup job, vendor patch or customer recovery was executed.