Documentación de los modos de fallo de los sistemas críticos de SmallCountry. Para cada sistema se describe qué pasa si cae, qué se degrada, qué sigue funcionando, cómo se recupera y qué dependencias rompe.
Esta página es complementaria a las Matrices de Resiliencia y a los Runbooks de Emergencia. Mientras las matrices muestran el impacto global de un escenario, esta página detalla el modo de fallo de cada sistema individual.
Nadie puede iniciar sesión en ningún servicio protegido por forward-auth (Nextcloud, Immich, Matrix, Grafana, Forgejo, farmOS, etc.). Las sesiones existentes caducan en un máximo de 24 horas.
¿Qué se degrada?
Caddy sigue funcionando pero no puede validar sesiones. Los servicios sin autenticación (Jitsi, ntfy, Uptime Kuma, Mosquitto) siguen accesibles.
El Protocolo de Mortalidad define la recuperación completa desde backup de PostgreSQL + repositorio Ansible. Tiempo: <15 minutos. Procedimiento: restaurar dataset ZFS rpool/datos/authentik del último snapshot, ejecutar playbook deploy-authentik.yml.
¿Qué dependencias rompe?
Rompe el acceso a ~25 servicios con SSO. No rompe servicios de infraestructura, sensores ni MQTT.
Todos los LXC de Ra (~42 contenedores) se detienen. Todos los servicios de usuario, identidad y la mayoría de servicios de infraestructura dejan de funcionar.
¿Qué se degrada?
Horus, Geb y Thoth siguen operando con sus servicios locales. La finca (Garganta la Olla) funciona autónomamente con Geb + sensores. Los backups offsite en Thoth están a salvo.
¿Qué sigue funcionando?
Horus (IA local), Geb (energía y sensores de campo), Thoth (backup offsite). Servicios en Horus: Ollama, Open WebUI, Whisper. Servicios en Geb: MPPT, batería, MQTT local, Shelly.
¿Cómo se recupera?
Si es fallo de hardware: sustituir N100 por hardware de repuesto, reinstalar Proxmox desde ISO, importar pool ZFS, ejecutar deploy-all.yml de Ansible. Tiempo: <2 horas. Si es fallo de software: reiniciar Proxmox, verificar ZFS, iniciar LXC desde snapshot. Tiempo: <15 minutos.
¿Qué dependencias rompe?
Rompe todos los servicios alojados en Ra. No rompe los servicios en Horus, Geb ni Thoth.
Corrupción del pool ZFS significa pérdida de datos si no hay backups. Con backups 3-2-1, la pérdida se limita al delta desde el último snapshot (máximo 15 minutos).
¿Qué se degrada?
Si el pool falla por corrupción de metadatos: los LXC siguen corriendo en memoria pero cualquier escritura falla. Lectura puede fallar para bloques corruptos.
¿Qué sigue funcionando?
Si solo falla el pool rpool: Horus, Geb, Thoth y sus datos siguen intactos. El pool hddpool puede seguir accesible si el fallo es aislado.
¿Cómo se recupera?
1) Identificar el dataset corrupto con zpool status -v. 2) Si es recuperable: zfs rollback al último snapshot bueno. 3) Si el pool entero está corrupto: recrear pool, restaurar desde PBS (datos de LXC) y Restic (datos de aplicación). Tiempo: 30 min a 4 horas según volumen.
¿Qué dependencias rompe?
Rompe todos los servicios que dependen de almacenamiento persistente en Ra (~42 servicios).
El dominio .sc deja de resolverse. Los servicios siguen siendo accesibles por IP, pero todas las URLs del tipo servicio.sc fallan. Caddy no puede enrutar por nombre de host.
¿Qué se degrada?
Navegación por nombre de dominio. Comunicación entre servicios que usan nombres .sc en lugar de IPs.
¿Qué sigue funcionando?
Todo sigue funcionando si se accede por IP. Los administradores pueden usar IPs directas. Proxmox, SSH y Ansible usan IPs, no nombres.
¿Cómo se recupera?
1) Reiniciar Pi-hole: systemctl restart pihole-FTL. 2) Si no arranca: restaurar desde backup de configuración en /etc/pihole/. 3) Plan B de emergencia: añadir registros manualmente en /etc/hosts de los clientes. Tiempo: <2 minutos (reinicio), <10 minutos (restauración).
¿Qué dependencias rompe?
Rompe la resolución de nombres .sc. La comunicación por IP sigue intacta.
El bus IoT se silencia. Los sensores ESP32 no pueden publicar datos. Node-RED no recibe eventos del mundo físico. Las automatizaciones de campo se detienen.
¿Qué se degrada?
Monitorización de la finca en tiempo real. Automatizaciones que dependen de sensores (riego, alertas de colmena, control de gallinero).
¿Qué sigue funcionando?
Todos los servicios de usuario, identidad, almacenamiento y media. La telemetría de infraestructura (Prometheus → VictoriaMetrics) no usa MQTT. Los ESP32 acumulan datos en buffer local. La bomba del sótano tiene camino alternativo vía Shelly HTTP.
¿Cómo se recupera?
Reiniciar Mosquitto: systemctl restart mosquitto. Los ESP32 se reconectan automáticamente y envían los datos acumulados. Tiempo: <1 minuto (reinicio), <5 minutos (drenaje del buffer de sensores).
¿Qué dependencias rompe?
Node-RED (flujos MQTT), Grafana (dashboards de campo), Geb (publicación MQTT), Shelly (control MQTT). No rompe servicios de usuario.
Ningún servicio es accesible vía HTTPS desde el exterior ni desde la red local por nombre de dominio. Los servicios en sí siguen corriendo pero son inalcanzables.
¿Qué se degrada?
Acceso web a todos los servicios. Las aplicaciones móviles que usan la API directamente (Immich app, Joplin) dejan de sincronizar.
20+ servicios pierden su backend de base de datos. Authentik no puede validar sesiones (usa Redis para caché pero PostgreSQL para datos). Nextcloud, Immich, Matrix, Forgejo, farmOS, n8n dejan de funcionar.
¿Qué se degrada?
Todos los servicios que dependen de PostgreSQL. Los que usan SQLite o Redis (Grafana, Pi-hole) no se ven afectados.
1) Verificar logs: journalctl -u postgresql. 2) Si es fallo de disco: zfs rollback rpool/datos/postgresql. 3) ⚠️ Réplica en Horus no implementada (prevista Q4 2026). Mientras tanto, restaurar desde PBS (RTO: 30min-4h).. 4) Restaurar desde backup PBS. Tiempo: 5-30 minutos según método.
¿Qué dependencias rompe?
~22 servicios. Los servicios de campo (sensores, MQTT, Node-RED) y la infraestructura base no dependen de PostgreSQL.
Se detienen todas las automatizaciones en tiempo real. Sin alertas de colmena, sin riego automático, sin control de gallinero, sin modo tormenta, sin gestión de perfiles energéticos.
¿Qué se degrada?
La capa de reacción automática del sistema. Las personas reciben menos notificaciones y deben actuar manualmente.
¿Qué sigue funcionando?
Los sensores siguen recolectando datos (Mosquitto + ESP32 independientes). n8n sigue ejecutando flujos de trabajo programados. Todos los servicios de usuario funcionan.
Automatizaciones de campo y energía. No rompe la recolección de datos (ESP32 → Mosquitto → VictoriaMetrics sigue sin Node-RED si se configura scrape directo).
Se pierde la telemetría energética en tiempo real. Node-RED deja de recibir datos de MPPT, batería e inversor. Las automatizaciones de perfil energético se detienen.
¿Qué se degrada?
Monitorización y gestión automática de la energía. Los dashboards de energía en Grafana se vacían. Las transiciones entre perfiles (Normal → Ahorro → Emergencia) dejan de ser automáticas.
¿Qué sigue funcionando?
El hardware energético funciona autónomamente: paneles → MPPT → batería → inversor. La batería se carga y descarga sin necesidad de Cerbo GX. La bomba del sótano, si está en Shelly local, sigue funcionando.
¿Cómo se recupera?
1) Reiniciar Geb: ciclo de alimentación. 2) Verificar conectividad de red. 3) Si fallo de hardware: el MPPT y el inversor siguen operando sin Cerbo GX. Sustituir unidad. Tiempo: 5 minutos (reinicio), días (sustitución hardware).
¿Qué dependencias rompe?
Node-RED (flujos energéticos), Grafana (dashboards de energía), n8n (informes energéticos). El suministro eléctrico no se interrumpe.
Sin inferencia de lenguaje. Hermes Agent no puede responder. Open WebUI muestra error de conexión. La transcripción clínica se queda sin análisis. Continue.dev no funciona.
¿Qué se degrada?
Todas las funciones de IA. La entrada por voz (Whisper) puede seguir funcionando si está en su propio LXC.
¿Qué sigue funcionando?
Absolutamente todo excepto las funciones de IA. La IA es un aumentador, no un requisito. Ningún servicio Tier B o superior depende de Ollama.
¿Cómo se recupera?
1) Verificar GPU disponible: nvidia-smi. 2) Reiniciar Ollama: systemctl restart ollama. 3) Recargar modelo: ollama pull llama3.1:8b. 4) Si fallo de GPU: Ollama puede correr en CPU (más lento). Tiempo: <2 minutos (reinicio), 10-20 minutos (recarga de modelo).
¿Qué dependencias rompe?
Hermes Agent, Open WebUI, Continue.dev, Sherlog, flujo de transcripción clínica.
SmallCountry. Para cada sistema se describe qué pasa si cae, qué se degrada, qué sigue funcionando, cómo se recupera y qué dependencias rompe.