platform/docs/adr/0005-zfs-per-customer.md
Bart Van Geyt 9f819df4d9 Phase 0: architecture docs, ADRs, and repo scaffold
Establish the design foundation for the heleosv2 multi-tenant hosting
platform before any implementation code:

- Monorepo skeleton: docs/, platform-infra/, site-templates/,
  deployments/, control-panel/ with orientation READMEs.
- docs/: roadmap index, architecture + threat model, naming conventions,
  site profiles, provisioning workflow, backup & DR runbook, repo/GitOps
  layout, and the approved architecture plan.
- docs/adr/: 9 ADRs recording the rationale for single-host Compose,
  Traefik edge, nginx+fpm split, shared MariaDB, ZFS-per-customer,
  decoupled backup streams, Forgejo, CLI-first, and SFTP-only.
- Secrets hygiene: .gitignore (only *.enc.* committed) and .gitattributes
  (LF for scripts/Dockerfiles/YAML run on the Linux host).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 12:26:00 +02:00

1.1 KiB

ADR 0005 — ZFS dataset per customer

Status: Accepted

Context

Backups must be cheap, integrity-checked, and restorable per customer without touching neighbours. ZFS offers checksummed integrity, cheap copy-on-write snapshots, and incremental zfs send.

Decision

Create a ZFS dataset per customer (tank/customers/<customer>/web) holding only the web root. Docker image/layer storage and the MariaDB datadir live on separate platform datasets. Customer web data is bind-mounted into containers from the customer dataset.

Consequences

  • Snapshot and zfs send operate at the customer granularity — restore one customer independently.
  • Data integrity via checksums; cheap frequent snapshots.
  • Keeping the dataset to web files only (no logs, no DB dumps) means an unchanged site produces a near-empty incremental, keeping offsite send cheap — the explicit reason logs and DB dumps are stored elsewhere (ADR 0006).
  • Ties the platform to a ZFS-capable host (OpenZFS on Linux); not portable to arbitrary cloud block storage without rework.