Paperless-ngx puede ser una de las mejores piezas de un homelab doméstico, pero solo si dejas de tratarlo como una demo bonita y empiezas a pensar en entrada, búsqueda, copias y recuperación.
Hay una fase bastante común en cualquier homelab. Empiezas con un mini PC, un NAS viejo o una Raspberry Pi. Todo parece razonable. Luego añades otro nodo porque quieres probar Proxmox. Después cae un switch mejor, un SAI, un par de SSDs, quizá un servidor más gordo para almacenamiento o IA local. Un día miras el rack, escuchas el zumbido de fondo y te haces la pregunta incómoda: cuánto cuesta tener todo esto encendido todo el día.
Uso zfs get como lectura segura antes de tocar datasets o discos de VM en Proxmox. Me permite ver propiedades heredadas, valores locales y diferencias que explican comportamientos raros.
Uso zpool status como primera lectura de salud en los nodos Proxmox con ZFS. No arregla nada por sí solo, pero me dice rápido si el pool está sano o si tengo que dejar de mirar VMs y empezar a mirar discos.
No me preocupa actualizar Proxmox. Lo que me preocupa es hacerlo con esa falsa tranquilidad de quien ve cuatro checks verdes y piensa que ya está todo bajo control. En un nodo suelto ya hay margen para liarla. En un cluster pequeño, todavía más. No porque Proxmox sea frágil, sino porque en casa solemos mezclar infra razonable con decisiones que tomamos medio dormidos.
Mi experiencia con esto es bastante simple. Los upgrades salen bien cuando llegas con contexto. Se tuercen cuando entras con prisa, ejecutas apt full-upgrade porque hoy te viene bien y solo después descubres que había un paquete raro, un nodo con quorum justo o una VM donde no tocaba.
Hay comandos que parecen poca cosa y luego te acaban enseñando medio estado del sistema si los lees con un poco de mala leche. pvesm status es uno de esos. Mucha gente lo abre, confirma que hay varios active, ve porcentajes que no dan miedo inmediato y pasa a otra cosa. Yo ya no lo hago así.
Con los años he aprendido que el almacenamiento en Proxmox rara vez te avisa con un único dramatismo limpio. Más bien va dejando señales pequeñas. Un storage que sigue activo pero ya va demasiado lleno. Un local-lvm que aparece inactivo y no sabes si es normal o una chapuza heredada. Un backup server que aún aguanta, pero está más cerca del borde de lo que te gustaría admitir. Nada de eso suena a tragedia instantánea. Precisamente por eso conviene mirar bien.
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.
Hay una fase bastante cutre en casi todo homelab con Proxmox. La de decirte a ti mismo que levantar una VM nueva son cinco minutos y luego echar media hora repitiendo siempre lo mismo. Crear la máquina, montar ISO o importar imagen, tocar red, meter clave SSH, actualizar paquetes, instalar cuatro utilidades, corregir alguna tontería del hostname y cruzar los dedos para no haber dejado un usuario raro o una configuración vieja de otra prueba. No es un drama, pero tampoco es serio.
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.