Skip to content
ZBIX website
ZBIX CRM 1.2.0

Apply an approved application upgrade

The Linux package provides an upgrade command that verifies package content and image identities, installs a versioned release, applies forward migrations and checks readiness. Native Windows updates use a different package lifecycle and must follow their release-specific qualification.

Execute the approved package upgrade and verify the resulting application and background services.

  • Completed upgrade preparation with a fresh independently verified and isolated-restored recovery point.

  • The approved target package and a release-specific supported upgrade path.

  • An authorized maintenance window and operator access to the target.

  1. Confirm the current installation and intended target one final time. Check that the approved recovery artifact and required external keys are available.

  2. For Linux, extract the approved target archive into a separate staging directory and verify its inner checksums and manifest. Use the target package’s own bin/zbix-crm command so that its runtime files match the intended release.

  3. Set the required recovery-point acknowledgement through the approved maintenance procedure, using the identifier whose verification and restore-test receipts were reviewed. The operator remains responsible for the validity of that recovery evidence.

  4. Run the target package’s upgrade command during the approved window. It stops API/worker writers, applies forward migrations, installs the updated service command and restarts the stack. Monitor the command outcome; do not assume completion from a new image being present.

  5. Check status, version and readiness. Confirm the expected migration, worker heartbeat, storage access and representative authorized application operations. Review background queues for new failures.

  6. For native Windows, use the publisher-approved update procedure for the exact package after a protected-state backup and rehearsal. The installer can stop/re-register the existing service, but that behavior alone does not qualify all Windows upgrade paths.

  7. Record the resulting package/schema identities, validation results and any unresolved items. Reopen normal use only when the change owner accepts the result.

Post-upgrade Linux verification

Terminal window
sudo zbix-crm status
sudo zbix-crm version
curl -fsS http://127.0.0.1:8088/api/ready

The approved target release is running with the expected schema and service behavior, or the installation remains controlled while the documented failure response is applied.

  • The Linux installer requires an acknowledged recovery-point ID; it does not replace independent verification and restore testing.

  • On Linux migration failure, the previous release setting is restored and services remain stopped. No automatic database downgrade occurs.

  • Do not run the new-install procedure over an existing Linux installation or improvise a Windows upgrade based solely on retained ProgramData.

  • If package or image identity checks fail, stop and obtain the correct package rather than editing integrity records.

  • If migration fails, follow the approved recovery/forward-repair decision while services remain controlled.

  • If readiness passes but worker or business checks fail, keep the change open and investigate the affected service. Escalate with sanitized command outcome and exact identities.

Download manuals ↓

Open full-resolution image