La alta disponibilidad en casa tiene una trampa muy tonta: suena a madurez técnica, pero muchas veces es solo una forma cara de no admitir que un buen backup era suficiente.
He caído en esa tentación. Montas varios nodos, ves que el cluster funciona, empiezas a mover máquinas de un lado a otro y de repente la cabeza se va sola: “esto podría estar en HA”. El DNS, Home Assistant, el gestor de contraseñas, el proxy, el panel de monitorización, el servidor de medios, el lector RSS, el bot de Telegram que consulta dos cosas cada tres días. Todo parece candidato cuando tienes martillo de alta disponibilidad.
El problema es que una casa no es un CPD pequeño. Una casa tiene horarios raros, cortes eléctricos absurdos, familia usando servicios sin saber que existen, dispositivos IoT con firmware de dudosa moralidad y una tolerancia bajísima a que el WiFi se comporte raro porque has decidido hacer mantenimiento del cluster un domingo por la noche.
Por eso mi postura actual es más seca: HA solo para lo que de verdad necesita seguir funcionando cuando un nodo cae. Para todo lo demás, backups probados, restauración documentada y menos fantasía.
primero: alta disponibilidad no es backup#
Parece obvio, pero conviene repetirlo porque es el error que más daño hace. HA no protege de borrar datos. No protege de una actualización mala. No protege de una configuración corrupta replicada a todos los nodos. No protege de ransomware. No protege de una base de datos que se rompe por dentro.
HA protege de una cosa concreta: que una carga siga viva o vuelva rápido si falla el sitio donde estaba corriendo.
Eso es útil. Mucho. Pero es otro problema.
Si borro mal una carpeta de fotos y esa carpeta está en almacenamiento compartido, la alta disponibilidad me ayuda a perder las fotos desde más nodos. Precioso, pero poco útil. Si una actualización de Home Assistant rompe una integración crítica, que la VM pueda arrancar en otro nodo no arregla la integración. Si Vaultwarden tiene una base de datos corrupta, mover el servicio no convierte la base de datos en sana.
Antes de pensar en HA, quiero tres cosas más aburridas:
- Backup reciente de los datos.
- Restauración probada en una máquina aparte.
- Una nota clara de qué se levanta primero si todo se va al suelo.
Sin eso, HA es maquillaje técnico. Muy bonito en el dashboard, bastante inútil en el día malo.
qué servicios sí pondría en HA en casa#
Mi lista corta es mucho más pequeña de lo que era hace unos años.
El primer candidato es DNS si depende de mí. Si toda la casa usa Pi-hole, AdGuard Home o un DNS interno para resolver servicios, no quiero que un nodo muerto deje a todo el mundo sin nombres. Pero aquí hay una solución más simple que montar una VM en HA: dos resolvers pequeños, en equipos distintos, anunciados por DHCP. Uno principal y uno secundario. Si el principal cae, la casa sigue navegando. No hace falta convertirlo en una ópera.
El segundo candidato es Home Assistant, pero con matices. Si Home Assistant solo enciende luces decorativas, no necesita HA. Si controla calefacción, sensores importantes, rutinas de noche o automatizaciones que afectan a la convivencia, entonces sí me interesa reducir caída. Aun así, prefiero un diseño que falle de forma segura. Las luces deben poder encenderse desde un interruptor. La calefacción debe tener control manual. La casa no puede depender de que yo haya actualizado bien un contenedor.
El tercer candidato es el gestor de contraseñas, aunque aquí soy conservador. Me importa más tener acceso fuera del homelab que una HA perfecta dentro de casa. Si uso Vaultwarden, necesito backups, exportación controlada, 2FA y una copia de emergencia accesible. Poner la VM en HA ayuda si muere un nodo, pero no sirve si el almacenamiento compartido falla o si me quedo sin acceso a la red. Para contraseñas, la resiliencia real suele estar más cerca de una buena estrategia de recuperación que de un check de HA.
El cuarto candidato es el acceso remoto. Si necesito entrar desde fuera para arreglar cosas, no quiero que todo dependa de una sola VM que casualmente vive en el nodo muerto. Aquí Tailscale, WireGuard o una VPN clásica pueden tener un segundo punto de entrada. No para navegar más rápido, sino para no quedarme fuera de mi propia casa técnica.
Y ya está. Esa es la lista seria.
¿Media server en HA? Normalmente no. Si Jellyfin cae una tarde, se ve otra cosa. ¿RSS en HA? No. ¿Grafana? Me encanta, pero si el dashboard cae no se cae la casa. ¿Repositorios Git? Depende. Si trabajas contra ellos todos los días, quizá. Si son proyectos personales, backup y restauración.
cuándo HA empieza a oler a postureo#
Para mí hay varias señales claras.
La primera: no has restaurado nunca el servicio, pero ya quieres ponerlo en HA. Mala idea. Si no sabes levantarlo desde cero, automatizar su movimiento entre nodos solo añade niebla.
La segunda: el servicio tiene datos delicados y no has probado backup. Esto pasa mucho con fotos, documentos, contraseñas y bases de datos. Nos obsesionamos con que el contenedor arranque en otro sitio, pero no comprobamos si los datos se pueden recuperar limpios.
La tercera: necesitas almacenamiento compartido complejo para proteger algo que podría tolerar una hora de caída. Ceph, NFS, ZFS replicado, iSCSI y compañía tienen su lugar. También tienen mantenimiento. Si metes una dependencia de storage distribuido para que un lector RSS no tenga 20 minutos de caída, algo se ha torcido.
La cuarta: cada mantenimiento requiere pensar demasiado. Una arquitectura doméstica robusta debe ser entendible con sueño. Si tengo que mirar cinco documentos antes de apagar un nodo, probablemente he montado algo demasiado delicado para casa.
La quinta: estás protegiendo servicios que solo usas tú, pero dejas sin cuidar lo que usa la familia. Esto es muy homelab. El panel bonito tiene HA, pero las fotos familiares dependen de un disco sin copia reciente. Batman tendría palabras.
el coste real de poner HA en casa#
La alta disponibilidad tiene costes que no siempre salen en el diagrama.
Consume más. Si quieres que un servicio pueda moverse, necesitas al menos dos máquinas listas, a veces tres si hay quorum de por medio. En mini PCs modernos no es una locura, pero suma. Y suma todos los días.
Complica el almacenamiento. Una VM en un nodo con disco local es fácil de entender. Una VM que puede saltar entre nodos necesita que sus datos estén accesibles desde más de un sitio o que haya replicación. Eso abre preguntas incómodas: qué pasa si la réplica se queda atrás, qué pasa si el storage compartido cae, qué pasa si hay split brain, qué pasa si un snapshot ocupa más de la cuenta.
Complica las actualizaciones. Ya no actualizas “un servidor”. Actualizas un conjunto. Tienes que mirar versiones, estado de cluster, migraciones, storage y orden. No es difícil, pero tampoco es gratis.
Aumenta las formas raras de fallo. Un servicio simple suele fallar de forma simple. Un servicio muy distribuido puede fallar de formas creativas. Y las formas creativas siempre aparecen cuando tienes menos ganas.
También hay un coste mental. Esto no se menciona bastante. Un homelab debería darte placer, aprendizaje y utilidad. Si cada cambio te genera tensión porque no recuerdas cómo encajan las piezas, la arquitectura te está cobrando intereses.
mi regla práctica: caída tolerable contra pérdida tolerable#
Cuando dudo, separo dos preguntas.
Primera: ¿cuánto tiempo puede estar caído este servicio sin que sea un problema real?
Segunda: ¿cuántos datos puedo perder sin que me duela?
La primera pregunta habla de disponibilidad. La segunda habla de backups.
Para DNS, la caída tolerable es muy baja. Si falla, la casa nota cosas raras rápido. Pero los datos son pequeños y fáciles de replicar. Solución: dos resolvers simples.
Para fotos familiares, la caída tolerable puede ser alta. Si Immich no funciona durante unas horas, no pasa nada. Pero la pérdida tolerable es casi cero. Solución: backups fuertes, copias fuera, restauración probada. HA no es lo primero.
Para Home Assistant, depende de qué controle. Si solo agrupa sensores, puede caer. Si gestiona automatizaciones importantes, la caída tolerable baja. Pero tampoco quiero que la casa dependa de una VM perfecta. Solución: diseño manual de respaldo más HA razonable.
Para Jellyfin, la caída tolerable es alta y la pérdida tolerable depende de si puedes reconstruir la biblioteca. En mi caso, no lo pondría en HA salvo que me sobrase todo.
Esta matriz evita muchos caprichos.
HA con Proxmox: útil, pero no mágico#
Proxmox facilita bastante montar HA en casa. Cluster, grupos, recursos, migraciones, watchdog, almacenamiento compartido o replicación. Funciona muy bien cuando lo planteas con cabeza.
Pero hay que entender qué estás prometiendo.
Si una VM está en HA y el nodo muere, Proxmox intentará arrancarla en otro nodo según la política. Para eso necesita quorum, acceso al disco y recursos suficientes. Si todo eso está sano, perfecto. Si el problema es el storage, la VM no va a resucitar por inspiración divina. Si todos los nodos están justos de RAM, quizá arranca donde no debe o no arranca. Si has metido demasiadas cosas críticas en el mismo grupo, puedes convertir una caída parcial en una mudanza bastante fea.
Mi enfoque sería empezar pequeño:
- Un grupo HA para servicios realmente críticos.
- Pocos recursos protegidos.
- Prioridades claras.
- Capacidad libre en los nodos de destino.
- Backups fuera del propio cluster.
Y, sobre todo, pruebas. Apagar un nodo de laboratorio y ver qué ocurre. Migrar una VM. Restaurar desde backup. Medir cuánto tarda. Si no lo has probado, no lo tienes. Tienes una esperanza con interfaz web.
alternativas más simples que HA completa#
No todo necesita cluster.
Para DNS, dos instancias independientes suelen ser mejor que una instancia “perfecta”. Si una cae, la otra responde. No hay drama.
Para servicios web pequeños, un backup de configuración más un compose documentado puede ser suficiente. Si cae el nodo, levantas el servicio en otro host en 15 minutos. No es HA, pero quizá es más que suficiente.
Para datos importantes, snapshots y backups versionados hacen más por ti que una VM migrable. Especialmente si hay una copia fuera del equipo principal.
Para acceso remoto, dos rutas distintas ayudan mucho. Un túnel en una máquina pequeña y una VPN en otro host. No tiene que ser elegante. Tiene que funcionar cuando el nodo bonito está muerto.
Para monitorización, prefiero alertas simples y externas a depender solo de Grafana dentro del mismo cluster que quiero vigilar. Si el cluster muere y también muere la alarma, el dashboard era decoración.
qué haría en un homelab doméstico pequeño#
Si empezase con tres mini PCs y un NAS, no pondría todo en HA.
Pondría DNS en dos sitios. Pondría Home Assistant con backup frecuente y quizá HA si de verdad controla cosas importantes. Tendría una ruta remota secundaria. Haría backups de Vaultwarden, documentos y fotos con más cariño que cualquier otra cosa. Separaría laboratorio de producción. Dejaría media, RSS, descargas, dashboards y pruebas fuera de HA.
También reservaría capacidad. Esto cuesta porque da rabia ver recursos libres. Pero HA sin margen es teatro. Si cada nodo está al 80 por ciento de RAM, cuando uno caiga no tienes alta disponibilidad. Tienes sillas musicales con servidores.
Y documentaría el procedimiento mínimo: qué apagar, qué mirar, qué servicio debe arrancar dónde y cómo restaurar si la automatización no hace su trabajo.
No una novela. Una página.
mi conclusión#
La alta disponibilidad en casa merece la pena cuando protege algo que afecta a la vida real de la casa y cuando no sustituye a los backups. DNS, acceso remoto, alguna pieza de domótica y quizá contraseñas entran en esa conversación. El resto tiene que ganarse el sitio.
Me gusta HA. Técnicamente es interesante y cuando funciona da mucha tranquilidad. Pero también puede convertirse en una excusa para montar una arquitectura más delicada que el problema original.
La pregunta que me hago ahora no es “¿puedo poner esto en HA?”. Casi siempre puedo.
La pregunta buena es otra: “si esto cae durante dos horas, ¿pasa algo serio?”
Si la respuesta es no, backup, documentación y a otra cosa. Hay muchas formas de complicarse la vida. No hace falta pagar electricidad por todas.