Windows Server 2012 R2 dedujo 356GB a 1.32GB

Estoy experimentando con la deduplicación en un espacio de almacenamiento de Server 2012 R2. Lo dejé ejecutar la primera optimización de deduplicación anoche, y me complació ver que reclamaba una reducción de 340 GB.

Sin embargo, sabía que esto era demasiado bueno para ser verdad. En esa unidad, el 100% de la deducción provino de las copias de seguridad de SQL Server:

Eso parece poco realista, teniendo en cuenta que hay copias de seguridad de bases de datos que son 20 veces más grandes en la carpeta. Como ejemplo:

Considera que un archivo de respaldo de 13.3GB se ha deducido a 0 bytes. Y, por supuesto, ese archivo en realidad no funciona cuando realicé una restauración de prueba.

Para agregar insulto a las lesiones, hay otra carpeta en esa unidad que tiene casi una TB de datos que debería haber deducido mucho, pero no la tiene.

¿Funciona la deduplicación de Server 2012 R2?

La deduplicación funciona.

Con la deduplicación, el campo Tamaño en disco deja de tener sentido. Los archivos ya no son "archivos" habituales, sino que vuelven a analizar los puntos y no contienen datos reales sino metadatos para que el motor de deduplicación reconstruya el archivo. Tengo entendido que no puede obtener ahorros por archivo ya que el almacén de fragmentos de deduplicación es por volumen, por lo que solo obtiene ahorros por volumen. http://msdn.microsoft.com/en-us/library/hh769303(v=vs.85).aspx

Quizás su trabajo de deducción aún no se haya completado, si algunos otros datos aún no se han deducido. No es súper rápido, tiene un límite de tiempo de manera predeterminada y puede tener limitaciones de recursos dependiendo de su hardware. Verifique la programación de deduplicación del Administrador del servidor.

He implementado dedup en varios sistemas (Windows 2012 R2) en diferentes escenarios (SCCM DP, diferentes sistemas de implementación, servidores de archivos genéricos, servidores de archivos de carpetas de inicio de usuarios, etc.) durante aproximadamente un año. Solo asegúrese de estar completamente parcheado, recuerdo varios parches para deducir la funcionalidad (tanto las actualizaciones acumulativas como las revisiones) desde RTM.

Sin embargo, hay algunos problemas que algunos sistemas no pueden leer datos directamente de archivos optimizados en el sistema local (IIS, SCCM en algunos escenarios). Según lo sugerido por yagmoth555, debe intentar Expandir-DedupFile para no optimizarlo o simplemente hacer una copia del archivo (el archivo de destino no se optimizará hasta la próxima ejecución de optimización) y vuelva a intentarlo. http://blogs.technet.com/b/configmgrteam/archive/2014/02/18/configuration-manager-distribution-points-and-windows-server-2012-data-deduplication.aspx https: //kickthatcomputer.wordpress .com / 2013/12/22 / sin-entrada-archivo-especificado-windows-server-2012-dedupe-on-iis-with-php /

Si su copia de seguridad SQL está realmente dañada, creo que se debe a un problema diferente y no a la tecnología de deduplicación.

Parece que salte el arma diciendo que este tipo de deduplicación no es posible. Aparentemente, es totalmente posible, porque además de estas copias de seguridad de SQL Server sin comprimir, también tengo copias de seguridad a nivel de instantánea VMWare de las máquinas virtuales del host.

Como yagmoth555 sugirió, ejecuté un Expand-DedupeFilearchivo en algunos de estos archivos de 0 bytes y obtuve un archivo totalmente utilizable al final.

Luego miré mi metodología de prueba para determinar cómo determinaba que los archivos no eran buenos, y encontré una falla en mis pruebas (¡permisos!).

También abrí un archivo de copia de seguridad deducido de 0 bytes en un editor hexadecimal, y todo parecía estar bien.

Así que ajusté mi metodología de prueba y todo parece funcionar. Cuando lo dejé, las deducciones en realidad mejoraron, y ahora he ahorrado más de 1.5TB de espacio gracias a la deducción.

Voy a probar esto más a fondo antes de darle un empujón a la producción, pero en este momento parece prometedor.

Sí, pero solo vi el caso de un clúster hiperv db dedup'ed. 4tb a 400g, y la VM se estaba ejecutando. El sistema operativo estaba completamente parcheado.

Para su archivo de copia de seguridad sql, ¿es un volcado que puede leer en él? Verificaría el contenido. Por esa parte no puedo responder cómo deduce el archivo ascii.