# Infrastructure config snapshots

Snapshot `/etc`, Terraform state, and other infrastructure configuration to a
store, and use the recorded chain of snapshot IDs — `revisions` and `ancestors`
— as an ordered, verifiable audit trail of how the configuration changed.

## The problem

Infrastructure configuration drifts. Someone hand-edits `/etc` on a host during
an incident, Terraform state diverges from the committed plan, and three months
later nobody can say what the config looked like on the day an outage began — or
prove that the rollback target is genuinely the last known-good state. Ad-hoc
tarballs in a bucket answer none of this: they are not deduplicated, not
integrity-checked, and carry no relationship to one another, so reconstructing
"what changed, in what order" is archaeology.

## Why snapdir

Each configuration snapshot is a content-addressed ID, and snapdir records the
relationships between them so the history is queryable:

- **Tamper-evident points in time.** A snapshot ID is the BLAKE3 hash of the
  config's [manifest](../concepts/manifests.md); any change to any file yields a
  different ID, so a snapshot cannot be silently altered.
- **An ordered audit trail.** [`snapdir revisions`](../guide/history.md) lists the
  snapshot IDs recorded at a location, and
  [`snapdir ancestors`](../guide/history.md) traces a snapshot's lineage and where
  each ancestor lives — a defensible record of how the configuration evolved.
- **Cheap to keep often.** Objects are
  [content-addressed](../concepts/content-addressing.md) and deduplicated, so
  snapshotting `/etc` hourly costs only the bytes that changed.

## Walkthrough

Snapshot a host's configuration to a store, excluding noise you do not want to
capture, and record the ID:

```sh
cfg_id=$(snapdir push --store s3://infra-audit/etc --exclude '\.cache/|/tmp/' /etc)
echo "$cfg_id"
```

Do the same for Terraform/IaC state so plan and applied state are both captured
as points in time:

```sh
snapdir push --store s3://infra-audit/tfstate ./terraform
```

Later, review the audit trail. List the snapshot IDs recorded at a location, then
trace one snapshot's lineage to see what came before it and where each ancestor
is stored:

```sh
snapdir revisions --location s3://infra-audit/etc
snapdir ancestors --id "$cfg_id"
```

When you need to roll back, restore a known-good snapshot into place and verify it
end-to-end:

```sh
snapdir pull   --store s3://infra-audit/etc --id "$cfg_id" ./etc-restore
snapdir verify --store s3://infra-audit/etc --id "$cfg_id"
```

## Outcome

Configuration becomes a series of tamper-evident, deduplicated snapshots with a
queryable history: you can show exactly what `/etc` or your IaC state contained
at any recorded point, prove it has not been altered, and trace the ordered chain
of changes with `revisions` and `ancestors`. Rollback targets are verifiable
known-good states rather than best guesses. See
[History](../guide/history.md) for navigating the recorded trail.