On this page
Backups and recovery in the portal
Define a portal-based protection and restore workflow, while clearly separating the planned Cloud capability from what customers can use today.
Use this planning guidance now for an inquiry and pilot proposal. Service commitments require a written agreement.
Before you start
Before the pilot starts, list data owners, persistent volumes, databases, object storage, secrets/configuration, retention, recovery point objective (RPO), recovery time objective (RTO), data location and deletion rules. A platform plan or more nodes does not automatically protect application data.
1. Define what must be protected
| Data class | Questions for the proposal |
|---|---|
| Application state | Which volumes/database records are required to restart the service? Which consistency point is valid? |
| Configuration | Are secrets, config, certificates and registry references included or customer-owned? |
| Retention | How many restore points, for how long and in which location? |
| Recovery | Who starts recovery, who validates the application and what is the agreed RPO/RTO? |
2. Planned portal workflow
The intended Cloud screen, once the protection capability is released, is: open Protection in the cluster workspace, choose data scope and retention, review the quoted infrastructure/protection item, create a snapshot or scheduled policy, follow its operation ID, and open a separate Restore action into an isolated target before replacing a live workload.
- 01
Preview
Review data scope, size, retention, cost and target; no data should change during preview.
- 02
Create
Confirm once and save the operation ID, point-in-time and resulting protection status.
- 03
Restore test
Restore into an isolated target, run the application acceptance test and record elapsed time and data consistency.
3. Prove recovery before relying on it
- ✓The portal shows a current successful protection result, not only a scheduled intent.
- ✓The restore point contains the agreed data and configuration without exposing secrets.
- ✓An isolated application test passes and the measured RPO/RTO is recorded.
- ✓The owner knows the retention, deletion and support escalation path.
4. What to do in the current pilot
Ask ClusterPilot to include backup/restore scope, retention, RPO/RTO, data location and a restore test in the individual proposal. If the requirement is not explicitly accepted, treat it as uncovered and keep the launch decision open. The update page's readiness gate is a safety check; it is not evidence that customer backup creation or restoration is available.
Use this guide within your agreed pilot scope. Kubernetes examples are not evidence of a generally available Cloud capability.