Summary
The current backup & restore guide does not cover a common enterprise topology where a worker group runs in a separate Kubernetes cluster under a different service account, with tenant-scoped internal storage that is not reachable from the primary cluster. Because the two clusters are fully isolated — the primary cluster has no access to the worker cluster's storage, and vice versa — backup and restore must be executed independently in each environment. The current guide gives no indication of this requirement, making migrations an operational risk.
Topology to document
Cluster A (primary) → Kestra control plane, JDBC backend, SA: kestra-sa
Cluster B (workers) → Worker group, SA: worker-sa (isolated IAM/RBAC)
Internal storage → Scoped to worker-sa; no cross-cluster access in either direction
Requested content
Please add a section titled something like "Cross-cluster worker groups with tenant-scoped storage" under the existing Backup & Restore of Internal Storage section. It should cover:
-
A clear statement that the primary cluster has no access to worker-group-scoped storage — backup and restore are entirely separate operations per cluster, coordinated by timing, not by data transfer between clusters.
-
Prerequisites identifying which tenants use worker-group-scoped storage and mapping them to their respective service accounts and clusters. Kestra placed in maintenance mode as in other guide
-
Backup procedure, two independent steps using the Kestra CLI in each cluster:
- run
kestra backups create FULL --tenant tenant_a from Cluster A tenants
- run
kestra backups create FULL --tenant tenant_b from Cluster B (executed from worker)
- Restore procedure, run restore command
- A preflight check recommendation — verify the worker group's service account can reach its internal storage before starting any migration, to avoid discovering the gap mid-operation.Suggested placement
Immediately after the existing "Backup & Restore of Internal Storage" sub-section. Cross-link from the Worker Group page under an operational considerations or migrations note.
Additional context
Even a short callout box on the existing page — warning that worker groups with tenant-scoped storage require an independent backup operation executed from the worker cluster — would be a meaningful improvement over the current state, where there is no indication this topology requires any special handling.
Summary
The current backup & restore guide does not cover a common enterprise topology where a worker group runs in a separate Kubernetes cluster under a different service account, with tenant-scoped internal storage that is not reachable from the primary cluster. Because the two clusters are fully isolated — the primary cluster has no access to the worker cluster's storage, and vice versa — backup and restore must be executed independently in each environment. The current guide gives no indication of this requirement, making migrations an operational risk.
Topology to document
Cluster A (primary) → Kestra control plane, JDBC backend, SA: kestra-sa
Cluster B (workers) → Worker group, SA: worker-sa (isolated IAM/RBAC)
Internal storage → Scoped to worker-sa; no cross-cluster access in either direction
Requested content
Please add a section titled something like "Cross-cluster worker groups with tenant-scoped storage" under the existing Backup & Restore of Internal Storage section. It should cover:
A clear statement that the primary cluster has no access to worker-group-scoped storage — backup and restore are entirely separate operations per cluster, coordinated by timing, not by data transfer between clusters.
Prerequisites identifying which tenants use worker-group-scoped storage and mapping them to their respective service accounts and clusters. Kestra placed in maintenance mode as in other guide
Backup procedure, two independent steps using the Kestra CLI in each cluster:
kestra backups create FULL --tenant tenant_afrom Cluster A tenantskestra backups create FULL --tenant tenant_bfrom Cluster B (executed from worker)Immediately after the existing "Backup & Restore of Internal Storage" sub-section. Cross-link from the Worker Group page under an operational considerations or migrations note.
Additional context
Even a short callout box on the existing page — warning that worker groups with tenant-scoped storage require an independent backup operation executed from the worker cluster — would be a meaningful improvement over the current state, where there is no indication this topology requires any special handling.