Failover: cobertura y recuperación por pérdida de nodo

Actualización 21oct, 12:14 CEST: pmx50 arrancó de nuevo a las 11:56:40, boot 558fbd3c…. La nueva lectura confirma quórum, 28 invitados arrancados, 14 recursos HA y réplicas sin error, con la misma distribución. Los boots y tiempos siguientes pertenecen a la muestra anterior: no sirven de guarda para ejecutar una recuperación hoy. Véase el informe actualizado.

Revisión 21 octubre 2026, 10:36–11:06 CEST. Sustituye el inventario y los procedimientos de agosto: no mover configuraciones de invitados ni restaurar sobre sus IDs de producción como respuesta automática a una caída.

La cobertura es parcial: hay recursos HA con recuperación en otro nodo, recursos HA estrictos que esperan al suyo, parejas redundantes y servicios sin HA. Estar running o started no demuestra funcionamiento de la aplicación.

Estado verificado y alcance

Lecturas nativas de sólo lectura en ambos hosts: pvecm status, ha-manager status, API PVE de recursos/afinidades/replicación/invitados y política de datacenter; pvesr status para estado local de réplicas. Hostname y boot se comprobaron antes y después de cada captura:

• pmx50 / proxmox: <REDACTED_UUID>.
• pmx51 / proxmox2: <REDACTED_UUID>.
• Ambos observan quórum 3/3, dos nodos y QDevice; quorum requerido 2.
• CRM master proxmox2 active, fencing armed. LRM de pmx51 active/watchdog active y LRM de pmx50 idle/watchdog standby. Son estados de HA de esa muestra, no una comprobación de cada keepalive hardware ni una explicación de los resets. LRM watchdog standby no significa watchdog hardware desarmado: el mux puede mantener el hardware armado y alimentarlo sin clientes, como explica el análisis del mux.
• 14/14 recursos HA started en pmx51; diez con afinidad preferente por pmx51 y destino permitido pmx50, cuatro estrictos en pmx51.
• 28/28 invitados running: ocho en pmx50 y veinte en pmx51.
• Política efectiva en ambos: shutdown_policy=conditional.
• A las 10:37:13 CEST, pmx51 declara 14 trabajos de réplica habilitados, State OK y FailCount 0 hacia pmx50. Pmx50 no tiene trabajos locales de origen; no significa que falten las réplicas recibidas.

No se ejecutó normalidad, colector, backup, restore, migración, failover, reinicio, probe de producto o acceso al NAS. No se accedió a Home Assistant ni se inspeccionó el trabajo paralelo de Vera. La primera consulta pvesr status --output-format json fue rechazada por opción no soportada: no aportó estado de réplica. Se conserva ese resultado y se usó después la CLI nativa sin esa opción; no fue un fallo de replicación.

Qué se recupera y qué espera

Conjunto actual	Recursos	Si cae su nodo
HA migrable, preferencia pmx51	CT100 Vera, CT123 cloudflared, CT155 WireGuard, CT212 maint, CT213 PocketID, CT214 Vaultwarden, CT215 avisos, CT216 pegamento, CT220 Jellyfin, VM171 Home Assistant	HA puede recuperar en pmx50, sujeto a aislamiento del origen, réplica y capacidad; no son diez servicios activo-activo
HA estricto en pmx51	CT110 TV gateway, CT172 ha-ml, CT217 observabilidad, CT218 personal	No se recuperan automáticamente en pmx50; esperan a pmx51 aunque tengan réplica
Sin HA en pmx50	CT186 PBS, VM208 cómputo/media, CT219 cloudflared2, CT251 RAG, CT270 Caddy primario, CT280 Remote-Pulse, CT281 WP-Pulse, CT305 Homelable	Esperan su recuperación o un plan de recuperación específico; pareja Caddy/conector separada donde existe
Sin HA en pmx51	CT200 n8n, CT204 Pi-hole2, CT271 Caddy secundario, CT301 Warpgate, CT302 Trove, CT303 Argus	Esperan su recuperación; Caddy y DNS tienen pareja fuera de ese nodo

Las afinidades leídas son ha-group-ha-network, con prioridades proxmox:1,proxmox2:2, y ha-solo-51, strict=1, nodo proxmox2. VM171 conserva failback=0: quedarse en pmx50 tras recuperarse no autoriza forzar un retorno. AMD e Intel no proporcionaron migración en vivo fiable en los ensayos documentados; Home Assistant debe moverse en frío.

Réplicas y pérdida de datos posible

Recursos	Calendario configurado	Último sync observado el 21oct
CT212/213/214	Cada 5 minutos	10:35:02–10:35:08
CT100/123/155/215/216/217/218/220 y VM171	Cada 15 minutos	10:30:05–10:30:35
CT172	Cada 30 minutos	10:30:02
CT110	Cada hora	10:00:01

Las edades de todas las filas eran inferiores al intervalo configurado en la captura. El calendario es un objetivo de RPO, no una garantía: ante una caída importa el último sync completado y su consistencia. Réplica no es backup ni protege de borrados o corrupción propagados. Tener réplica de un recurso estricto no levanta su afinidad ni autoriza arrancarlo en otro nodo.

Pérdida de pmx50

El núcleo residente en pmx51 continúa: Home Assistant, identidad, contraseñas, maint, avisos, pegamento, observabilidad y servicios personales no necesitan trasladarse por perder pmx50. Caddy271 y cloudflared123 ofrecen la ruta de entrada redundante si su estado y configuración siguen correctos.

Se interrumpen VM208 y sus aplicaciones, PBS186, Remote-Pulse, RAG y Homelable. WP-Pulse quedó retirado el21oct17:31: CT281 parado/onboot0, sin borrar datos ni copias; no forma parte del conjunto a recuperar automáticamente. Véase la retirada y recuperación manual. El mapa de aplicaciones y propietarios está en distribución de servicios, con sus fechas; no atribuir a VM208 servicios que ya viven en CT217/218/220.

1. Desde el nodo superviviente, leer quórum, HA, tareas y propietarios actuales; guardar fecha/boots. Si no hay quórum o el origen no está aislado, resolver esa condición antes de cualquier arranque en otro nodo.
2. Observar si pmx50 retorna y completa su arranque ordinario. El watchdog ha producido reinicios reales; eso no demuestra causa resuelta ni recuperación funcional de aplicaciones.
3. Comprobar la pareja de acceso por metadatos locales y configuración vigente. Evitar peticiones de productos bajo demanda: Sablier puede despertarlos.
4. Si la pérdida es permanente, preparar recuperación de PBS y de cada servicio con su fuente y almacenamiento reales, IDs de ensayo libres, aislamiento y capacidad comprobada. No restaurar VM208 sobre su ID activo ni trasladarla al Celeron por defecto. Su carga y requisitos no forman parte del N-1 HA.

PBS principal y archivo no deben confundirse: la documentación vigente describe main local y archive sobre loop/ext4 protegido en TerraMaster. Perder pmx50 puede perder acceso al principal local; apuntar otro PBS al NAS no recrea los chunks que sólo estaban en el disco perdido. Antes de restaurar hay que resolver qué datastore sobrevive y qué snapshots completos contiene. Véanse retención actual y estado PBS tras arranque.

Pérdida de pmx51

Pmx50 mantiene sus ocho invitados. La pareja Caddy270/cloudflared219 y el Pi-hole de la RPi pueden mantener entrada y DNS; no sustituyen la autenticación PocketID mientras se recupera su CT. Los diez recursos migrables pueden recuperarse mediante HA, pero los cuatro estrictos y los seis sin HA de pmx51 no tienen esa cobertura.

1. Leer quórum/QDevice y estado HA desde pmx50. Dejar que el gestor HA complete aislamiento y recuperación; no competir moviendo archivos de /etc/pve.
2. Contrastar el presupuesto N-1 actual y caliente antes de ampliar cargas. No levantar afinidades estrictas para aparentar recuperación total.
3. Si la memoria no alcanza, aplicar únicamente el procedimiento manual acotado de N-1: revisar trabajo activo de RAG251/Homelable305 y pérdida aceptable antes de apagado ordenado; medir el margen real después. No usar forceStop, quitar memoria a ciegas o apagar PBS/VM208/entrada como atajo. CT281 queda fuera de esos candidatos.
4. Tras el regreso de pmx51, observar failback y réplicas ordinarias. VM171 puede permanecer deliberadamente en pmx50 por failback=0; no migrarla en vivo. Recursos en error requieren investigar la tarea/causa, no ciclar su estado automáticamente para borrar la evidencia.
5. Confirmar funciones afectadas después de la recuperación, por sus contratos y rutas: HA started, guest running y un healthcheck no prueban login, transacción, reproducción o coherencia de datos.

N-1, tiempos y dependencias

No se ejecutó un ensayo de pérdida de nodo durante esta revisión. Las muestras calientes previas de 19oct dejaron +374 MiB y +828 MiB después de reservar 2 GiB, sin crédito de balloon. No son una nueva medición ni una garantía para picos; los límites de los migrables sumaban 19.328 MiB. No se ha acreditado capacidad N-1 por observar memoria PVE o un arranque en frío. La muestra conjunta de las 11:03 del 21oct mide 13.689,81 MiB RAM+swap de los diez migrables frente a 13.529,87 MiB disponibles en pmx50: −2.207,95 MiB tras reserva de 2 GiB. No pasa el criterio existente; incluye caché/swap y no demuestra OOM inevitable. RAG251/Homelable305 solos no acreditan recuperar ese margen. El informe actual separa la medición operativa de la garantía a límites máximos. Método y límites, ajustes RAM ya aplicados.

Recuperación	Evidencia / expectativa útil	Lo que no está demostrado
Caddy VIP	CT270/271 activos; VIP único en CT270 y configuración activa idéntica a las 10:42	Tiempo actual de failover y cobertura auth/TLS/backend
CT HA migrable	Documentación PVE instalada/ensayos previos sitúan recuperación por caída real en torno a 2–2,5 min	SLA medido hoy o recuperación simultánea con carga máxima
Home Assistant	Recuperación de nodo más arranque del guest: estimación histórica ≈8 min; migración en vivo no fiable	RTO actual de integraciones ni continuidad sin corte
Jellyfin	Migración HA y retorno reales; HLS CPU en pmx50 y VAAPI en pmx51 documentados 19oct	Repetición actual ni tolerancia a pérdida del NAS
PBS/VM208/otros sin HA	Requieren retorno del nodo o restore específico	Los antiguos 25–60 min no son RTO verificado vigente

Router, switch, enlace LAN, alimentación y NAS son dominios de fallo compartidos. Dos DNS no garantizan que cada cliente use ambos; dos túneles no eliminan la dependencia de Cloudflare/Internet; dos Caddy no duplican PocketID ni los backends. QDevice comparte RPi con DNS primario: mantener su recuperación y alimentación independiente forma parte de la continuidad.

La coordinación nueva de SAI sigue desactivada: autonomía/reserva y tiempo de parada nativa no acreditados, guarda Meross sin aplicar por el canal Home Assistant permitido. No se promete apagado/arranque seguro por corte eléctrico con esa propuesta aún pendiente.

Verificaciones y recuperación pendiente

• Restore PBS aislado de CT123 y Paperless real (146 originales y tres PDF) documentados en ensayos. No demuestran restore de todos los guests, de CT217 ni de Immich completo.
• CT217 tiene job y snapshots observados, con sus 16 binds bajo rootfs en la muestra del 20oct; complete_recovery_spec: false y restore pendiente. Cobertura concreta.
• Preparar cada restore con snapshot fechado, recursos/espacio, red realmente aislada y comprobaciones de consistencia de la aplicación; una IP libre en vmbr0 no constituye aislamiento. No ejecutar el antiguo ejemplo de ensayo que arrancaba copias de producción en LAN.
• Reconciliar el drill Caddy con configuración y recuperación actuales antes de programarlo. Parar Caddy es una intervención, no parte de esta lectura; no forzar sync/restart de rutas para inspeccionar.
• Para mantenimiento planificado, usar la consola/procedimiento con preflight estricto y política conditional, no las instrucciones antiguas migrate. Guardas aplicadas.

Evidencia de esta revisión

Proyecciones privadas 0600 bajo directorio 0700 ~/.local/state/ha-coverage-20261021-x92_we4v/; contienen sólo metadata operativa, sin secretos, payloads de backup o configuración de aplicaciones:

Archivo	SHA256
pmx.json	<REDACTED>
pmx2.json	<REDACTED>
pmx-replication-native.json	<REDACTED>
pmx2-replication-native.json	<REDACTED>