JetBackup shipped v5.4.2 on 16 August 2026, and it's the kind of release that's easy to skim past because the version bump looks minor. It isn't. The headline addition is an Immutable Backups Wizard that turns S3 Object Lock configuration from a manual bucket-policy exercise into a guided setup, alongside destination duplication, orphan-backup retention controls, and a long list of restore-path fixes across every supported panel. If you run JetBackup 5 across a fleet, this is worth pulling forward rather than letting it ride until the next scheduled maintenance window.
Immutable Backups Wizard
Until this release, getting JetBackup writing to an Object Lock-protected bucket meant configuring the bucket's Compliance mode retention, the destination's path-style addressing, and the retention math by hand — see immutable JetBackup 5 backups with S3 Object Lock for what that involved. 5.4.2 adds a wizard (WHM → JetBackup 5 → Destinations → Immutable Backups Wizard) that walks through the same setup with the lock-versus-retention window math handled for you.
The wizard doesn't replace the underlying constraint — lock period still has to exceed retention period, or the daily prune job fails against a still-locked object — it just removes the chance of getting the arithmetic wrong on the first bucket you configure. Existing Object Lock destinations configured manually before 5.4.2 keep working; there's no migration step required.
Destination duplication and orphan retention
Two smaller additions change day-to-day destination management:
- Duplicate/Clone Destination: copy an existing destination's full configuration — endpoint, credentials, path style, multipart threshold — as the starting point for a new one. Useful when standardising a second region or provider off a destination you already tuned, rather than re-entering every field from configuring JetBackup 5 destinations on cPanel.
- Orphan Backups Retention: a dedicated retention setting for backups whose parent account no longer exists on the server (deleted cPanel account, terminated reseller). Previously these accumulated until a manual cleanup; now they age out on their own schedule, independent of the retention window on active accounts.
Bug fixes worth knowing about
The fix list is long — full detail is in JetBackup's own changelog — but a handful affect common restore paths directly:
- cPanel v136 restore warnings: account restores no longer throw spurious
chmodwarnings on scoped userdata during restore on cPanel 136. If you saw warning noise in restore logs after upgrading to cPanel 136, this is why. - Bare Metal Recovery ISO ordering: BMR backups now generate the recovery ISO first and upload snapshot data last, instead of the reverse. The previous order could leave a BMR backup set with snapshot data but no matching ISO if the job was interrupted mid-run.
- MySQL
caching_sha2_passwordaccounts: cPanel-panel backups were silently skipping MySQL users authenticated with thecaching_sha2_passwordplugin (MySQL 8's default since cPanel switched away frommysql_native_password). Confirm any recent backup sets that predate 5.4.2 actually captured these users before relying on them for a restore. - "Too many open FD" errors: resolved a file-descriptor leak that surfaced during operations opening sockets repeatedly — mostly visible on servers doing large numbers of small incremental jobs in sequence.
- Disaster Recovery auto-lockout: critical settings are now automatically disabled while a DR routine executes, preventing a concurrent configuration change from corrupting an in-progress disaster recovery run.
Per-panel fixes
Beyond the base engine, each supported panel got its own patch set. The ones most likely to affect a live fleet:
- DirectAdmin: fixed incorrect home directory group ownership after restore, a Roundcube configuration restore failure, and an SSL "Key is Invalid" error when saving certificates.
- Plesk: fixed
httpdocsdirectory group ownership incorrectly changing topsaclnduring homedir restoration. - Linux (standalone): fixed email backups using an
.emptymailplaceholder path when the source account had an empty email path, which caused restores to fail outright rather than skip cleanly. - Webuzo: fixed account restores failing outright when the terminate-existing-account option was enabled.
None of these are exploitable security issues — they're restore-correctness bugs, which matters more in practice: a backup that silently drops MySQL users or fails a DR restore partway through is worse than one that fails loudly at backup time.
Upgrade recommendation
Run the update through WHM's JetBackup interface or /scripts/upcp if JetBackup updates are
bundled into your cPanel update cycle. There's no deprecation or breaking change in this
release that requires a maintenance window — the jetmongod version bump is the only
prerequisite to check first. If you're running Object Lock destinations configured before
this release, there's nothing to redo; the wizard is additive for new destinations only.
Confirm your JetBackup license is current, since license validation
gates access to update channels the same way it does on every other product in this stack.