## TL;DR

Your apply worked, but Terraform could not write the updated state back (the classic trigger: you just destroyed the bucket holding the state). Terraform saved the state locally as `errored.tfstate` instead of losing it. Fix the backend, then `terraform state push errored.tfstate`. Do not just re-apply: that forks the state.

## The error

```text
Error: Failed to persist state to backend

The error shown above has prevented Terraform from writing the updated state to the configured backend. To allow for recovery, the state has been written to the file "errored.tfstate" in the current working directory.

Running "terraform apply" again at this point will create a forked state, making it harder to recover.

To retry writing this state, use the following command:
    terraform state push errored.tfstate
```

## Steps to fix

1. Stop. Do not re-run `apply`. Back up `errored.tfstate` somewhere safe right now.
   - Expected: you have a copy of the post-apply state.
2. Fix the backend: recreate the deleted bucket/table, restore network access, or correct the backend config.
   - Expected: the backend is writable again.
3. Push the saved state:
   ```bash
   terraform state push errored.tfstate
   ```
   - Expected: `state push` succeeds; remote state matches reality.
4. Run `terraform plan` and confirm it shows no unexpected changes.
   - Expected: plan is empty or matches intent; no fork.

## When to use this

- `apply` ends with `Failed to persist state to backend` and an `errored.tfstate` file appears, usually after destroying the state bucket or losing backend connectivity mid-apply.

## When NOT to use this

- `Failed to save state` without the `errored.tfstate` recovery path is the same family; the push step is what is specific to this error. If the backend is fine and only the lock failed, address the lock.

## Compatibility

- All Terraform versions; the `errored.tfstate` recovery flow is long-standing.

## Root cause

Terraform writes state after the apply completes. If the backend disappears mid-run (destroyed bucket, revoked credentials, network drop), the write fails. Rather than lose the record of what was just done, Terraform dumps it locally and tells you exactly how to push it back.

## Edge cases

- Never `terraform destroy` the stack that owns the state bucket without migrating state first; this error is the predictable outcome.
- If someone applied again before you pushed, you have a fork: compare serials, pick the authoritative copy, and push with `-force` only deliberately.
- Keep `errored.tfstate` out of version control; it can contain secrets.