BEFORE YOU BEGIN
Check before you begin
License entitlement, release compatibility and data-recovery acceptance are separate concerns. This guide is based on local code/package documentation; sample releases, capacities and rollback behavior are not guarantees for every installation.
Visual/action limit: no real license/updater screen was captured in this inspection; another screen was not substituted. Content is based on license_manage.py, related license handlers and unified updater documentation. No license file/manager, server setting, timer, package, migration, service restart or rollback action was performed. Commands are read-only check examples; they were not executed in this inspection.
- Authorized operator and installation/machine identity
- Valid license or signed release package
- Maintenance, backup and rollback planning
- Release, service and data acceptance evidence
011. Define the target release and component inventory
Inventory master/web, repository, dispatcher/scheduler, node/DataMover, VMware/OpenShift and agent releases. Validate release notes and supported upgrade paths from the authorized package; an example named 1.2.0 is not the latest-release claim. Linux unified updater and Windows/AD agent upgrades are different procedures.
Expected resultScope, release and the relevant check result are recorded.
022. Validate package integrity and provenance
Validate the authorized archive, outer SHA-256, inner SHA256SUMS and available signature using a trusted public key. A hash alone does not prove publisher identity. The unified guide says remote auto-update rejects unsigned packages by default and rejects path traversal archives; validate that behavior in the installed updater. Never distribute private signing keys to customers.
Command examplesha256sum -c SHA256SUMS
Expected resultScope, release and the relevant check result are recorded.
033. Plan maintenance and running jobs
Correlate active backup/restore/replication processes and scheduler queues using run identities. Do not replace running binaries without an approved maintenance gate and drain plan; avoid automatic kills or queue/state deletion. A callback-based fixture test in the Windows AD transaction document is not proof of a real cross-process maintenance lock or production-ready updater.
Expected resultScope, release and the relevant check result are recorded.
044. Prepare configuration, database and rollback evidence
Prepare protected, accessible backups for configuration/credentials/TLS, databases and existing binary/unit releases. Keep tokens/private keys out of general support bundles. Separate migration recovery from binary rollback; do not assume old releases can read upgraded catalogs. Record the rollback point and stop criteria in advance.
Expected resultScope, release and the relevant check result are recorded.
055. Apply updates only to matching roles
The unified updater can read roles from install.roles; automatic-update timers require explicit configuration. Use offline-package and role-override paths according to the installed release’s operator guide. Do not generalize documented /etc/erabackup preservation to every configuration/migration operation. This guide executes no live update command and enables no automatic updater.
Expected resultScope, release and the relevant check result are recorded.
066. Complete health, release and data-path acceptance
After packaging changes check service and binary/hash results, repository health and client HTTPS access. Complete catalog/data acceptance with an approved small Full/incremental and isolated restore test; HTTP 200 alone is not backup acceptance. Read updater journal/log and timer state; verify every required role separately.
Command examplejournalctl -u era-updater -n 100 --no-pager
systemctl list-timers era-updater.timer
Expected resultScope, release and the relevant check result are recorded.
077. Record rollback limits and return to service
The unified guide stores old binaries/units under /opt/erabackup/rollback/update-* and describes rollback after certain repository/relay/scheduler health failures. This does not establish automatic recovery of database migrations, remote nodes or every agent. Roll back only within an approved scope; exit maintenance and resume scheduling after acceptance. This inspection installed no package and executed no update/rollback or restart.
Expected resultScope, release and the relevant check result are recorded.
COMMON QUESTIONS
Is a file upload or health check enough?
No. Validate identity/scope, release and post-action data acceptance separately. Licensing and upgrade/rollback are different operations.