Backups

telark holds two pieces of durable state inside your cluster:

The snapshot PVC, mounted into the exporter pod, holds the captured manifest blobs. This is the audit trail.
The telark CRDs, persisted in etcd by the API server, hold application, plan, user, role, group, session, and config state.

Neither is automatically backed up by telark. The choice of backup tool is yours — this page is the operational shape.

Backing up the snapshot PVC

The snapshot PVC is a single volume mounted into the exporter pod at SNAPSHOT_PVC_PATH. The on-disk layout is a hierarchy:

/<root>/<scope>/<namespace>/<application>/<generation>/<id>.json

Three workable backup strategies:

Velero with volume snapshots

If your CSI driver supports volume snapshots (CSI-spec VolumeSnapshot), Velero is the lowest-friction option:

# Velero schedule, abridged
spec:
  schedule: "0 */6 * * *"
  template:
    snapshotVolumes: true
    storageLocation: default
    includedNamespaces:
      - telark

Restore is velero restore create --from-backup <name>. The volume comes back as the same PersistentVolumeClaim the exporter mounts.

Velero with restic

If CSI volume snapshots are not available, Velero's restic fallback writes a file-level backup of the PVC to an object store. Slower; works on any storage class.

Per-cloud volume snapshots

If your storage class is cloud-native (EBS, GCP PD, Azure Disk), the cloud's own volume-snapshot mechanism is the simplest path:

AWS: aws ec2 create-snapshot against the underlying EBS volume, or aws backup for a scheduled plan.
GCP: gcloud compute disks snapshot.
Azure: az snapshot create.

Restore is cloud-specific. The trade-off is portability: cloud-snapshot artefacts live in the cloud, not in your backup store.

The telark CRDs are part of the cluster's etcd state. They are covered by any backup that captures custom resources — Velero backs them up by default (treat the CRDs as part of the telark namespace).

If you only want the telark CRDs (e.g. for migration), capture them via kubectl:

kubectl get applicationsasresources.erpi.telark -A -o yaml \
  > applications.yaml
kubectl get protectionplans.telark -A -o yaml > plans.yaml
kubectl get users.telark -A -o yaml > users.yaml
kubectl get userpasskeys.telark -A -o yaml > passkeys.yaml
kubectl get usersessions.telark -A -o yaml > sessions.yaml
kubectl get roles.telark -A -o yaml > roles.yaml
kubectl get groups.telark -A -o yaml > groups.yaml
kubectl get categories.telark -A -o yaml > categories.yaml
kubectl get globalconfigs.telark -A -o yaml > globalconfig.yaml

(Resource-group names follow the kind-lowercased convention; the exact list is in Reference → CRD reference.)

Restore is kubectl apply -f <file>. UserSession captures in particular are short-lived — there is rarely a reason to restore them.

What backups do not cover

Redis state — the exporter holds notifications in Redis. These are inherently ephemeral; treat the loss of Redis as the loss of the notifications feed only.
Live cluster state — Kyverno policies the protection-plan applier deployed live in the cluster's etcd, labelled by plan ID. Backing up plans is enough; the applier re-deploys policies on the next active phase transition.

Coordinating backups

A sane operational pattern:

Velero schedule every 6h, retaining 30 days, against the whole telark namespace (PVC + CRDs in one snapshot).
Separate disaster-recovery copy nightly to a cross-region bucket.
Quarterly restore drill into a sandbox cluster to validate the process.

Volume snapshots without occasional restore tests are a liability. Test the restore.

Disaster recovery shape

A full DR restore for a cluster telark was installed in:

Install telark in the new cluster as if it were fresh (see Getting started → Quickstart).
Restore the PVC from your backup (Velero / restic / cloud snapshot).
Restore the telark CRDs from the backup. Apply in this order: Category → Role → Group → User → GlobalConfig → ApplicationAsResource → ProtectionPlan → UserPasskey.
Restart the exporter pod so it mounts the restored PVC.
telark reconciles. Active plans will re-deploy their Kyverno policies on the next controller tick.