¿Por qué un disco virtual disperso consume todo su tamaño después de restaurar una copia de seguridad?
Un disco virtual disperso pasa a estar completamente asignado cuando la restauración escribe las regiones llenas de ceros como bloques reales o vuelve a crear la imagen con un formato grueso.
Las imágenes dispersas VHD, VHDX, raw y QCOW2 pueden informar de una gran capacidad lógica mientras consumen almacenamiento solo para las regiones asignadas. Una copia de seguridad puede conservar perfectamente el contenido de los archivos y, aun así, perder el mapa de huecos, los clústeres no asignados, el estado de descarte o los metadatos de aprovisionamiento ligero. El sistema invitado restaurado puede arrancar con normalidad aunque el archivo del host ocupe ahora todo su tamaño virtual. Diagnostica el formato y la asignación antes de compactar o convertir la única copia restaurada.
Compara el tamaño lógico con el tamaño realmente asignado
Registra el formato de la imagen, el tamaño virtual, el tamaño aparente del archivo, los bloques asignados en el host, el sistema de archivos de destino y si la imagen restaurada está marcada como dispersa o preasignada.
Microsoft explica que los archivos dispersos devuelven ceros para las regiones no asignadas mientras mantienen un tamaño nominal mayor, por lo que el tamaño virtual y el consumo físico deben medirse por separado.
Usa una herramienta que tenga en cuenta la asignación en lugar de depender únicamente de un explorador de archivos. Si el tamaño virtual y el asignado son ahora iguales, es probable que la restauración haya materializado los huecos o seleccionado un formato fijo.
Determina si la copia de seguridad conservó los huecos dispersos
Revisa las opciones de copia de archivos, copia por bloques, archivado, compresión y archivos dispersos del trabajo de copia de seguridad. Identifica si almacenó las extensiones asignadas o leyó todo el disco lógico como un flujo continuo de bytes.
GNU Coreutils documenta que las herramientas de copia deben volver a crear los huecos dispersos en el destino; de lo contrario, las secuencias largas de ceros pueden escribirse como bloques asignados normales.
Una restauración cuyo contenido es válido no demuestra que se hayan conservado los metadatos de asignación. Compara una imagen de prueba pequeña con huecos conocidos mediante la misma ruta de copia de seguridad y restauración.
Comprueba si la conversión de la imagen desactivó la dispersión
Inspecciona cada paso de conversión entre el objeto de copia de seguridad y la imagen restaurada. Registra el formato de entrada, el formato de salida, la opción de preasignación, el umbral de dispersión y si se utilizó la descarga de copia.
QEMU indica que la conversión con qemu-img puede detectar sectores cero y omitirlos, mientras que un umbral de dispersión cero o una ruta de descarga de copia no compatible pueden producir un destino completamente asignado.
Nunca reconviertas una imagen mientras la máquina virtual esté en ejecución. Trabaja con una copia verificada y compara el contenido del disco virtual antes de reemplazar la imagen restaurada.
Verifica que el sistema de archivos de destino admita archivos dispersos
Comprueba la compatibilidad con archivos dispersos en el sistema de archivos NAS de destino y en cada volumen intermedio de preparación. Una restauración escrita primero en un sistema de archivos incompatible puede perder los huecos antes de llegar al almacenamiento final.
La asignación ligera depende tanto de las propiedades de aprovisionamiento del objeto de almacenamiento como de su tamaño lógico. Un destino puede admitir archivos grandes y, aun así, restaurar la imagen como un objeto completamente asignado cuando la aplicación de copia de seguridad no vuelve a crear los huecos.
Si el sistema de archivos de preparación o de destino no puede conservar los huecos, el archivo puede quedar completamente asignado antes de llegar al almacén de datos final de la máquina virtual. Prueba primero la compatibilidad con archivos dispersos usando una imagen desechable.
Distingue el formato de restauración grueso del espacio libre del invitado
Identifica si el disco restaurado es raw preasignado, raw disperso, VHD fijo, VHDX dinámico o QCOW2. El espacio libre del invitado no se convierte automáticamente en un hueco en el host.
Red Hat distingue entre discos virtuales preasignados y dispersos: los discos preasignados reservan inmediatamente todo el tamaño, mientras que los discos dispersos asignan almacenamiento a medida que se escriben los datos.
Si el destino de restauración era intencionadamente grueso, la asignación completa es esperable y no indica daños. Decide si la compensación entre rendimiento y capacidad justifica volver a convertirlo a un formato ligero.
Recupera el espacio puesto a cero con un método sin conexión compatible
Apaga la máquina virtual, confirma que existe una copia de seguridad independiente y determina si los bloques eliminados del invitado se han puesto a cero o se han descartado. El espacio libre del sistema de archivos invitado aún puede contener datos antiguos distintos de cero.
El flujo de trabajo virt-sparsify de Red Hat convierte el espacio libre reconocido en regiones dispersas del host y advierte que no debe ejecutarse sobre imágenes de disco activas.
Ejecuta la compactación únicamente sobre una imagen duplicada, verifica después el sistema de archivos invitado y conserva la imagen restaurada original hasta que las pruebas a nivel de aplicación se completen correctamente.
Comprueba el comportamiento de la preasignación y la liberación de huecos
Inspecciona si la aplicación de restauración preasignó el destino por motivos de fiabilidad o rendimiento y si el destino admite desasignar rangos posteriormente.
La interfaz fallocate de Linux distingue entre asignar bloques reales y liberar huecos, lo que demuestra por qué escribir ceros y desasignar espacio no son la misma operación.
No liberes huecos directamente en un formato de disco virtual desconocido. Usa el hipervisor o la utilidad de imágenes que conozca sus metadatos y la disposición de sus clústeres.
Valida el disco restaurado antes de reemplazarlo
Arranca la copia compactada de forma aislada, comprueba los sistemas de archivos, las aplicaciones, las instantáneas y el espacio libre del invitado; después, compara los hashes de archivos representativos y la estructura informada del disco virtual.
La lista de comprobación de recuperación de servidores domésticos de ZimaSpace establece el requisito relacionado de demostrar la recuperación del almacenamiento y las aplicaciones antes de retirar la copia anterior.
El problema se resuelve cuando el disco restaurado conserva el formato ligero previsto, el espacio asignado en el host refleja los datos reales del invitado y la máquina virtual supera las verificaciones de arranque, carga de trabajo, copia de seguridad y restauración. Conserva la imagen completamente asignada si la conversión produce errores o la plataforma requiere aprovisionamiento grueso.
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...
