Hay días en los que Proxmox te mira con cara de niño bueno. Todo verde, ninguna alarma fea, la interfaz carga rápido y uno empieza a pensar que quizá hoy sí puede tocar cosas sin pagar peaje. A mí ese momento me da exactamente la reacción contraria. Cuando un cluster parece demasiado tranquilo, me obligo a revisar lo básico antes de hacer nada que pueda mover piezas importantes.
Lo digo porque ya he aprendido que el desastre raro casi nunca empieza con una explosión cinematográfica. Empieza con una confianza tonta. Un reinicio que parecía inocente. Una actualización lanzada deprisa. Una VM que mueves de nodo porque sí. Dos minutos después estás preguntándote por qué HA no se comporta como esperabas o por qué Corosync decide ponerse estupendo justo hoy.
Hay una clase de fallo que me parece bastante peor que un error claro. El fallo silencioso. El que no rompe con estruendo, no manda una alarma espectacular y no te deja un log rojo diciendo “esto ha salido mal”. Solo sigue adelante, aparenta normalidad y mientras tanto te está preparando una hostia para más tarde.
Eso fue exactamente lo que me obsesionó con mis backups por NFS. El problema no era que el backup remoto se cayera. Eso puede pasar. El problema era algo más traicionero. El montaje remoto no estaba donde debía, el script aún tenía un camino alternativo local, y la combinación de ambas cosas podía convertir una copia supuestamente segura en un proceso bastante eficiente llenando el disco del host.
Hay una discusión que aparece cada poco en cualquier grupo de Proxmox. LXC o VM. Como si hubiera que casarse con una sola cosa y defenderla hasta el final de los tiempos. Yo hace tiempo que me bajé de esa pelea porque en la práctica no me sirve para nada. En mi homelab uso las dos. Y cuanto más tiempo llevo con Proxmox, más claro tengo que la decisión buena no sale de una religión técnica. Sale de saber qué servicio tienes delante y cuánto castigo te puede devolver si eliges mal.
Hay tecnologías que funcionan tan bien en una demo corta que te hacen pensar que ya has resuelto un problema entero. mDNS es una de ellas. Conectas un dispositivo, aparece con su nombre, abres equipo.local y durante un momento todo parece civilizado. Luego pasa una semana, metes un par de VLANs, pruebas desde otro sistema operativo, intentas usar el mismo nombre desde VPN o desde otra subred, y descubres que el invento no estaba roto. Simplemente estaba resolviendo un problema mucho más pequeño del que tú querías arreglar.
Una de las ideas más engañosas cuando montas un cluster de Proxmox en casa es pensar que repartir cargas significa dejar todos los nodos parecidos. Mismo número de máquinas, memoria parecida, CPU más o menos compensada y una satisfacción estética bastante sospechosa cuando miras la interfaz. Yo he pasado por ahí y no lo recomiendo demasiado.
Con el tiempo he acabado prefiriendo otra cosa. Menos simetría bonita y más intención. Un nodo puede ser el más fuerte y cargar con lo pesado. Otro puede quedarse con servicios persistentes pero tranquilos. Otro puede ser el comodín para mantenimiento, failover o experimentos. Eso, en la práctica, me ha dado un cluster mucho más cómodo que intentar jugar a la igualdad perfecta.
Hay un punto en todo homelab un poco serio en el que un solo servidor deja de tener gracia. No porque no sirva, sino porque se convierte en un cuello de botella para todo. Mantenimiento, pruebas, reinicios, cambios de disco, errores tontos, ganas de experimentar. De repente cualquier cosa toca demasiado. Ahí es donde un cluster de Proxmox empieza a tener sentido.
Yo llevo tiempo con un cluster pequeño de tres nodos y la experiencia me ha convencido de algo bastante concreto. Para casa, tres mini PCs bien elegidos me parecen una de las mejores formas de entrar en clustering de verdad sin irte al absurdo del rack enterprise ni al caos de reciclar hardware que nunca quiso trabajar junto.
Ceph tiene muy buena prensa en el mundo homelab. Es normal. Sobre el papel suena brillante. Almacenamiento distribuido, replicación, tolerancia a fallos, integración muy seria con Proxmox y la sensación de que estás montando algo que se parece a un entorno de verdad. El problema es que, cuando bajas del PowerPoint al salón de casa, Ceph también te recuerda muy rápido que no le importan tus ilusiones.
Yo no lo digo desde fuera. Lo tengo corriendo en un cluster pequeño de Proxmox y me gusta. De hecho, me sigue pareciendo una de las piezas más potentes que puedes montar en casa si sabes muy bien por qué la estás montando. Pero también creo que muchísima gente lo recomienda demasiado pronto, como si fuera el siguiente paso natural después de instalar tres nodos y aprender a pronunciar “quorum” sin pestañear.
Hay una cosa que me sigue haciendo gracia del mundo self-hosted. Montamos infra cada vez más compleja para acabar resolviendo tareas que, en el fondo, se arreglan con dos comandos bien puestos y un poco de criterio. Publicar una web estática es una de ellas.
He probado flujos más elaborados. CI/CD con más capas, builders remotos, pipelines con demasiadas piezas, deploys muy listos sobre el papel y algo menos listos cuando fallan a las dos de la mañana. Al final he vuelto a lo que mejor me funciona para proyectos pequeños y medianos que controlo yo: Hugo para generar el sitio y rsync para dejarlo en el servidor.
Cada pocos meses veo la misma idea repetida en Reddit, YouTube y foros de homelab. Si quieres un servidor de verdad, necesitas Proxmox, Linux, una caja con más bahías que sentido común y, si puede ser, un mini PC chino con cuatro puertos 2.5GbE para sentir que estás en control de tu vida. Me gustan esos cacharros, de hecho tengo varios. Pero hay una verdad menos vistosa: el equipo que más trabajo real me saca adelante sigue siendo un Mac mini M1.
Hace unos días publiqué mi guía base de Tailscale. Ahí contaba por qué dejé de pelearme con WireGuard puro para el acceso diario al homelab. Esa parte sigue siendo cierta. Instalar Tailscale sigue siendo ridículamente fácil. Lo que ya no me parece tan sencillo es diseñarlo bien cuando tu red deja de ser cuatro cacharros y empieza a parecer una pequeña jungla.
Ese es el punto en el que casi todas las guías se quedan cortas. Te enseñan a hacer tailscale up, ves el dispositivo en el panel y te vienes arriba. Luego pasan dos semanas, quieres acceder a un switch que no puede instalar el cliente, quieres sacar internet por casa cuando estás de viaje, o decides que igual no te hace gracia que todos los nodos hablen con todos. Ahí empieza el trabajo real.
El año pasado perdí un disco en mi servidor de almacenamiento. No fue un fallo catastrófico con chispas y humo, fue algo peor: el disco empezó a dar errores intermitentes durante semanas, los datos se corrompieron de forma silenciosa y me di cuenta tarde. Tardé tres días en recuperar todo desde el backup, y eso fue porque tenía backup. Muchos no lo tienen.
Desde entonces uso Scrutiny en todos mis servidores. Es un servicio Docker que recopila los datos S.M.A.R.T. de todos tus discos, los analiza y te manda una alerta cuando detecta valores que deberían preocuparte. No es infalible (los discos pueden fallar sin previo aviso S.M.A.R.T.) pero en mi experiencia la mayoría de fallos vienen precedidos de semanas o meses de señales que S.M.A.R.T. detecta si alguien está mirando.
Cuando monté mi homelab hace unos años, lo primero que quería era acceder a mis servicios desde fuera de casa sin abrir puertos al mundo. Empecé con OpenVPN, que funcionaba pero era una pesadilla de configurar. Luego me pasé a Tailscale, que sigue siendo mi opción favorita para redes mesh complejas. Pero hace unos meses descubrí wg-easy, y para casos simples es lo que uso ahora.
WireGuard en sí lleva años disponible. El problema siempre ha sido la configuración. Generar claves, editar archivos de configuración manualmente, distribuir los perfiles a los clientes… no es complicado, pero tiene fricción suficiente como para que muchos lo dejen a medias. wg-easy resuelve exactamente ese problema: es un contenedor Docker que levanta WireGuard con una interfaz web desde la que puedes gestionar clientes en dos clics.