traveler 0f82f39fdd final

2026-04-12 16:06:16 -05:00

2.2 KiB

Raw Blame History

title	description	published	date	tags	editor	dateCreated
Vault Grimoire	Storage and backup — the dragon guards the data hoard	true	2026-04-12T00:00:00.000Z	vault, storage, backup	markdown	2026-04-12T00:00:00.000Z

Vault Grimoire

The Vault Grimoire covers all storage and backup infrastructure. Data starts at znas, is deduplicated and encrypted by Kopia, and replicates offsite to two Pi vault nodes — one dedicated vault Pi and one inside Pocket Grimoire.

Sections

Section	Contents
ZFS	ZFS pools, datasets, NFS exports, commands reference
Kopia	Backup repos, retention, restore, two-repo architecture
Backups	Per-service backup runbooks (Immich, MailCow, Nextcloud, Wiki, services)
Offsite	Pi vault nodes, ZFS raw send, syncoid workflow

Offsite Vault Architecture

znas (primary)
  └── ZFS pool → Kopia dedup → encrypted repo
        ├── syncoid -w → Pi Vault (dedicated offsite)
        └── syncoid     → Pocket Grimoire (portable vault node)

Both offsite nodes receive ZFS raw send with the -w flag. Encryption keys stay on znas. The vault nodes store encrypted data only — no keys needed there.

Two-Repo Architecture

Kopia uses two separate containers on different ports:

Container	Repo	URL	Purpose
kopia	Primary vault	`kopia.netgrimoire.com`	Main backup, dedup, retention
vault	Offsite server	`vault.netgrimoire.com` (port 51516)	Replication target for Pi vaults

One Kopia server instance per repository. They cannot share.

Key Rules

ZFS encryption cannot be done in-place. Migration requires rsync to a new encrypted dataset, then ZFS raw send with -w to vaults (no key exposure on vault side).
ZFS must fully mount before NFS starts on znas. Systemd override required: After=zfs-import.target zfs-mount.service.
Loopback NFS mount needs x-systemd.after=nfs-server.service in fstab.

2.2 KiB Raw Blame History