# Restore, fail over, and roll back

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

```console
$ one inspect release:sha256:f421…
state degraded
state_provider unreachable
last_durable_checkpoint checkpoint:sha256:91d0…
latest_observation stale by 4m12s
```

## 2. Plan restore as a forward operation

```console
$ 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@1
```

The checkpoint retains lineage, encryption context, schema revision, provider
format, creation receipt, and restore compatibility.

## 3. Apply and resume the same operation

```console
$ one apply plan:revision:sha256:301a…
operation recovery:operation:sha256:77e2…
state awaiting_provider_observation

$ one reconcile recovery:operation:sha256:77e2…
state verifying
```

Unknown provider outcomes are observed before repetition.

## 4. Verify before cutover

```console
$ one inspect recovery:operation:sha256:77e2…
restore receipt:sha256:5a10…
replay through history:cursor:9104
consistency checks passed
application checks passed
traffic cutover ready
```

Failover 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

```console
$ 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.

See [recovery and continuity](/one/lifecycle/recovery).