Backups en Proxmox sin frustraciones: un script de la comunidad

Proxmox Backup Server puede utilizar almacenamiento respaldado por un LUN iSCSI de Synology, y un script creado por la comunidad intenta simplificar la conexión inicial y su configuración. Esto reduce el trabajo manual repetitivo, pero no sustituye una prueba real de recuperación ni una decisión informada sobre los dominios de fallo del almacenamiento.

El proyecto publicado pbs-synology-iscsi propone una configuración guiada de iSCSI y CHAP. El debate que surgió a su alrededor se centró menos en si el script funciona y más en si NFS, el almacenamiento local en PBS o iSCSI representa la arquitectura más sencilla a largo plazo.

¿Por qué usar iSCSI de Synology para Proxmox Backup Server?

El iSCSI de Synology puede presentar almacenamiento en bloque a un host dedicado de PBS, evitando algunos de los problemas de permisos en carpetas compartidas que complicaban este entorno.

El autor, conocido como MorphyDK, describió su frustración constante al usar NFS como almacenamiento para PBS sobre Synology. No se trataba de un fallo catastrófico de disco ni de backups desaparecidos misteriosamente. Era la molestia constante de los permisos y ajustes que hacían que cada instalación limpia fuera innecesariamente engorrosa. Quien mantenga un homelab conoce bien esa fricción. Algo funciona, pero cuando quieres replicarlo meses después tienes que reconstruir decisiones olvidadas. El sistema de backup pasa a ser un elemento más que requiere reparaciones, una situación bastante irritante cuando su única misión es facilitar la recuperación.

Antes de decidirte por un protocolo de destino, revisa una Proxmox backup strategy más amplia que incluya copias fuera del host y restauraciones.

El punto de inflexión llegó al encontrar el enfoque de Derek Seaman para conectar un LUN iSCSI a un host de Proxmox Backup Server. MorphyDK lo probó y comprobó que funcionaba. Esa distinción es importante: la idea de usar iSCSI no se presentó como un invento nuevo desde cero. El autor reconoció abiertamente el trabajo de Derek como punto de partida y se centró en hacer el proceso más accesible. En lugar de volver una y otra vez a una lista de comandos y notas dispersas, buscaba una configuración guiada con menús, colores, detección de discos y opciones claras. El objetivo era resolver la repetición tanto como el almacenamiento: menos investigación manual, menos pasos olvidados y una instalación que cualquier usuario de homelab pudiera intentar con tranquilidad.

Detrás de este debate hay una diferencia técnica real. NFS expone un recurso compartido de red, introduciendo la propiedad de archivos y el control de accesos en la relación entre PBS y el NAS. Por su parte, iSCSI entrega almacenamiento en bloque a la máquina con PBS, donde un sistema de archivos Linux adecuado aloja el datastore. La official PBS storage documentation describe los datastores como directorios sobre sistemas de archivos estándar de Unix, como ext4, XFS o ZFS. Esto no convierte a iSCSI en una solución universalmente superior ni elimina todos los fallos posibles, pero sí cambia dónde se gestiona el sistema de archivos. Por eso, para quien esté cansado de lidiar con permisos en NFS, la alternativa resulta tentadora. La cuestión práctica es si ese cambio hace que tu entorno específico sea más fácil de operar.

¿Qué automatiza el script de Synology iSCSI para PBS?

El repositorio describe un flujo de trabajo asistido para configurar el destino iSCSI y la autenticación sin repetir pasos manuales.

El published project va más allá de un menú colorido. Su repositorio detalla la configuración guiada de destinos iSCSI con autenticación CHAP, inspección previa del almacenamiento y la capacidad de reconocer y volver a conectar un datastore existente de PBS en lugar de borrarlo sin avisar. También incluye tareas posteriores a la instalación, como ajustes en repositorios, actualizaciones del sistema, supervisión de recuperación de montajes y programación de trim. Estas son las funciones documentadas por el autor, no una garantía de que cada ruta funcione a la perfección en cualquier máquina. Con todo, la intención es evidente: el script busca transformar una serie de pasos del sistema operativo y del almacenamiento que se olvidan con facilidad en un procedimiento repetible. Para quien ya ha rehecho esta configuración varias veces, es una meta muy razonable.

Una promesa especialmente relevante es lo que ocurre cuando la herramienta encuentra datos previos. El almacenamiento de backups es el peor sitio para que un script asuma cosas por su cuenta. El repositorio indica que el instalador revisa los discos e intenta conservar y reconectar cualquier datastore existente que detecte. Esto merece atención, porque un buen instalador debe saber cuándo la decisión correcta es no tocar nada. Aun así, la descripción de un README no sustituye revisar el código ni probar las ramas destructivas en un entorno seguro. El proyecto también ofrece un comando de shell directo que descarga y ejecuta el script al vuelo. ¿Es cómodo? Desde luego. ¿Conviene ejecutarlo a ciegas sobre la única copia de backups irreemplazables? Eso cuesta mucho más recomendarlo.

El autor también reconoció que utilizó bastante ayuda de Claude AI. Esa aclaración no hace que el código sea malo por defecto, igual que programar cada línea a mano tampoco lo hace seguro automáticamente. Pero sí plantea dudas legítimas sobre la revisión y las pruebas, sobre todo cuando hay particionado, montajes, actualizaciones y autenticación de por medio. En este punto, la colaboración humana en las respuestas aportó un contrapeso positivo. El propio Derek intervino y se ofreció a integrar los cambios mediante una pull request, y MorphyDK continuó la conversación en privado. Una herramienta nacida de una molestia personal terminó captando el interés del creador del método original. Así es como las pequeñas utilidades de infraestructura acaban siendo útiles para más gente, siempre que el mantenimiento y la supervisión crezcan al mismo ritmo que la comodidad.

¿Es más simple NFS o iSCSI para las copias de Proxmox?

Ni NFS ni iSCSI son siempre más sencillos; la mejor alternativa depende de cómo se gestione, monte, supervise y restaure el datastore.

No todos los participantes querían un instalador de iSCSI más elaborado. Un usuario explicó que instala PBS directamente en el servidor de almacenamiento, eliminando por completo la necesidad de conectar discos a través de NFS, iSCSI o SMB. Otro sugirió una guía para ejecutar PBS como máquina virtual dentro de Synology. Varios compartieron experiencias con hardware de Synology más antiguo: recordaron que un DS1815+ funcionaba bastante bien con PBS, mientras que otro usuario con un RS820 comentó que su configuración era totalmente fiable, aunque no batiera récords de velocidad. Esta última observación quizá sea el criterio más sensato de toda la conversación. Cuando el trabajo consiste en proteger una red doméstica, la previsibilidad de los backups importa más que unas gráficas de rendimiento impresionantes.

Puedes consultar las ventajas y desventajas de cada opción en nuestra ZFS, Ceph, LVM Thin and RAID comparison.

Otro participante simplificó todavía más la propuesta: ejecutar PBS en Docker sobre un NAS con suficiente potencia. Lo presentó como una alternativa rápida y directa con un consumo de memoria modesto, aunque esa estimación era la opinión de una persona y no un requisito probado en distintos modelos de NAS. Los contenedores resultan atractivos cuando encajan con tus costumbres y tu hardware actual, pero también trasladan la compatibilidad, la persistencia y la recuperación a otra capa. Estas alternativas no son intercambiables entre sí, y los comentarios tampoco demostraron que lo fueran. Hay administradores que prefieren un equipo dedicado para PBS con almacenamiento remoto, mientras que otros quieren el servicio de backup dentro del propio hardware de almacenamiento. Ambas son opciones coherentes, pero cada una exige confiar en una parte diferente del despliegue.

Luego surgió una sugerencia que hacía parecer modesto el script original: incorporar multipathing en iSCSI. Un participante compartió un ejemplo básico en shell y defendió configurar varias rutas entre el iniciador de PBS y el almacenamiento. El autor respondió que lo evaluaría, mientras otro lector preguntaba si eso implicaba múltiples sesiones de almacenamiento. El multipath puede ser muy útil cuando hay rutas redundantes disponibles, pero el fragmento compartido distaba de ser un añadido probado y listo para producción. Y lo que es más importante, refleja la tentación habitual en el homelab: cada vez que alguien elimina un dolor de cabeza en la configuración, otra persona encuentra una mejora de resiliencia que merece la pena añadir. De pronto, un script pensado para reducir retoques corre el riesgo de llenarse de piezas móviles.

¿Cómo deberías evaluar una configuración de almacenamiento en PBS?

Evalúa el diseño por el éxito en las pruebas de restauración y la previsibilidad ante fallos, no por lo limpio que quede el asistente inicial.

El debate de fondo no trata de darle un premio a NFS o a iSCSI, sino de decidir dónde prefieres asumir la complejidad. Una instancia dedicada de PBS con un LUN iSCSI de Synology mantiene el servicio y sus datos separados, pero exige configurar almacenamiento en red. Ejecutar PBS en el propio NAS elimina esa conexión de red, pero concentra el servicio y los datos en el mismo dispositivo. Un despliegue basado en contenedores parece ligero, pero introduce consideraciones propias de soporte y mantenimiento. Por último, el multipath añade tolerancia a fallos en una red bien diseñada, aunque suma complejidad a la configuración. Ninguno de estos compromisos se resuelve según lo vistoso que sea un menú de instalación. La opción adecuada depende del hardware que ya tengas y de los escenarios de fallo que quieras mitigar.

También conviene diferenciar entre una conexión estable y un plan de recuperación fiable. Montar un LUN con éxito no demuestra que puedas restaurar una máquina virtual dañada. Que un script detecte un datastore previo no garantiza que los datos internos estén sanos. La conversación aportó anécdotas positivas e ideas útiles, pero no mostró pruebas comparativas de rendimiento ni evidencias de restauración a largo plazo con la nueva herramienta de MorphyDK. Conviene ser transparente con esos datos ausentes: un usuario prudente revisará el script, lo probará primero con almacenamiento descartable, entenderá qué acciones pueden alterar discos y verificará que las restauraciones funcionen en la práctica. Esas comprobaciones son menos vistosas que una configuración automática, pero son las que separan una aparente actividad de backup de unos datos realmente recuperables.

Quizá lo más interesante de esta historia sea su origen modesto. Alguien se topó con un problema recurrente, aprendió de una solución previa y creó una herramienta para ahorrar tiempo a los demás. El autor original se mostró dispuesto a colaborar, mientras otros aficionados propusieron arquitecturas alternativas y conexiones más resistentes. Nadie dio una respuesta definitiva, y el nuevo script tampoco necesita serlo para resultar útil. Su verdadero valor dependerá de si facilita configurar PBS sin que resulte más difícil confiar en el sistema. Porque una solución de backup que se instala de maravilla pero falla al restaurar no soluciona el problema de fondo.

En mi caso, elegiría el protocolo que el operador pueda supervisar y recuperar con total confianza, realizando una restauración completa de un invitado antes de darlo por bueno. Si en tu caso un datastore de PBS directo sobre almacenamiento local fiable resulta más sencillo, añadir una capa extra de iSCSI quizá no merezca la pena.