Immich mola mucho, pero las fotos familiares no son un laboratorio. Antes de venderlo como nube privada hay que preparar backups de verdad y probar cómo se sale del agujero.
La alta disponibilidad en casa suena preciosa hasta que descubres que también duplica mantenimiento, consumo y formas raras de romper cosas. Esta es mi línea roja.
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.
Un homelab serio necesita saber qué se levanta primero cuando todo falla. No por paranoia, sino porque el día malo llega y no conviene improvisar con la casa mirando mal.
El self-hosting tiene una fase de luna de miel peligrosísima. Descubres que puedes montar casi cualquier cosa en Docker, encuentras listas infinitas de “awesome self-hosted” y empiezas a sustituir servicios como quien cambia cromos. Gestor de contraseñas, fotos, notas, RSS, automatizaciones, documentos, bookmarks, monitorización, dashboards, VPN, recetas, PDF, analítica, chat, Git, backups. Todo parece razonable por separado.
Luego pasan unos meses y aparece la factura real. No siempre en euros. La factura llega en actualizaciones, backups, migraciones, bases de datos rotas, logs raros, certificados caducados, móviles que no sincronizan, contenedores abandonados y pequeñas obligaciones que nadie te avisó que venían con el pack de libertad digital.
Si hoy tuviera que montar un homelab pequeño desde cero para una casa normal, no empezaría por Kubernetes. Tampoco por Ceph, alta disponibilidad ni un rack con luces que parezca la cabina de un avión. Empezaría por una pregunta bastante menos sexy: qué datos no quiero perder y qué servicios necesita realmente mi familia.
Esa pregunta cambia todo. El homelab de internet suele estar diseñado para enseñar capturas. El homelab de una casa debería estar diseñado para no molestar, no perder fotos, no romper internet y no convertirse en otro trabajo administrativo. Hay una diferencia enorme entre “quiero aprender infraestructura” y “quiero que las fotos de mi hija estén seguras”. Las dos cosas pueden convivir, pero no deberían tener la misma prioridad.
zfs send y receive convierten snapshots en streams que puedes guardar o enviar a otro servidor. En homelab me sirven para replicar datasets concretos, pero siempre hago primero una prueba seca y reviso nombres, tamaño y destino.
zfs snapshot no sustituye a un backup, pero me da un punto de vuelta local muy cómodo antes de tocar datasets ZFS. La clave está en nombrarlos bien, revisarlos y borrarlos cuando ya no hacen falta.
El almacenamiento en Proxmox tiene una forma especial de mentirte sin mentirte. El panel puede enseñar un storage como configurado, el cluster puede tenerlo definido en /etc/pve/storage.cfg, las VMs pueden apuntar a él y aun así, en un nodo concreto, ese storage puede no estar usable.
Esto se nota mucho en clusters caseros. Tienes discos locales, Ceph o RBD, un PBS, algún recurso CIFS o NFS en el NAS, quizá un local-lvm que solo existe de verdad en algunos nodos. Todo parece ordenado hasta que intentas arrancar una VM, hacer backup o migrar algo y Proxmox te responde con un error que suena mucho más grave de lo que realmente es.
Hay una zona de Proxmox que mucha gente mira solo cuando algo ya ha explotado. Las tareas recientes.
Yo intento mirarlas antes.
Cuando un nodo se comporta raro, una VM aparece apagada, un backup falla o una acción del panel no termina como esperaba, una de las primeras cosas que lanzo es esto.
1 pvesh get /nodes/proxmox-node-3/tasks --limit 12 --output-format yaml Es una forma rápida de preguntarle al nodo qué ha pasado hace poco. No lo que yo creo que pasó. No lo que recuerdo haber tocado mientras tenía tres pestañas abiertas. Lo que Proxmox ha registrado como tarea.
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.
La semana pasada publiqué la guía básica de Vaultwarden. Ahí contaba por qué me compensa más que seguir pagando un gestor alojado por otro y cómo dejarlo funcionando en poco tiempo. Esa parte está bien para arrancar, pero si te quedas ahí te falta lo importante.
Vaultwarden no es un servicio cualquiera. No es un dashboard más, ni un lector RSS, ni una app para ver métricas del NAS. Aquí vives con tus credenciales, tus notas seguras, tus TOTP y en muchos casos la puerta de entrada al resto del homelab. Si esto lo montas regular, el problema no es que falle una tarde. El problema es que estás haciendo malabares con la pieza más sensible de toda tu casa digital.