¿Por qué las copias de seguridad deduplicadas parecen más pequeñas que el espacio que ocupan al restaurarse?

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

Las copias de seguridad deduplicadas parecen más pequeñas porque los fragmentos repetidos se almacenan una sola vez, mientras que una restauración reconstruye cada archivo lógico y cada copia independiente.

Diez imágenes de máquinas virtuales pueden compartir gigabytes de bloques idénticos del sistema operativo en un repositorio de copias de seguridad. Al restaurarlas en un sistema de archivos ordinario se recrean diez espacios de direcciones, a menos que el destino también admita el uso compartido compatible, la dispersión o la compresión. Por lo tanto, el tamaño del repositorio y la capacidad de restauración describen representaciones diferentes, con distintas reglas de asignación y sobrecarga en el sistema de archivos de destino seleccionado de forma segura.

La deduplicación almacena la identidad una vez y la referencia muchas veces

El software de copias de seguridad divide los datos en fragmentos, calcula sus huellas y almacena solo los fragmentos que aún no están presentes. Los manifiestos conservan qué fragmentos pertenecen a cada archivo y punto de restauración. El repositorio puede representar muchas copias lógicas con una sola carga física más sus referencias.

Una descripción general de la deduplicación de copias de seguridad explica cómo se eliminan las copias redundantes del almacenamiento de copias de seguridad. El ahorro depende del contenido repetido, no simplemente del número de archivos.

La restauración invierte esa correspondencia. Cada archivo recibe sus bytes ordenados en el destino solicitado. Si el destino no admite el uso compartido de bloques, los fragmentos repetidos vuelven a consumir extensiones independientes. La reducción de datos era una propiedad del repositorio, no una promesa de que todos los destinos de restauración sigan siendo igual de compactos.

La compresión, la dispersión y los metadatos amplían la diferencia

La compresión reduce los bytes almacenados según la entropía del contenido. Los archivos dispersos omiten largas regiones de ceros, pero una opción de restauración puede materializar esos huecos. Las unidades de asignación, las sumas de comprobación, los atributos extendidos y los metadatos del sistema de archivos añaden sobrecarga al destino que los resúmenes del repositorio pueden excluir.

Una explicación del almacenamiento distingue los archivos dispersos del tamaño asignado: un archivo puede indicar una longitud lógica grande y, al mismo tiempo, consumir menos bloques físicos. Las herramientas de restauración deben conservar los huecos explícitamente para mantener ese ahorro.

También puede ocurrir lo contrario. Un destino comprimido o un clon con copia en escritura puede mantener los datos restaurados por debajo de su tamaño lógico. No existe un multiplicador universal para convertir los bytes del repositorio en bytes restaurados, porque importan la representación, el conjunto de retención y el sistema de archivos de destino.

Cuándo la deduplicación no es la causa principal

La explicación falla cuando un único archivo no duplicado aumenta inesperadamente. El cifrado, los medios precomprimidos, los formatos de exportación de bases de datos o un cambio en el aprovisionamiento ligero pueden ser la causa dominante. Un catálogo de copias de seguridad también puede mostrar solo los datos únicos de un ámbito, mientras que la restauración incluye varias instantáneas seleccionadas.

Una discusión técnica sobre la tasa de deduplicación enfatiza que los tamaños lógicos y físicos deben distinguirse al informar sobre las tasas de deduplicación. Las tasas sin especificar el ámbito pueden inducir a error al planificar la capacidad.

El mecanismo también deja de aplicarse si los hashes o los recuentos de los archivos restaurados difieren de los de la copia de seguridad seleccionada. En ese caso, el problema es la selección o la integridad, no una expansión esperada. Un menor número de bytes en la copia de seguridad no justifica dimensionar por debajo del espacio temporal necesario antes de la verificación.

Mide una restauración en lugar de confiar en la tasa

Elige un conjunto de restauración representativo y registra los bytes lógicos de origen, los bytes únicos del repositorio, los bytes comprimidos, las extensiones dispersas, el recuento de archivos y la unidad de asignación del destino. Restaura en un destino aislado utilizando tanto opciones que conserven la dispersión como las opciones predeterminadas; después, verifica los hashes y el espacio asignado.

Utiliza un plan de almacenamiento de almacenamiento compartido de modelos para que el destino de prueba no sature los servicios activos. Mantén fijos la retención del repositorio y los ajustes de compresión del destino al comparar las ejecuciones.

Dimensiona la recuperación a partir del mayor valor entre la salida asignada medida y el tamaño lógico del conjunto de datos más un margen de trabajo, no a partir del número de repositorio deduplicado. Si la conservación de la dispersión cambia el resultado, documenta esa dependencia. Si cambia la identidad o el recuento de archivos, detente y resuelve la corrección de la restauración antes de ajustar la capacidad.

Centro de Tecnología e IA

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.