Overview
When updating JetBackup, the update process may fail before the JetBackup package is updated if yum or dnf cannot refresh metadata from one of the enabled repositories on the server.
In this case, the failure is not caused by the JetBackup repository itself. The package manager refreshes enabled repositories before resolving the update, so any broken third party repository can prevent the JetBackup update from continuing.
Common examples include expired, deprecated, unreachable, or misconfigured repositories such as PostgreSQL, EPEL, CloudLinux, Imunify360, Node.js, Docker, or other third party package sources.
Example Error
Error: Failed to download metadata for repo "example-repo":
Cannot download repomd.xml:
Cannot download repodata/repomd.xml:
All mirrors were tried
Or:
Errors during downloading metadata for repository "example-repo":
Status code: 410 for https://example.com/repo/repodata/repomd.xml
In this example, the problematic repository is:
example-repo
Cause
yum and dnf refresh repository metadata before installing or updating packages.
Even when updating only JetBackup, the package manager may still check enabled repositories unless they are explicitly disabled for the update command. If any enabled repository has invalid metadata, missing repomd.xml, expired mirror URLs, or an unreachable endpoint, the entire update can fail.
Step 1: Review the JetApps Update Log
JetApps update logs are stored under:
/usr/local/jetapps/var/log/jetapps/
List recent logs:
ls -lah /usr/local/jetapps/var/log/jetapps/ | tail
Search recent logs for repository metadata errors:
grep -Ei "Failed to download metadata|Errors during downloading metadata|Cannot download repomd.xml|All mirrors were tried|Status code" /usr/local/jetapps/var/log/jetapps/*.log | tail -100
Look for the repository ID in the error.
Example:
Failed to download metadata for repo "example-repo"
The problematic repository is:
example-repo
Step 2: Confirm the Repository Is Enabled
Check enabled repositories:
yum repolist enabled
Or, on systems using dnf:
dnf repolist enabled
Search for the problematic repository:
yum repolist enabled | grep -i "example-repo"
Or:
dnf repolist enabled | grep -i "example-repo"
You can also locate the repository file:
grep -R "^\[example-repo\]" /etc/yum.repos.d/
Step 3: Confirm the JetBackup Package Is Available
Use the following format:
yum --showduplicates list jetbackup5-{panel} --disablerepo="*" --enablerepo=jetapps,jetapps-{tier}
Replace {panel} with the installed JetBackup panel package:
cpanel | directadmin | linux | plesk | webuzo
Replace {tier} with the JetApps repository tier used by the server.
Common example:
release | rc | edge | alpha
Example for DirectAdmin on the release tier:
yum --showduplicates list jetbackup5-directadmin --disablerepo="*" --enablerepo=jetapps,jetapps-release
If the JetBackup package list displays correctly, the JetBackup repository is reachable.
Step 4: Temporarily Bypass the Problematic Repository
Use this method when you only need to complete the JetBackup update and do not want to permanently disable the repository yet.
yum update jetbackup5-{panel} -y --disablerepo="example-repo" --enablerepo=jetapps,jetapps-{tier}
Example:
yum update jetbackup5-directadmin -y --disablerepo="example-repo" --enablerepo=jetapps,jetapps-release
Step 5: Run a Fully Isolated JetBackup Update
If more than one third party repository is failing, disable all repositories for the command and enable only the JetApps repositories.
yum update jetbackup5-{panel} -y --disablerepo="*" --enablerepo=jetapps --enablerepo=jetapps-{tier}
Example:
yum update jetbackup5-directadmin -y --disablerepo="*" --enablerepo=jetapps --enablerepo=jetapps-release
This is usually the safest method when the goal is to update JetBackup without being blocked by unrelated server repositories.
Step 6: Permanently Disable the Problematic Repository
Only permanently disable the repository if it is no longer needed, deprecated, broken, or confirmed to be safe to disable by the server administrator.
yum config-manager --disable "example-repo"
Or, on systems using dnf:
dnf config-manager --disable "example-repo"
If config-manager is unavailable, install the required package:
yum install yum-utils -y
Or:
dnf install dnf-plugins-core -y
Then retry disabling the repository.
Step 7: Verify the Repository Is Disabled
yum repolist enabled | grep -i "example-repo"
Or:
dnf repolist enabled | grep -i "example-repo"
If there is no output, the repository is no longer enabled.
You can also check the repository file directly:
grep -R -A10 "^\[example-repo\]" /etc/yum.repos.d/
Look for:
enabled=0
Step 8: Retry the JetBackup Update
After disabling, bypassing, or correcting the problematic repository, retry the JetBackup update.
You can use the standard JetApps updater:
Example:
jetapps -a
yum:
yum update jetbackup5-{panel} -y --enablerepo=jetapps,jetapps-{tier}
Example:
yum update jetbackup5-directadmin -y --enablerepo=jetapps,jetapps-release
Confirm the installed package:
rpm -qa | grep jetbackup5
You may also verify from the JetBackup CLI:
jetbackup5 --version
Real World Example
In one case, the JetBackup update failed because the server had a broken PostgreSQL repository enabled:
Errors during downloading metadata for repository "pgdg13":
Status code: 410 for https://download.postgresql.org/pub/repos/yum/13/redhat/rhel-8-x86_64/repodata/repomd.xml
The problematic repository was:
pgdg13
The update could be completed by bypassing the broken repository:
yum update jetbackup5-directadmin -y --disablerepo="pgdg13" --enablerepo=jetapps,jetapps-release
Or by isolating the update to JetApps repositories only:
yum update jetbackup5-directadmin -y --disablerepo="*" --enablerepo=jetapps --enablerepo=jetapps-release
Notes and Best Practices
Do not delete repository files from /etc/yum.repos.d/ unless you are certain the repository is no longer required.
Disabling a problematic repository is safer than deleting it, since it can be enabled again later if needed.
If the affected repository belongs to a third-party application, review that application before permanently disabling the repository.
When troubleshooting JetBackup updates, always confirm whether the error references jetapps, jetapps-{tier}, or another repository.
If the error references another repository, the issue is most likely external to JetBackup.

