Hyvop

Get 40% offSee the offer

0.9.0 betaDocumentation of the Community Edition, copied on .
On this page

Backup and restore#

The chart does not back anything up for you. This page says what holds state, what must be copied, and what a restore needs. Make a restore test before you rely on a backup.

What holds state#

Store Object Volume Holds
PostgreSQL StatefulSet hyvop-postgres PVC data-hyvop-postgres-0 (1Gi by default) Core's database: accounts, organisations, integrations and their settings
ClickHouse StatefulSet hyvop-clickhouse PVC data-hyvop-clickhouse-0 (2Gi by default) The data lake: inventory, metrics and cost
Valkey Deployment hyvop-valkey none Nothing on a volume; there is nothing of it to back up

If you set postgres.persistence.enabled=false or clickhouse.persistence.enabled=false, that store lives in the pod and is lost when it restarts; that is for a throwaway evaluation only.

The stores hold your inventory, metrics, cost, findings and audit record in clear. Hyvop encrypts only the secrets described below; encrypt the volumes themselves with a storage class that encrypts (global.storageClass, or per store postgres.persistence.storageClass and clickhouse.persistence.storageClass). The class of a volume cannot be changed afterwards.

What must be kept besides the data#

A copy of the database is not enough. Keep these Secrets with your backups. They are in the release's namespace; none of them is stored on a volume, and uninstalling the release deletes the ones the chart made.

Secret Key Why it matters
hyvop-core-secrets data-key The data key. The secrets the database holds (what an integration signs in with, the mail relay's password, a model provider's key) are encrypted under it. Without it they cannot be read and must be entered again
hyvop-core-secrets jwt-secret-key (and jwt-previous-secret-keys) The session key. Sessions are signed with it. If it changes, everyone is signed out
hyvop-core-secrets setup-code, ai-key, oidc-client-secret The setup code, the model key and the identity provider's secret, if you use them
hyvop-ingestor-secrets shared-secret What core proves itself to the ingestors with
hyvop-postgres-credentials password The password the PostgreSQL volume was initialised with
hyvop-clickhouse-credentials, hyvop-clickhouse-accounts password; reader-password, ingest-password ClickHouse's three accounts
hyvop-keycloak-credentials admin-password Only if you use the bundled Keycloak

If you named a Secret of your own for a concern (core.existingSecret, postgres.existingSecret and the others), that Secret is yours to back up, and the chart does not delete it.

Copy the data key as the notes of the chart tell you:

sh
kubectl get secret hyvop-core-secrets -n hyvop -o jsonpath="{.data.data-key}" | base64 -d

Store it somewhere other than the backup of the database: together they open everything; apart, neither does.

Taking a backup#

  1. A consistent copy of both stores is a snapshot of their volumes taken at the same time, using your storage provider's volume snapshots. To avoid a write in the middle of collection, scale core down first and back up afterwards:

    sh
    kubectl scale deployment hyvop-core -n hyvop --replicas=0
# ... take the snapshots ...
kubectl scale deployment hyvop-core -n hyvop --replicas=1

    The ingestors write to ClickHouse as well; scale hyvop-ingestor-aws (and the Azure and GCP ones if you run them) down in the same way. Core schedules the collections, so with core down none starts.

  2. Copy the Secrets above, in particular the data key and the session key.

  3. For PostgreSQL you may also take a logical dump, from inside the pod: kubectl exec -n hyvop hyvop-postgres-0 -- sh -c 'pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' > hyvop.sql.

Record the chart version you ran (helm list -n hyvop): a restore goes back into the same version, then upgrades.

Restoring#

Restore into a namespace with no Hyvop in it.

  1. Restore the volumes to PVCs with the names in the table above, in the namespace you will install into.
  2. Recreate the Secrets from your copies, before the install. Either create Secrets of your own and name them (core.existingSecret, core.ingestorExistingSecret, postgres.existingSecret, clickhouse.existingSecret, clickhouse.accountsExistingSecret), or give the values back (core.env.HYVOP_DATA_KEY, core.env.JWT_SECRET_KEY, postgres.db.password, clickhouse.password, ...). A Secret of your own must hold the keys in the table above; data-key needs 32 characters or more.
  3. helm install the same chart version with the same values.
  4. Check that core starts. Core refuses to start while a stored value is under a key it was not given; its log names the table and the missing key's id. Give the old key in core.env.HYVOP_PREVIOUS_DATA_KEYS. If a key is lost for good, nothing can read what was written under it: empty those values and enter the secrets again.
  5. Sign in, open Integrations and read the ingestion card: it shows the last and next run of each collection.

Do not reinstall over a kept volume without giving the old secrets back. The data key is made anew by a fresh install and would not open what the old key sealed; and a PostgreSQL volume was initialised with the password then in hyvop-postgres-credentials.

Changing the data key#

To change the key, give the new one and name the old one, then upgrade; core rewrites what was under the old key at its next start, after which the old key can be removed from core.env.HYVOP_PREVIOUS_DATA_KEYS:

sh
helm upgrade hyvop ./hyvop -n hyvop --reuse-values \
  --set core.env.HYVOP_DATA_KEY="$(openssl rand -base64 48)" \
  --set core.env.HYVOP_PREVIOUS_DATA_KEYS="<the key until now>"