¿Por qué un repositorio de copias de seguridad deduplicadas aparece como de solo lectura después de una poda interrumpida?
Un repositorio puede actuar como de solo lectura después de una poda interrumpida cuando un bloqueo exclusivo, un error de almacenamiento, un backend inmutable o un estado de mantenimiento incompleto impiden realizar cambios.
«Solo lectura» puede ser la respuesta de seguridad del cliente de copias de seguridad, no necesariamente el modo de montaje real del sistema de archivos. Una poda cancelada puede dejar un bloqueo exclusivo, tareas de empaquetado o indexación sin finalizar, espacio de trabajo insuficiente para la limpieza u operaciones del backend que permiten leer, pero rechazan las eliminaciones. Por separado, el sistema operativo puede volver a montar como solo lectura el sistema de archivos del repositorio después de errores de E/S o de consistencia. Identifica qué capa rechaza la primera escritura antes de eliminar bloqueos o volver a ejecutar la poda.
Captura la primera operación que informa de solo lectura
Ejecuta un comando para listar el repositorio, luego una comprobación no destructiva, y guarda el primer error del cliente, del backend y de los registros del sistema operativo.
La documentación de Restic explica que la poda reescribe los datos del repositorio y necesita acceso exclusivo porque elimina contenido sin referencias y puede volver a empaquetar archivos parcialmente utilizados.
Si el listado funciona, pero todas las operaciones que crean un bloqueo o escriben metadatos fallan, distingue entre un bloqueo obsoleto, permisos de escritura del backend y retención de objetos.
Comprueba si la poda interrumpida dejó un bloqueo exclusivo
Enumera los bloqueos del repositorio mediante la herramienta de copias de seguridad e identifica el equipo, el proceso, la hora de creación y el comando propietario de cada bloqueo.
Borg documenta que los comandos que modifican el repositorio utilizan bloqueos del repositorio para impedir escrituras simultáneas y advierte que romper un bloqueo activo puede dañar el estado del repositorio.
Elimina un bloqueo obsoleto únicamente mediante el comando compatible y solo después de demostrar que su propietario ya no está activo.
Determina si el sistema de archivos se volvió a montar como solo lectura
Comprueba la tabla de montajes, el registro del kernel, el estado del sistema de archivos, el estado del conjunto de almacenamiento y los errores recientes de USB, SATA, red o del controlador.
La documentación de ext4 de Linux enumera errors=remount-ro como una política de seguridad, lo que demuestra cómo una avería de almacenamiento puede hacer que el repositorio sea realmente de solo lectura.
No fuerces un remonte de lectura y escritura mientras continúen los errores de hardware o del sistema de archivos. Conserva los registros y repara primero el almacenamiento.
Inspecciona el estado parcial de la poda, compactación o indexación
Determina qué fase se interrumpió: seleccionar instantáneas caducadas, eliminar referencias, volver a empaquetar datos, reconstruir un índice o confirmar metadatos.
La referencia de poda de Borg señala que la poda y la compactación son pasos independientes, por lo que los archivos pueden seguir siendo válidos aunque la recuperación de espacio no se haya completado.
Utiliza el comando de comprobación del repositorio antes de ejecutar otra operación destructiva. No elimines manualmente paquetes, índices ni segmentos.
Comprueba el bloqueo de objetos, la inmutabilidad y las credenciales del backend
Para repositorios en la nube, inspecciona la retención de objetos, la retención legal, la política del bucket, el versionado, los permisos de eliminación y la rotación de credenciales.
AWS afirma que S3 Object Lock impide eliminar o sobrescribir objetos durante un periodo de retención protegido, lo que permite las lecturas mientras la poda falla.
No debilites la retención inmutable solo para conseguir que la poda finalice. Utiliza un diseño de repositorio compatible con la herramienta de copias de seguridad.
Verifica el espacio libre, los inodos y el espacio de trabajo de la poda
Comprueba los bytes del sistema de archivos, los inodos, las cuotas, las reservas de instantáneas, los directorios temporales, los límites del almacén de objetos y el espacio de la caché local.
GNU Coreutils explica que df puede informar sobre bloques y uso de inodos, diferenciando un sistema de archivos lleno de un bloqueo o un fallo de permisos a nivel del repositorio.
Si el sistema de archivos está lleno, añade capacidad temporal o elimina datos ajenos al repositorio que hayas verificado, en lugar de borrar objetos del repositorio.
Recupera el sistema con una comprobación, desbloqueo y una única ejecución de mantenimiento controlada
Protege los últimos puntos de restauración conocidos como válidos, detén las tareas programadas, ejecuta una comprobación compatible, elimina únicamente un bloqueo que hayas confirmado como obsoleto y realiza una sola ejecución de mantenimiento con registros.
La guía de ZimaSpace para recuperar un destino de copias de seguridad lleno proporciona una regla relacionada: trata el repositorio como una estructura administrada, no como archivos independientes.
El problema se resuelve cuando el listado, la comprobación, la copia de seguridad, la retención y una restauración de prueba se completan correctamente sin desbloqueos forzados ni eliminaciones manuales.
Preguntas frecuentes
¿Puedo eliminar manualmente el archivo de bloqueo?
No como primer paso. Confirma que ningún proceso lo posee y utiliza la operación de desbloqueo compatible de la herramienta de copias de seguridad.
¿Debo volver a ejecutar inmediatamente la poda después de un bloqueo?
No. Verifica el estado del repositorio, el índice, el sistema de archivos y el backend antes de realizar otra operación de mantenimiento destructiva.
¿El comportamiento de solo lectura significa que los datos de la copia de seguridad están a salvo?
No necesariamente. La falta de paquetes, los errores de almacenamiento, los objetos inmutables o los índices incompletos también pueden impedir las restauraciones.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
