Documentation

The operational database: discovered material, host inventory, tasks, templates, policies, tags, dashboard layouts and configuration. This is the essential backup; losing it means re-discovering the entire estate.
The audit database: change history. Losing this loses the timeline permanently, because it cannot be reconstructed from current state. Where history supports an audit obligation, this backup is not optional.
The identity provider database: users, realm configuration and federation settings. Alternatively, keep a current realm export.
Configuration files, or the environment file that generates them, including the credential encryption key. Without that key, credentials in a restored database are unrecoverable — which makes the key part of the backup, and makes storing it alongside the backup a mistake.
Certificates and private keys.
The log store, if log retention is an audit obligation rather than an operational convenience.
Not required: container images, frontend assets, or generated configuration — all reproducible from source and the environment file.

Both objectives, and what determines them, are set out below, so that a deployment can set them deliberately rather than inherit them.

Recovery point objective: how much data loss is acceptable. Discovery data is regenerable by re-scanning, so a longer objective may be tolerable for the operational database. History is not regenerable, so the audit database usually needs a shorter one. These being different numbers for the two databases is a legitimate and cost-effective choice.
Recovery time objective: how long the platform may be unavailable. During an outage, discovery is not running and compliance reporting is unavailable, but no discovered material is lost as long as the databases survive.
Backup frequency should be derived from the recovery point objective, not chosen by habit.

Database: use the native database dump or snapshot mechanism. Back up both the operational and audit databases. A dump of one is not a backup of the platform.
Container volumes: the repository ships a backup helper covering the named volumes. Confirm what it covers and, importantly, what it does not.
Identity provider: export the realm including users, on a schedule, and keep the export with the backup set.
Configuration and secrets: back these up separately from the database, under separate access control. The credential encryption key stored next to the encrypted database defeats the encryption entirely.
Automate all of the above and monitor the automation. An unmonitored backup job is a backup you find out about during a restore.

Stop the platform services before restoring the database, so nothing writes during the restore.
Restore the operational and audit databases from the same backup point, so that history and current state agree.
Restore configuration and the credential encryption key. Confirm the key matches the one in use when the backed-up credentials were written, or every stored credential will need re-entering.
Restore or re-import the identity provider realm.
Restore certificates and keys.
Start services in the documented order: database, identity provider, backends, frontend and proxy.
Work through the validation checklist in 2.7. A restore is not complete until it is validated.

Verify every backup is readable, not merely that the job reported success.
Perform a full restore into an isolated environment on a schedule. This is the only way to know the restore procedure works and how long it takes — and the elapsed time is what the recovery time objective must be based on.
Verify after a test restore: login succeeds, the inventory count matches, a history timeline renders, a stored credential decrypts, and a scan runs.
Record the elapsed restore time and use it to validate or correct the stated recovery time objective.

Keep at least one backup copy in a separate failure domain from the platform.
Encrypt backups at rest, and manage the backup encryption key separately from the backup.
Apply retention to backups deliberately, matching the customer audit obligation.
Restrict access to the backup set to the same standard as the platform itself. A backup contains the whole cryptographic inventory of the estate, which makes it a high-value target in its own right.