Concepts

Snapshots and retention

How telark captures manifests on the change cycle and bounds how many it keeps.

A snapshot in telark is the recorded manifest of an application's tracked resources at the moment a change cycle finished. Snapshots are the audit trail of cluster state; they are also the raw material a rollback re-applies.

This page is the conceptual primer. The wire surface — endpoints, payloads, headers — lives in Features → Snapshots & rollback.

When a snapshot is taken

Discovery runs an event-coalesced cycle on its informer cache. When a cycle classifies a change (see Concepts → Change classes), it walks the application's resource inventory and writes one snapshot record per (application, namespace, generation) tuple. The manifest is persisted to the exporter's PVC; the entry is appended to the application's snapshots array on the CRD.

You do not have to ask for snapshots. They happen on the cycle. The dashboard's Manage Snapshots panel surfaces what already exists; there is no "take snapshot" button.

What "generation" means

Every application carries a monotonic generation counter that discovery increments when the cycle records a change. The generation is the stable handle for a snapshot: a rollback targets a generation, not an ID, because IDs differ between namespaces while generation is the application-wide ordinal.

What gets captured

The kinds telark tracks for snapshot purposes line up with the admission targets the protection-plan applier also recognises:

  • ServiceAccount
  • Secret
  • ConfigMap
  • Service
  • NetworkPolicy
  • Deployment
  • StatefulSet
  • DaemonSet
  • Job
  • CronJob

Plus the operational kinds carried in the application's resource inventory when present (PVCs, Ingresses, HPAs, VPAs).

The manifest is captured as-is from the informer cache. If a controller-managed field (e.g. status, resourceVersion) was on the object at capture time it is on the snapshot — the rollback controller filters those out at apply time.

Retention

Retention is bounded so the PVC does not grow unbounded:

  • Default: 5 versions per scope.
  • Configurable via the GlobalConfig CRD field spec.snapshots.maxPerApp.
  • Pruning runs automatically as new snapshots land — the oldest exceed-the-limit entries are deleted from the PVC and from the application's snapshots array.

A higher cap means more rollback history but more PVC consumption. The Storage bars in the dashboard help you see how much room is left before pruning kicks in.

What retention is not

  • Not a backup. telark snapshots cover the manifest layer only. Volume contents, secrets that resolve via external KMS, and cluster-level state outside the tracked kinds are out of scope. Use Velero or volume-snapshot tooling for the data plane.
  • Not a compliance log. If you need long-term retention, capture the NATS telark.applications.update topic into your own store before retention prunes the manifest.

How a snapshot relates to a rollback

A rollback picks a generation and re-applies every snapshot entry for that generation. If the application spans namespaces, the rollback controller treats the multi-namespace snapshot set as one logical unit keyed by generation.

The rollback controller sorts the manifests by kind order (ServiceAccount first, CronJob last) so dependencies land before the workloads that reference them.