La instalación de UrBackup de la fuente falló por varias razones independientes antes de funcionar: la descarga de la imagen se reescribió mediante un espejo exclusivo de China continental, las primeras rutas de enlace no existían en el host de ZimaOS, los permisos del directorio de copias de seguridad eran incorrectos y la URL y los puertos del lanzador de la aplicación resultaban confusos.
La lección duradera es tratar UrBackup como una aplicación Docker con estado normal: usa rutas reales de almacenamiento del host, conserva tanto los datos de las copias de seguridad como la base de datos y el estado de UrBackup, verifica los permisos del usuario de ejecución y confirma los puertos de escucha de la WebUI y la red antes de confiar en ella para las copias de seguridad de los clientes.
La primera descarga de la imagen se reescribió a un espejo inutilizable
El demonio devolvió un mensaje de rechazo de descarga para docker.1panel.live/uroni/urbackup-server. La página oficial de descargas de UrBackup todavía identifica uroni/urbackup-server como imagen Docker oficial.
Consulta la imagen Docker oficial actual de UrBackup.
Los montajes de enlace deben apuntar a carpetas reales del host de ZimaOS
El resumen operativo utilizó almacenamiento real en rutas como /media/Safe-Storage/UrBackup/backups y /media/Safe-Storage/UrBackup/data, asignados a /backups y /var/urbackup. Inspecciona la ruta real de tu host en lugar de copiar literalmente el nombre del almacenamiento de la fuente.
«Permiso denegado» significa que el usuario del contenedor no puede escribir
La fuente encontró No hay permiso para acceder a "/backups/urbackup_tmp_files". Su solución utilizó un UID/GID específico y la propiedad correspondiente del host. No fijes 1000:100 como identidad universal; verifica el usuario de ejecución actual.
Conserva ambas copias de seguridad y el estado de UrBackup
El repositorio contiene datos de copias de seguridad de los clientes, mientras que /var/urbackup contiene la base de datos y el estado del servidor. Un plan de recuperación utilizable debe conservar ambos según corresponda.
La fuente utilizó la red del host
La mantenida uroni/urbackup-server La imagen documenta actualmente la red del host como un patrón de Docker compatible y expone los puertos de servicio normales de UrBackup. La red del host simplifica el descubrimiento, pero elimina el aislamiento de red de Docker.
La WebUI necesita el puerto correcto
La fuente corrigió el lanzador de ZimaOS al puerto 55414. El lanzador solo es una URL práctica; el estado real del servicio debe comprobarse mediante los registros y los puertos en escucha.
Prefiere una definición de Compose reproducible
App Store 2.0 actual de ZimaOS y los flujos de trabajo de aplicaciones personalizadas admiten Docker Compose estándar. Mantén la imagen, las rutas persistentes, la zona horaria, la política de reinicio y la red en una sola definición de Compose.
Usa el modelo actual de Compose de ZimaOS.
Un panel en ejecución no es la prueba final
Registra un cliente, completa una copia de seguridad pequeña, reinicia el contenedor o el host y, después, realiza una restauración de archivos. Así se verifican conjuntamente la red, los permisos, la persistencia de la base de datos y el almacenamiento de copias de seguridad.
Coloca el repositorio de copias de seguridad en el almacenamiento de datos, no en el disco del sistema
UrBackup puede consumir cientos de gigabytes o más. La ruta del repositorio debe apuntar a un espacio de almacenamiento real de ZimaOS con capacidad y estado conocidos, no a la pequeña unidad del sistema operativo.
Antes de incorporar clientes, confirma la ruta del host en ZimaOS y controla el espacio libre durante la primera copia de seguridad completa.
La base de datos de UrBackup forma parte del sistema de restauración
Los archivos de /backups son solo la mitad de un servidor utilizable. El estado y la base de datos de UrBackup en /var/urbackup realiza un seguimiento de los clientes, los metadatos de las copias de seguridad, la retención y la configuración del servidor.
Documenta y protege ambas asignaciones persistentes para que la recreación de un contenedor no deje un montón de archivos de copia de seguridad sin el estado esperado del servidor.
Usa acceso de escritura con los mínimos privilegios
El ajuste de UID/GID específico de la fuente solucionó una implementación, pero cambiar recursivamente la propiedad de todo un conjunto de almacenamiento es arriesgado. Crea un directorio exclusivo para UrBackup y concede acceso a la identidad del contenedor a ese directorio, en lugar de otorgar acceso amplio de escritura a datos no relacionados del NAS.
La red del host expone directamente los servicios de UrBackup en ZimaOS
Cuando se utiliza la red del host, los servicios de UrBackup escuchan directamente en el host. Si ZFW u otro firewall protege el NAS, permite únicamente los puertos y las redes de clientes necesarios para las copias de seguridad y la detección. No publiques directamente los puertos de servicio de UrBackup en Internet.
Prueba una restauración antes de dar por terminado el servidor de copias de seguridad
Completa una copia de seguridad de un cliente, reinicia ZimaOS o vuelve a crear el contenedor, verifica que el historial del cliente se conserve y, después, restaura varios archivos en una ubicación independiente. Esto valida la disponibilidad de la imagen, los permisos, el estado persistente, la red y la recuperabilidad real, no solo el panel en verde.
Preguntas frecuentes sobre UrBackup en ZimaOS
¿El usuario de la fuente finalmente logró hacer funcionar UrBackup?
Sí.
¿Todos los sistemas ZimaOS deberían usar PUID 1000 y PGID 100?
No. Esos eran valores específicos de la fuente.
¿Es obligatorio usar la red del host?
No de forma universal. Es una opción de imagen documentada que la fuente utilizó correctamente, pero reduce el aislamiento de red.
