¿Por qué un disco USB de respaldo rotado obtiene una ruta de montaje con sufijo después de reiniciar?
Un disco USB de respaldo rotado puede obtener una ruta de montaje con un sufijo cuando el directorio preferido basado en su etiqueta ya está ocupado, duplicado o asignado por otro automontador.
La rotación de respaldos suele utilizar varios discos similares, y los administradores pueden clonar sistemas de archivos o reutilizar la misma etiqueta de volumen por comodidad. Después de reiniciar, el orden de detección, el automontaje del escritorio, los directorios de montaje obsoletos, las etiquetas duplicadas o una entrada de fstab en conflicto pueden hacer que un disco aparezca bajo una ruta como BACKUP_1 en lugar de BACKUP. El disco puede estar en buen estado, mientras el trabajo de respaldo ahora apunta al directorio equivocado. Verifica la identidad antes de mover archivos o editar rutas.
Identifica el sistema de archivos detrás de la ruta inesperada
Registra el dispositivo real, el UUID del sistema de archivos, la etiqueta, el número de serie o la ruta by-id, el origen del montaje, el destino, el tipo de sistema de archivos y las opciones de cada disco de rotación conectado.
El comando de Linux findmnt relaciona un destino con su origen activo, evitando que un nombre de carpeta engañoso se confunda con el disco de respaldo previsto.
Si el directorio con sufijo pertenece al UUID correcto, el problema es la asignación de la ruta. Si pertenece a otro disco, detén el respaldo antes de que escriba en el conjunto de rotación equivocado.
Comprueba si hay etiquetas o UUID duplicados del sistema de archivos
Compara el UUID, la etiqueta, el PARTUUID, el número de serie y los nombres by-id de todos los discos rotados, incluidos los que estén desconectados si hay registros disponibles.
ArchWiki explica que las etiquetas son más fáciles de duplicar que los UUID, por lo que el automontaje basado únicamente en etiquetas es arriesgado cuando varios discos de respaldo comparten intencionadamente un nombre descriptivo.
Clonar un sistema de archivos también puede clonar su UUID. Asigna una identidad única al sistema de archivos antes de confiar en la rotación desatendida y documenta qué disco físico pertenece a cada identificador.
Comprende por qué los automontadores añaden un sufijo
Comprueba si una sesión de escritorio, un servicio NAS, un asistente de UDisks o un administrador de medios extraíbles montó el disco antes de que actuaran fstab o el servicio de respaldo.
El Filesystem Hierarchy Standard permite añadir dígitos a los directorios de montaje de medios extraíbles cuando más de un dispositivo necesita una ubicación de montaje similar.
La política exacta de los sufijos varía según el automontador, pero el principio de diagnóstico es el mismo: la ruta preferida no estaba disponible o era ambigua cuando llegó el dispositivo.
Comprueba si el directorio de montaje preferido ya estaba ocupado
Inspecciona el directorio esperado antes de conectar el disco. Determina si contiene otro montaje, archivos sueltos escritos mientras el disco estaba ausente, un montaje bind o un directorio de trabajo obsoleto de algún proceso.
La guía de Oracle sobre medios extraíbles señala que las etiquetas de los medios se utilizan para nombrar las rutas de montaje, lo que provoca una colisión cuando varios objetos multimedia presentan la misma ruta derivada de la etiqueta.
No elimines un directorio ocupado hasta comprobar si contiene respaldos escritos accidentalmente en el sistema de archivos raíz. Mueve los datos sueltos verificados mediante un proceso de recuperación controlado.
Define un punto de montaje fijo en fstab para cada disco de rotación
Elige una política estable: cada disco físico recibe su propio directorio fijo, o un script de rotación monta el UUID seleccionado actualmente en una única ruta de respaldo controlada después de verificar su identidad.
Red Hat documenta el montaje persistente mediante fstab con un UUID y un punto de montaje fijo, eliminando del proceso desatendido el orden de detección y las colisiones entre etiquetas descriptivas.
No crees varias entradas activas de fstab que compitan por el mismo directorio de destino. Un flujo de rotación debe confirmar que el disco anterior está desmontado antes de conectar el siguiente.
Haz que el inicio del respaldo dependa del montaje verificado
Comprueba si el programador se inicia antes de que finalicen la detección y el montaje del USB. Añade una comprobación previa del UUID, el punto de montaje, el estado de escritura y el archivo marcador esperado.
La documentación de Debian sobre montajes de systemd explica que las entradas de fstab se convierten en dependencias de montaje de systemd, lo que permite que los servicios de respaldo esperen un montaje específico en lugar de un directorio arbitrario.
Comprobar únicamente que exista el directorio no es suficiente, porque el directorio base existe incluso cuando el disco está ausente. Valida la identidad del sistema de archivos montado.
Prueba toda la rotación después de reinicios e intercambios de discos
Para cada disco, realiza un desmontaje limpio, desconéctalo, reinicia, vuelve a conectarlo, valida su identidad, efectúa una escritura desechable, ejecuta una simulación del respaldo y verifica la lectura posterior. Registra la ruta y el UUID esperados.
El artículo de ZimaSpace sobre montajes mediante UUID y rutas estables para aplicaciones aborda el diseño general de rutas fijas; este artículo se centra en las colisiones creadas al rotar varios discos de respaldo extraíbles.
El problema se resuelve cuando cada disco de rotación se asigna a su ruta documentada después de repetir las pruebas de reinicio e intercambio, y el respaldo se niega a ejecutarse cuando falta el UUID esperado o está montado en otro lugar.
Productos recomendados
Soporte y Consejos
Más para leer
¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...
¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...
¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un diagnóstico de pérdida de sesión que abarca el alcance del reinicio, la propiedad de las cookies, la rotación de secretos, las sesiones respaldadas...
