Rollback
Rollback restores the previous working control-plane version after an upgrade failure. First identify whether the issue comes from Chart, image, CRD, values, webhook certificate, or external dependencies.
Before Rollback
Check Helm revisions:
helm history testudo -n disaster-system
Inspect current state:
kubectl -n disaster-system get pods
kubectl -n disaster-system describe pod <pod-name>
kubectl -n disaster-system get events --sort-by=.lastTimestamp
If the issue is object storage, remote cluster reachability, image registry, or License, do not start with a Chart rollback.
Helm Rollback
helm rollback testudo <REVISION> -n disaster-system
Watch rollout:
kubectl -n disaster-system rollout status deploy/disaster-server
kubectl -n disaster-system rollout status deploy/disaster-web
kubectl -n disaster-system rollout status deploy/disaster-operator-controller-manager
CRD Rollback Notes
Helm rollback may not safely roll back CRDs. If a new version already wrote fields unknown to the old controller, rollback can cause:
- Old controller ignores new fields.
- Status parsing fails.
- Webhook validation does not match.
CRD-changing releases must provide migration and rollback guidance. Without explicit guidance, do not automatically roll back CRDs.
Post-rollback Verification
kubectl -n disaster-system get disasterinstances.testudo.softcdata.com
kubectl -n disaster-system get disasteroperation
kubectl -n disaster-system get appbackups,apprestores
In the console, verify:
- Login works.
- Instance list and detail pages work.
- Watch streams work.
- Backup/restore/disaster recovery history is readable.
When Not To Roll Back
- A failover, reprotect, undo, cancel, or drill cleanup is running.
- A CRD data migration has completed and the old version is incompatible.
- The problem is remote cluster or object storage failure.
- The problem is a business workload failure.
Pause new operations, preserve evidence, and follow release notes for manual recovery.