Saltar a contenido

Runbooks de disaster recovery

Prueba real del "invisible" — si reconstruir desde cero te lleva un weekend, no es invisible. Esta página es el plan para los 8 escenarios que pueden caerte encima, con tiempo-de-recovery objetivo, hardware necesario, procedimiento paso-a-paso. Principio que guía todo: "la casa funciona sin HA". HA es conveniencia, no infrastructure de vida.

Contexto

DR son los runbooks que vos (o el agente) ejecutan cuando algo pasó catastrófico. Son distintos de los failure modes catalogados — éstos son dentro de HA funcionando; DR es HA no funciona. Sin estos runbooks, el día que pase, vas a improvisar mal.

Contenido

Principio rector

La casa funciona sin HA.

Concretamente: - Locks: tenés llave física Y la cerradura abre con thumb-turn por dentro. Si HA falla, podés entrar/salir. - Lights: switches físicos siguen funcionando. Si HA cae, podés prender la luz manualmente. - HVAC: el thermostat tiene programación independiente (no depende de HA para el modo basic). - Smoke/CO detectors: alarmas físicas independientes que no requieren HA. - Water shutoff: válvula manual primaria + electroválvula HA-controlled como auxiliar.

Si tu setup viola alguno de estos, es un risk independiente de DR. Arreglar primero la dependencia física, después optimizar HA.

Los 8 escenarios

Escenario 1 — Power outage corto (<30 min)

Probabilidad: alta (varias veces/año). Severity: bajo. Time-to-recovery: 5-15 min post-power.

Lo que pasa: - Yellow se apaga. - Router/switches se apagan. - ESPHome devices se apagan. - Z2M coordinator pierde state momentáneo.

Recovery (automático): 1. Power vuelve → todo bootea. 2. Yellow inicia (~3 min). 3. Z2M reconecta, devices se re-asocian (5-10 min). 4. Smoke test del agente (cuando esté arriba): ping critical sensors.

Prerequisito: UPS pequeño para router + Yellow ($100-200, autonomía 30-60 min). Sin UPS, todo se cae más bruscamente.

Escenario 2 — Power outage largo (1-24h)

Probabilidad: media (1-2 veces/año típicamente). Severity: medio. Time-to-recovery: minutos tras power.

Diferencia vs corto: la UPS se acabó. HA se apagó "duro" (no shutdown limpio).

Recovery: - Mismo que corto. - Validar: database.db de HA no corrompido (recorder). Si está → restore desde backup. - Validar Z2M database.db no corrompido.

Prerequisito adicional: UPS con shutdown signal a Yellow (NUT integration) que apague HA limpio cuando battery < 20%.

Escenario 3 — Internet down 24h+

Probabilidad: media. Severity: bajo (si setup es local-first). Time-to-recovery: 0 (no rompe el setup).

Lo que pasa: HA Cloud sin acceso. Apps cloud externas fallan. Todo lo local-first sigue funcionando.

Validación de resilience local-first: - ✅ Luces, locks, HVAC: funcionan. - ✅ Automations locales: funcionan. - ⚠️ Notifications Telegram: NO funciona sin internet — fallback a ntfy local server o nada. - ❌ Cloud LLM AI Task: NO funciona — fallback a Ollama local si configurado, sino skip.

Lección: si algo crítico depende de internet, es un design flaw. Identificar y mitigar.

Escenario 4 — HA Yellow eMMC corrupto

Probabilidad: baja pero real (eMMC tiene vida útil). Severity: alto. Time-to-recovery: 2-4 horas con backup verificado y spare hardware, días sin spare.

Lo que pasa: Yellow no bootea. eMMC dead.

Recovery: 1. Apagar Yellow. 2. Si tenés spare hardware (HA Green, RPi 5, mini-PC): a. Flash HAOS al nuevo hardware. b. Initial boot, ir a Onboarding. c. Restore from backup (el más reciente del NAS / Google Drive). d. Tras restore, validar Zigbee: - Si coordinator USB-stick externo: re-conectarlo, Z2M debería ver el mismo network. - Si coordinator integrado al Yellow original: requiere migrar el coordinator_backup.json (ver failure-mode-z2m-coordinator-lost). 3. Si NO tenés spare: - Yellow shipping replacement = días o semanas. - Mientras: mini-PC con HA Container como temporal HA (restore mismo backup). 4. Validar smoke tests: critical sensors respondiendo, automations critical disparando.

Prerequisito clave: - Backup automatizado a NAS o cloud (mínimo daily). - Backup probado mensualmente en restore test (ver coordinator-backup-automated). - Spare hardware si querés < 4h recovery.

Escenario 5 — Mini-PC muere

Probabilidad: baja. Severity: medio (essentials siguen, observabilidad y agente se caen). Time-to-recovery: 1-3 horas con spare, días sin.

Recovery: 1. Yellow sigue funcionando — essentials OK durante la recovery del mini-PC. 2. Spare mini-PC o repurpose hardware: a. Flash Debian. b. ansible-playbook bootstrap-mini-pc.yml (del repo). c. docker compose up -d con configs del repo. 3. Verificar agente reconecta, monitoring vuelve.

Prerequisito: TODO el setup del mini-PC en repo git (Ansible + Compose). Sin esto, recovery toma días.

Escenario 6 — Z2M coordinator muerto

Ver failure-mode-z2m-coordinator-lost — failure mode dedicado. Recovery con backup off-site = drop-in.

Escenario 7 — Catastrophic: house fire / robo / disaster total

Probabilidad: baja-baja. Severity: extremo. Time-to-recovery: semanas-meses.

Lo que pasa: hardware perdido completamente. Posiblemente network también.

Recovery: 1. Backups off-site (NAS robado/quemado no cuenta — necesitás cloud o casa de familia). 2. Reconstruir hardware completo. 3. Re-flash + restore del último backup cloud. 4. Re-comprar devices Zigbee/BLE (probable también perdidos). 5. Re-pair masivo.

Estado realista: el setup completo se pierde. Recovery = nuevo proyecto.

Mitigación: cloud backup en proveedor distinto al país (Google Drive, S3 distinto bucket, etc.). Sin esto, recovery imposible.

Escenario 8 — Configuration error / corrupción de repo

Probabilidad: media (vos lo causás). Severity: bajo si tenés git. Time-to-recovery: minutos.

Lo que pasa: pusiste algo malo, HA no arranca o automations rotas.

Recovery: 1. git revert <commit> o git checkout HEAD~1 -- <file>. 2. ansible-playbook -e mode=set sync-ha.yml (vía bellackn role). 3. Restart HA. 4. Funciona.

Prerequisito: everything-is-code aplicado. Sin git, no hay revert; estás como antes de git en cualquier producto.

Tabla resumen: time-to-recovery targets

Escenario Probabilidad Severity Target TTR Prerequisito
1. Power < 30 min Alta Bajo 15 min auto UPS opcional
2. Power > 1h Media Medio 30 min post UPS + NUT
3. Internet 24h+ Media Bajo 0 (no rompe) Local-first audit
4. Yellow eMMC dead Baja Alto 2-4h con spare Backup verified + spare
5. Mini-PC dead Baja Medio 1-3h con spare Ansible repo
6. Z2M coordinator Baja Medio 1-2h Backup + spare stick
7. Catastrophic loss Muy baja Extremo Semanas Cloud backup off-country
8. Config error Media Bajo 5-10 min git + bellackn role

Hardware spare strategy

Item Por qué tener spare Costo
Z2M coordinator stick El más probable de fallar, drop-in replacement $30
UPS (router + Yellow) Escenarios 1-2 $100-200
Mini-PC capable de HAOS Escenario 4 emergency $200-400 (puede ser el mismo del experimental tier que ya hay)
Batteries de devices críticos Escenario "battery murió en el momento equivocado" $20-50
Cable Ethernet de emergencia Si WiFi falla $5

Para tu setup específico ya recomendado: - Mini-PC del install-method-decision-2026 ES el spare del Yellow simultáneamente. - 1 coordinator de prueba (de la lista de compras priorizadas) ES el spare Z2M.

Eficiencia: spare strategy ya está implícita en la arquitectura propuesta.

Testing periódico (no opcional)

Test Frecuencia Procedimiento
Restore test backup HA Mensual Container ephemeral con backup montado, verificar boot
Restore test Z2M coordinator Mensual Mismo, con coordinator_backup.json
Power outage drill Trimestral Desenchufar UPS, ver autonomía + recovery
Spare hardware test Semestral Flash + restore en spare, verificar funciona
Full DR drill Anual Simular escenario 4 completo, medir TTR real

Sin testing, los runbooks son ficción. La cita de la fuente: "Backups that you have never actually restored from are not backups, they are just wishful thinking with a progress bar."

El agente AI en DR

Acción del agente Cuándo Autoridad
Detect power outage (smart plug del router cae) Escenario 1-2 Reporta a daily digest
Detect Yellow unreachable Escenario 4 Tier 1 alert, NO actúa solo
Restore desde backup Escenarios 4-6 Nunca autónomo — pide approval
Monitor recovery progress Todos Reporta milestones
Auto-trigger fail-safe (ej. shut water valve) Escenario "agua detectada + humano no responde" Sí, por escalation, con timeout y ack window

Relaciones

Citas / evidencia

Abierto / gaps

  • UPS específico recomendado para Yellow (modelo + autonomía calculada).
  • Cloud backup provider: Google Drive vs S3 vs Backblaze (cost + reliability comparison).
  • Runbook concreto del Yellow flash desde 0 — pasos exactos para tu hardware específico.
  • Patrón de "spare mini-PC kept cold" vs "spare mini-PC en uso" (el twin).