Skip to content

k8s: snapshot-schedule setup for the ci-build disk#62

Open
jmandel wants to merge 2 commits into
masterfrom
backup/ci-build-disk-snapshots
Open

k8s: snapshot-schedule setup for the ci-build disk#62
jmandel wants to merge 2 commits into
masterfrom
backup/ci-build-disk-snapshots

Conversation

@jmandel

@jmandel jmandel commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

Why

fhir-ci-build-disk holds the published build.fhir.org/ig site (/var/www) and
the SSH upload landing zone, but has no recovery point — a disk loss, corruption,
or an accidental VM/disk delete is currently unrecoverable. (Its only existing
snapshot is a one-off from 2018.)

What

A new idempotent k8s/snapshot-schedule.sh that:

  • creates a daily snapshot schedule (resource policy) in the disk's region
    (us-east1), with a retention window so snapshots auto-expire, and
  • attaches it to fhir-ci-build-disk.

create.sh now points to it next to the disk creation.

Cost is bounded by design

  • Snapshots are incremental + compressed — each stores only blocks changed since
    the previous one, and you're billed on those compressed/used bytes, not the disk's
    1 TB provisioned (or its used) size.
  • The schedule auto-deletes snapshots older than RETENTION_DAYS (default 7),
    so the set never grows unbounded. Steady-state ≈ compressed baseline + retention ×
    daily-delta
    , not N full copies.
  • Snapshots are stored in-region to avoid the multi-region premium.

Tunable via env vars (RETENTION_DAYS, START_TIME, DISKS, PROJECT, REGION,
ZONE). Run it after clearing orphaned staging dirs from ~/uploading (see the
reindex GC) so the baseline snapshot isn't bloated with cruft.

Note: hapi-fhir-org-v3 (project fhir-org-hapi, us-east1) also has no snapshot
policy — an equivalent schedule should be created in that project to protect it too
(out of scope for this repo).

🤖 Generated with Claude Code

jmandel and others added 2 commits June 22, 2026 22:16
fhir-ci-build-disk (build.fhir.org/ig store + upload landing zone) had no recovery
point. Add an idempotent setup script that attaches a daily snapshot schedule with a
retention window, and reference it from create.sh.

Snapshots are incremental + compressed and auto-expire after RETENTION_DAYS (default
7), so cost is ~baseline + retention*daily-delta, not N full copies; stored in-region
to avoid the multi-region premium. Tunable via env vars (RETENTION_DAYS, DISKS, etc).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… broke gcloud filter parsing)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant