This recipe recovers an orders release without rewriting external history or treating a backup as proof of successful restoration.
The command outputs below are illustrative end-product examples.
1. Inspect the current failure
$ one inspect release:sha256:f421…
state degraded
state_provider unreachable
last_durable_checkpoint checkpoint:sha256:91d0…
latest_observation stale by 4m12s2. Plan restore as a forward operation
$ one plan recovery release:sha256:f421… --checkpoint checkpoint:sha256:91d0…
candidate plan:revision:sha256:301a…
restore_target one.data.postgres#StandbyEu@1
replay_after history:cursor:8821
maximum_data_loss 0s
verification parcelhub.orders#RecoveryQualification@1The checkpoint retains lineage, encryption context, schema revision, provider format, creation receipt, and restore compatibility.
3. Apply and resume the same operation
$ one apply plan:revision:sha256:301a…
operation recovery:operation:sha256:77e2…
state awaiting_provider_observation
$ one reconcile recovery:operation:sha256:77e2…
state verifyingUnknown provider outcomes are observed before repetition.
4. Verify before cutover
$ one inspect recovery:operation:sha256:77e2…
restore receipt:sha256:5a10…
replay through history:cursor:9104
consistency checks passed
application checks passed
traffic cutover readyFailover changes placement and authority under a new plan. It does not rename the standby as the old provider or erase the outage.
5. Roll back an application generation
$ one plan rollback release:sha256:f421… --to generation:sha256:previous…
$ one apply plan:revision:sha256:…Rollback is another governed transition. Data changes that cannot be reversed remain explicit and may require compensation or forward repair.