# =============================================================================
# backup-agent-node-02 configuration
#
# Second agent, for the other Docker host. Same image and identity as
# backup/agent, different coverage and a staggered schedule so the two hosts do
# not upload at the same moment.
#
# Every path below was read from the running containers' Mounts via the Portainer
# API on 2026-10-15, not guessed from the compose files ??? these stacks are
# UI-deployed, so the compose files are not the source of truth for what is
# actually mounted.
# =============================================================================

# --- Schedule ---------------------------------------------------------------
# 03:30 ??? an hour offset from node-01's 03:00 avoids two concurrent uploads.
# Verification complete 2026-10-15: the first full archive is
# node02-2026-10-15T00-10-00.tar.zst.age at 3.3 GiB.
#
# ?????? The expression is evaluated in UTC, not in TZ below. Observed, not
# assumed: the "30 3 * * *" runs land at 03:30:00Z in the logs, which is 05:30
# in Europe/Stockholm. The TZ setting does not move the schedule, so read the
# times here as UTC and size the two agents' offsets accordingly.
#
# The pre-migration safety run of 2026-10-16 used a one-shot expression
# ("05 17 * * *") to produce an archive on demand instead of waiting for this
# window. Produced and verified, then reverted:
#   node02-2026-10-16T17-05-00.tar.zst.age  3,866,337,151 bytes
# Verified by streaming that archive through age and zstd into a tar listing
# (both dumps present at /backup/dumps/) and by restoring both of them into
# throwaway clusters ??? see README.md.
BACKUP_CRON_EXPRESSION="30 3 * * *"

# --- Archive shape ----------------------------------------------------------
BACKUP_COMPRESSION="zst"
BACKUP_FILENAME="node02-%Y-%m-%dT%H-%M-%S.{{ .Extension }}"
BACKUP_PRUNING_PREFIX="node02-"
# 7 days, not 14: this host's archive is ~3.3 GiB per run, so 14 days is ~46 GiB
# against a NAS the SeaweedFS filer reports as roughly 30 GB ??? the policy would
# have filled itself. 7 days is ~23 GiB. Longer history belongs offsite (Dropbox),
# not on the primary. Revisit as coverage grows.
BACKUP_RETENTION_DAYS="7"
BACKUP_PRUNING_LEEWAY="30m"

# --- Encryption -------------------------------------------------------------
# Same identity as node-01: one private key decrypts everything.
AGE_PUBLIC_KEYS="age12myl7hsh4vkvg8q2xmx8s0d6jkjlnyhnpg53hs4adxjrlca5f5psw52lgj"

# Label namespace for custom commands ??? see the node-01 .env for the detail.
# Containers here that grow labels must use docker-volume-backup.exec-label=node-02.
EXEC_LABEL="node-02"

# --- Destination: SeaweedFS S3 (via the VPS edge, path style) ---------------
AWS_S3_BUCKET_NAME="backups"
# Distinct path from node-01: pruning is scoped to the target path, so a shared
# path would let one host's retention delete the other's archives.
AWS_S3_PATH="backup-agent/node-02"
AWS_ACCESS_KEY_ID="mildgrim"
AWS_SECRET_ACCESS_KEY="R3dal3rt"
# LAN-direct, and this matters on THIS host more than any other: the agent runs
# on the same machine as SeaweedFS, so this is effectively loopback.
#
# Measured on the first run: the archive built in 38s but the upload was still
# going 6 minutes later, because going via s3.mildgrim.com routes LAN-to-LAN
# traffic out to the VPS and back over WireGuard. That hairpin is fine for small
# payloads and wrong for multi-GB ones. The edge name stays the documented
# fallback if an agent ever runs off-LAN.
#
# GOTCHA: AWS_ENDPOINT is a host authority and dvb never appends a port ??? a bare
# IP silently targets port 80 and the upload fails after the archive is built.
# The port is therefore required here.
AWS_ENDPOINT="192.168.1.16:10000"
AWS_ENDPOINT_PROTO="http"
AWS_ENDPOINT_INSECURE="false"
AWS_PART_SIZE="64"

# --- Notifications ----------------------------------------------------------
# NOTIFICATION_URLS="matrix://user:pass@host:port/?rooms=!room:host"
# NOTIFICATION_LEVEL="error"

# --- Timezone ---------------------------------------------------------------
TZ="Europe/Stockholm"

# --- Notifications: Matrix ---------------------------------------------------
# Used by the notify-matrix service, which watches this host's outbox and speaks
# for every report in it ??? coverage failures, stale archives, missing dumps, and
# the offsite replication's own state. An access token, not a password: supply a
# bot's token, invite the bot to the room, let it post.
MATRIX_HOMESERVER="https://matrix.mildgrim.com"
MATRIX_ACCESS_TOKEN="syt_YmFja3VwLWFnZW50_XHMXwtGmelKBaEoNbbla_4EQqgn"
MATRIX_ROOM_ID="!idzeoRKQdKuUsbnHMV:mildgrim.com"

# When the daily coverage and freshness check runs (UTC). 06:00 is two hours
# after this host's 03:30 agent run, so it judges a completed cycle.
CHECK_TIME="06:00"

# db-backup: connection passwords, referenced as env:// in db-backup.yml
DBB_JOPLIN_PASSWORD=joplin
DBB_MATRIX_PASSWORD=knasigW0rdJakt
DBB_ROMM_PASSWORD=romm_secure_db_pass
