Saltar a contenido

Patrón: backup automatizado off-site del Z2M coordinator

Sin este backup, la pérdida del coordinator stick implica re-pair masivo de todos los devices Zigbee. Con el backup, el restore en hardware nuevo es drop-in. Es la diferencia entre "tarde unas horas" y "tarde un fin de semana entero". Patrón cron + rsync sencillo, ~5 min de setup.

Contexto

Cierra el gap "coordinator backup automated" identificado en ../analysis/failure-mode-z2m-coordinator-lost. Es la mitigación más alta-ROI de cualquier failure mode catalogado.

Contenido

Qué se respalda

Archivo Qué es Critical?
coordinator_backup.json Network keys + topology Sí — sin esto, todos los devices necesitan re-pair
database.db State + bindings + groups Sí — sin esto, pierden settings + groups
configuration.yaml Config de Z2M Importante (en git ya, pero replicar)
state.json Last seen states Nice-to-have

Donde están

En HAOS Yellow (Z2M addon): 

/addon_configs/45df7312_zigbee2mqtt/
├── coordinator_backup.json
├── database.db
├── configuration.yaml
└── state.json

(El UUID exacto del addon puede variar. Encontrarlo con ls /addon_configs/.)

Script de backup

Para HAOS Yellow vía SSH & Web Terminal addon:

#!/bin/bash
# /root/scripts/z2m-backup.sh
set -euo pipefail

DATE=$(date +%Y%m%d_%H%M)
BACKUP_DIR=/backup/zigbee
Z2M_DIR=/addon_configs/45df7312_zigbee2mqtt  # ajustar UUID

mkdir -p "$BACKUP_DIR"

# snapshot atómico: archivar todo el dir
tar czf "$BACKUP_DIR/z2m-backup-$DATE.tar.gz" \
  "$Z2M_DIR/coordinator_backup.json" \
  "$Z2M_DIR/database.db" \
  "$Z2M_DIR/configuration.yaml" \
  "$Z2M_DIR/state.json" 2>/dev/null || true

# rsync off-site
rsync -av --delete \
  "$BACKUP_DIR/" \
  user@mini-pc.local:/backup/smart-home/zigbee/

# retention local: 30 días
find "$BACKUP_DIR" -name 'z2m-backup-*.tar.gz' -mtime +30 -delete

Schedule

Cron (en el SSH addon del Yellow): 

# Backup Z2M every night at 3am
0 3 * * * /root/scripts/z2m-backup.sh >> /var/log/z2m-backup.log 2>&1

O mejor, usar la Backup automation de HA que ya existe + agregar este script como add-on hook.

Tests periódicos

Mensual: el agente AI (mes 3+) ejecuta el "restore test":

# en mini-PC, container ephemeral
docker run --rm -v /backup/smart-home/zigbee:/backup \
  -v /tmp/z2m-test:/data \
  --name z2m-restore-test \
  koenkk/zigbee2mqtt:latest \
  bash -c "
    tar xzf /backup/z2m-backup-<latest>.tar.gz -C /data &&
    zigbee2mqtt --help  # verifica que no peta
  "

Si el container inicia y reconoce los files, backup OK.

Para HA Container (mini-PC)

Si Z2M corre en container del mini-PC (no Yellow), el bind mount es directo:

# docker-compose.yml
services:
  zigbee2mqtt:
    volumes:
      - ./zigbee2mqtt-data:/app/data

El backup es tar czf del dir ./zigbee2mqtt-data + rsync a NAS. Más directo aún.

El agente AI

Mes 1: no toca esto. Mes 2+: agente verifica el archivo más reciente del backup. Si > 25 horas (esperamos 24h cycle), alerta. Mes 6+: agente ejecuta el restore test mensual automáticamente, reporta resultado.

Relaciones

Abierto / gaps

  • ¿La estrategia con HA Backup integration automatiza esto out-of-the-box? Probable que sí, validar.
  • Encryption del backup off-site (las network keys son sensitive — Ansible Vault del backup).
  • ¿Quién tiene acceso al backup? Política recomendada: solo el agent + el humano.