What has to be backed up on a CID222 appliance, how to take a consistent copy, and the order to restore it in.

An appliance's state is a database, a handful of directories on the host, and the secrets that decrypt what is in the database. This page says which those are, how to copy them consistently, and the order to put them back.

What do I need?

Licence: Any
Role: admin_user

Prerequisites

Administrative access to the hypervisor the appliance runs on, or shell access to the appliance host.
A destination for the backup that is not the appliance's own disk.
A maintenance window: the only consistent file-level copy is taken with the stack stopped.
For a restore: the same secrets that were in use when the backup was taken.

Warning

CID222 has no scheduled-backup feature and no restore workflow in the dashboard. The procedures below are manual, and they are what the appliance's layout supports today rather than a product capability. Treat the schedule, the off-box destination and the restore rehearsal as your own operational responsibility.

What the appliance already backs up, and what that covers

The updater takes two database backups immediately before it applies a release: a compressed logical dump and a physical snapshot of the database directory, both under /var/lib/cid/backups. The last 14 dumps are kept. A rollback restores from those.

That is an update safety net, not disaster recovery. It runs only when an update runs, it lives on the appliance's own disk, and it covers the database alone — not the host directories, not the TLS private keys, and not the environment file. Everything below is what you have to arrange yourself.

What to back up

What	Why it matters
`/var/lib/cid`	Setup state, the installed licence, the update state and version, the public TLS mirror, and the updater's own backups
`/etc/cid`	The licence and release trust anchors, the installation identity, and the outbound-proxy configuration
`/opt/cid/.env`	Every secret and setting the stack starts with, including the signing secret that decrypts stored credentials
`/opt/cid/tls`	The appliance's TLS private keys, which never leave the host
The PostgreSQL data volume	Tenants, credentials, filters, sessions, detections, event logs — the product's own data

You do not need to back up container images: a release is re-obtained from the channel or from a bundle. The model caches are rebuilt on their own, and the appliance's own update backups are already inside /var/lib/cid.

Danger

The signing secret in .env derives the keys that protect the stored provider API keys and the directory bind password. A database restored without the matching secret loads, but those values cannot be decrypted and must be re-entered. Back up the environment file with the database, and keep it somewhere at least as protected.

Take a backup

The simplest whole-appliance backup, and the one to prefer before an update or a configuration change you might want to undo.

Shut the appliance down

Power the virtual machine off from the hypervisor, or shut down the guest.

A snapshot of a running appliance captures the database mid-write. It usually recovers, but a powered-off snapshot is the only one you can rely on without testing.

Snapshot or export the virtual machine

Take the snapshot, or export the machine, and copy it off the host.

The copy contains the database, all three host directories and the private keys, so it is a complete appliance.

Power the appliance back on

Start the virtual machine and wait for the dashboard to answer.

Services restart in order; the dashboard may take a few minutes on a cold boot.

Restore, in this order

Order matters: the appliance reads its identity and its trust anchors before it reads the database, and it decrypts stored secrets with a key that comes from the environment file.

Rebuild the appliance to the same release

Deploy the appliance at the release the backup was taken from, and do not walk the setup wizard.

Restoring the state directories is what tells the appliance it is already configured. Completing the wizard first creates a second administrator and a second setup state.

Restore the trust anchors and the installation identity

Put /etc/cid back first, with its original ownership and permissions.

This restores the licence trust anchor and the installation identity. The identity is what the licence is bound to: an appliance that comes up with a new one cannot verify the licence you hold.

Restore the environment file and the private keys

Put /opt/cid/.env and /opt/cid/tls back, owner-only.

Without the original environment file the appliance starts, but the stored provider keys and directory bind password cannot be decrypted.

Restore the state tree

Put /var/lib/cid back.

This returns the setup state, the installed licence, the version stamp and the public TLS material. The appliance now believes it is the same appliance.

Restore the database

Restore the dump into the database, or put the data volume back, before the gateway starts.

Restore into an empty database. Restoring over a database that a fresh deployment already seeded produces conflicts rather than a clean copy.

Start the stack and check what came back

Start the containers and open the dashboard.

Migrations for the running release are applied on boot, so a restore of an older database onto the same release comes up on the current schema.