Installation Manual - 05d Vault snapshot retention policy

The defined lifecycle and recovery policy for greenfield Vault Raft snapshots.

Vault snapshot retention is now defined after both required proof points passed: the isolated restore drill and the leader failover drill.

Policy

For the current greenfield bootstrap stage:

snapshot schedule: daily at 02:15 UTC;
retention window: 30 days;
bucket: vault-raft-snapshots;
object versions: expire current and noncurrent versions after 30 days;
restore drill cadence: monthly during active buildout, then quarterly;
restore drill trigger: also run after Vault, MinIO, TLS, seal, or snapshot automation changes.

This gives roughly 30 daily recovery points while the platform is still being built. Increase the window before onboarding production workloads with stricter recovery requirements.

MinIO Lifecycle State

The lifecycle policy was applied on 2026-05-14.

MinIO requires delete-marker expiration as a separate rule from day-based expiration. The applied state is:

current object versions expire after 30 days;
noncurrent object versions expire after 30 days;
delete markers expire through a separate enabled rule.

Applied commands:

mc ilm rule add \
  --expire-days 30 \
  --noncurrent-expire-days 30 \
  gf-local/vault-raft-snapshots

mc ilm rule add \
  --expire-delete-marker \
  gf-local/vault-raft-snapshots

Validate the applied rule:

mc ilm rule ls gf-local/vault-raft-snapshots

Expected validation output shows:

one enabled Expiration rule with DAYS TO EXPIRE set to 30;
one enabled NoncurrentVersionExpiration rule with DAYS TO EXPIRE set to 30;
one enabled delete-marker expiration rule.

Production Follow-Up

Before this becomes the long-term production policy, add:

alert when the daily timer fails;
alert when no snapshot exists from the last 26 hours;
alert when restore drill is overdue;
MinIO backup or replication for the object store itself;
Git-driven automation for lifecycle policy management rather than manual mc commands.