Skip to content

ZFS snapshots DB (docker5): snapshoty se netvoří / selhaly

Kdy to pípá

  • Alert: “Snapshot job failed”, “No snapshot created in last X hours”, nebo restore point chybí.

Dopad

  • Zhoršení RPO pro databáze běžící na docker5 (kritická data bez lokální rollback možnosti).

Priorita

  • P0: snapshoty chybí > 24h pro kritické DB.
  • P1: snapshoty chybí > 6h nebo opakovaný failure.
  • P2: jednorázové selhání, další běh OK.

Rychlá kontrola (do 5 minut)

1) Na docker5 ověř poslední snapshoty datasetu: - zfs list -t snapshot | head - filtrem na dataset DB (pokud používáš naming konvenci) 2) Ověř volné místo na poolu: - zfs list - zpool list 3) Ověř, zda běží plánovač (cron/systemd timer), který snapshoty dělá.

Diagnostika

  • Zjisti přesný mechanismus snapshotu:
  • cron job / systemd timer / script / TrueNAS-side snapshot task
  • Najdi logy:
  • journalctl pro timer/service
  • výstup ze scriptu
  • Typické příčiny:
  • pool/dataset je read-only
  • chybí místo
  • zfs dataset rename/mountpoint změna
  • práva nebo path mismatch
  • skript failuje na non-zero exit

Náprava

1) Pokud je problém volné místo: - provést cleanup (prune starých snapshotů dle retention) 2) Pokud je read-only / I/O: - eskaluj na TrueNAS storage runbook 3) Pokud je rozbitý scheduler: - obnov systemd timer / cron entry 4) Pokud se změnil dataset/mount: - upravit konfiguraci snapshot skriptu (target dataset) - doplnit guard: “fail fast” + alert s názvem datasetu

Ověření

  • Vynucený ruční snapshot projde:
  • zfs snapshot <dataset>@manual-test-YYYYMMDD-HHMM
  • Další plánovaný běh vytvoří snapshot.
  • Alert se srovná po definované době.

Prevence / follow-up

  • Alert “age of newest snapshot” per dataset.
  • Retention politika a kapacitní headroom.
  • Po změně mount/dataset vždy update runbook + konfigurace.

Odkazy

  • (doplň: cesta na skript / timer unit / repo)