Disaster recovery
Restore application data, replace lost capacity, and verify recovery procedures.
Disaster recovery creates replacement infrastructure from retained data and restores application service after hardware, storage, or regional failure. A recovery plan must include data, configuration, credentials, and traffic changes.
Select a recovery source
Open Storage → Backups → Recovery points for completed backups, Storage → Volumes → Volume → Snapshots for a local capture, or Storage → Volumes → Volume → Replication for a regional recovery target.
Use a healthy retained volume for a compute-only failure, a snapshot for a local data rollback, or a completed backup when the source pool or region is unavailable. Inspect capture time and consistency before choosing the source.
For compute-only failure, a surviving replicated volume can avoid a data restore, but the previous writer must be excluded before replacement execution begins. For application corruption, the newest live replica usually contains that same corruption; select a recovery point from before the damaging change.
A snapshot depends on the source storage system remaining readable. An independent backup can survive the loss of that pool but requires destination access, decryption material, transfer capacity, and newly created resources.
Restore an application
- Open a completed recovery point, inspect all included volume IDs, and choose Restore.
- Choose an allowed target region and storage policy.
- Create an isolated recovery network without production DNS or load balancer attachment.
- Restore volumes and create droplets with a compatible image and CPU profile.
- Supply current credentials through the approved secret-delivery procedure.
- Verify boot, filesystems, databases, application migrations, and background jobs.
- Stop or fence the previous writers before allowing the recovered service to accept writes.
- Update load balancer backends or DNS and observe application health.
Restored resources receive new IDs. Network addresses, volume attachment IDs, and host keys can change. Update automation references explicitly. The restore manifest maps source resources to their replacements.
Avoid competing writers
A failed control connection does not prove that a source host is stopped. Establish fencing through host power control, storage lease revocation, or the approved infrastructure procedure before promoting a replacement writer.
For databases with their own replication, coordinate promotion with the database's ownership model. An infrastructure restore cannot determine which application replica contains the authoritative transaction history.
Restore across regions
The backup data and destination policy must permit the target region. Image, network, firewall, quota, and capacity requirements are checked again there. A backup copy does not recreate external DNS zones or third-party integrations.
Use data residency to preapprove destinations. Test target capacity and image availability before a regional outage; an empty region configuration is not reserved recovery capacity.
Run a recovery exercise
Record the source capture time, restore start, infrastructure readiness, application validation, and service restoration time. Verify the permitted data loss against actual application records. Keep the original backup unchanged.
Run the exercise in an isolated project or network. Disable outbound mail, payment processing, scheduled jobs, and webhooks that would affect production. Remove temporary resources after documenting the result and cleanup IDs.
Return to the primary environment
A recovered application can have new writes that do not exist in the old primary. Use the application's replication or export procedure to reconcile data before switching back. Do not reattach an outdated source volume as if no writes occurred.
For control-plane recovery, follow Control-plane backup and restore. That process restores Infra configuration and identities; it does not replace application backup policies.