Understand recovery points and backup services

Product Zbix CRM · Version 1.2.0 · Source reviewed · Reviewed 28 October 2026
Audience Administrators and implementation teams · Deployment Release specific self hosted

Overview

Backup & Recovery coordinates durable jobs for encrypted recovery-point creation, independent integrity verification and isolated restore testing. It distinguishes these states because a completed backup job alone does not prove that the artifact can be restored.

Purpose

Understand which components must be available and which evidence is needed when assessing recoverability.

Prerequisites

• Access to Backup & Recovery appropriate to your responsibilities.

• Knowledge of the installation’s database, private-file storage, destination and external key custody.

Procedure

1. Identify the source PostgreSQL instance and private-file store protected by the self-hosted deployment. The backup runtime uses a consistent exported PostgreSQL snapshot and captures referenced private files.

2. Identify the destination and recovery encryption key. The key is supplied independently of the backup artifact and must remain recoverable if the application host is lost.

3. Follow a recovery point through its states: creation, independent integrity verification and isolated restore test. Review the associated durable job and receipt for each operation.

4. Understand the restore-test boundary. It creates a temporary database and file area, compares recovered data and hashes, and does not start a customer-facing application or external integrations.

5. Separate self-hosted recovery from provider-managed recovery. The ordinary worker does not execute a managed cloud database snapshot or point-in-time recovery simply because provider metadata is present.

Expected result

Operators can explain the protected data, supporting services, external dependencies and the meaning of each recovery state.

Screenshots and diagrams

SS-045 · Backup & recovery overview. Demonstration capture, 28 October 2026. Select the image to enlarge.

Important notes

• The v2 recovery configuration records required external secrets but does not include their values. Database credentials, MFA and communication keys, integration signing material and the backup recovery key need independent custody.

• Local and S3-compatible destinations are implemented. Managed database/PITR, Azure, GCS and SFTP entries do not establish connected provider recovery.

• No live restore action is available in CRM. Production recovery is a separately authorized operator process.

• The encrypted bundle is memory-bound. Capacity and recovery objectives require deployment-specific qualification.

Troubleshooting

• If Overview shows a successful backup but no verified or tested point, complete the missing operation and inspect its receipt.

• If an artifact is available but its required key is not, escalate to the recovery-key custodian. Do not replace keys and assume old artifacts will remain recoverable.

• If a provider operation remains a handoff request, confirm the deployment’s actual connected recovery service rather than repeatedly queuing the request.

Related articles

• Prepare backup access keys and storage

• Create an encrypted recovery point

• Verify a recovery point independently

• Test a recovery point in isolation

• Assess managed SaaS capabilities