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:
ServiceAccountSecretConfigMapServiceNetworkPolicyDeploymentStatefulSetDaemonSetJobCronJob
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
GlobalConfigCRD fieldspec.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
snapshotsarray.
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.updatetopic 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.