Back up Telark

Telark does not back itself up. Choose the tool; this page lists what to capture and the restore order.

What to back up

Not worth backing up: Redis (in-app notifications, insights, queues and locks; losing it clears the notification feed and current insights) and the Kyverno policies of active plans, which Telark redeploys from the plans.

The snapshot volume holds Secret manifests. Encrypt and restrict its backups accordingly.

1. Back up the volumes

With Velero and CSI volume snapshots, a schedule over the whole namespace captures both volumes and the custom resources in one backup:

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: telark
  namespace: velero
spec:
  schedule: "0 */6 * * *"
  template:
    includedNamespaces:
      - telark
    snapshotVolumes: true
    ttl: 720h

Without CSI snapshots, use Velero's file-system backup, or your cloud's volume snapshots (aws ec2 create-snapshot, gcloud compute disks snapshot, az snapshot create).

2. Export the custom resources

For a portable copy, or to inspect objects outside Velero:

for r in applications protectionplans telarkconfigs categories \
         users groups accessroles passkeys sessions; do
  kubectl get "$r.telark.io" -n telark -o yaml > "$r.yaml"
done

Use the fully qualified names. A plain kubectl get applications may return Argo CD's resources instead.

Restore into a new cluster

1. Install Telark as for a fresh cluster (Install Telark for production), with the same flags.

2. Restore the snapshot and report volumes, then restart the exporter so it mounts them:

   kubectl rollout restart -n telark deploy/telark-exporter-service

3. Restore the custom resources in this order: Category, AccessRole, Group, User, TelarkConfig, Application, ProtectionPlan, Passkey. Skip Session; people sign in again.

Two things get in the way of a plain kubectl apply:

• The CRD write guard rejects writes to telark.io from anyone but Telark's service accounts. Run the restore as an identity listed in app.crdGuard.extraAllowedUsers.
• Application, ProtectionPlan and TelarkConfig keep snapshot and rollback records, plan phases and approvals in .status, which kubectl apply does not write. Only a tool that restores the status subresource brings it back, for example a Velero restore with restoreStatus covering the telark.io resources.

Active plans redeploy their Kyverno policies on the next controller tick.

Test the restore

Backups you have never restored are a guess. Restore into a sandbox cluster from time to time and check that applications show their history and that a rollback to a restored snapshot succeeds.