# =============================================================================
# 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.
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"
