¿Tu datastore “engorda” después de mover archivos a una VM en VMware? Si al copiar ~200 GB de ISOs desde un servidor físico el uso del disco de la VM se dispara (por ejemplo, a ~320 GB en una unidad compartida de 400 GB), esta guía te ayuda a diagnosticar y normalizar el consumo real en Windows/NTFS sobre VMware.
Contexto del caso real
Tras migrar ~200 GB de ficheros (principalmente .iso) a una VM, el equipo observa:
- En el origen, Tamaño y Tamaño en disco coinciden (~202 GB).
- En el destino, el Explorador reporta Tamaño ~202 GB pero Tamaño en disco ~169 GB para esa carpeta… y sin embargo el volumen crece hasta ocupar ~320 GB del datastore.
El diagnóstico muestra dos causas frecuentes que se combinan en estos escenarios:
- Fragmentación elevada del volumen NTFS dentro de la VM (más metadatos y peor reutilización de bloques).
- Comportamientos característicos de discos finos (thin) y snapshots en VMware: al escribir nuevos bloques, el VMDK se expande; si existen snapshots, los bloques modificados se duplican en los discos de estado.
La solución aplicada que resolvió el caso fue optimizar/desfragmentar el volumen NTFS y realizar las labores de limpieza + TRIM/ReTrim, seguido de consolidación de snapshots en el hipervisor cuando correspondía.
Síntomas típicos y señales de alerta
| Síntoma | Qué sugiere | Comandos/Acciones |
|---|---|---|
| El “uso total del volumen/datastore” crece mucho más que la suma de los archivos copiados. | Fragmentación, snapshots activos, thin provisioning expandiéndose, VSS/Shadow Copies. | TreeSize (como SYSTEM), vssadmin, revisión de snapshots, Optimize-Volume -ReTrim. |
| Diferencias entre “Tamaño” y “Tamaño en disco”. | Compresión NTFS, ficheros dispersos (sparse), distinto tamaño de clúster, deduplicación. | fsutil fsinfo ntfsinfo, compact, Get-Item + atributos, utilidades de inventario. |
| El datastore de VMware crece aunque la VM borra datos. | Thin provisioning no recuperado aún, bloques no TRIMados, snapshots que retienen bloques. | Optimize-Volume -ReTrim, consolidar snapshots, Storage vMotion/VMDK shrink offline si aplica. |
| Carpetas “ocultas” consumen decenas de GB. | VSS (System Volume Information), Papelera ($RECYCLE.BIN), temporales. | TreeSize como SYSTEM, vssadmin list shadowstorage, limpiar Papelera. |
Qué está pasando “de verdad” debajo del capó
- NTFS y la fragmentación: Copiar muchos ficheros grandes cuando el volumen ya está poblado puede provocar alta fragmentación y multiplicar el overhead de metadatos (índices, MFT, mapas de asignación). El espacio efectivo ocupado por bloques y metadatos crece aunque la suma de “Tamaño” de archivos no lo refleje.
- Thin provisioning (VMDK thin): El archivo de disco virtual crece al escribir nuevos bloques por primera vez (o cuando los bloques viejos no pueden ser reutilizados eficientemente). Borrar dentro de Windows no reduce automáticamente el tamaño físico del VMDK en el datastore.
- Snapshots (VMware) y VSS (Windows): Los snapshots capturan el estado y redirigen escrituras a discos delta, lo cual incrementa el consumo por cada bloque modificado. En Windows, VSS mantiene copias de bloques para restauración.
- “Tamaño” vs “Tamaño en disco”: Si hay compresión NTFS, ficheros sparse o tamaños de clúster distintos, es normal ver discrepancias. El Explorador mide por archivo; el datastore mide por bloque de VMDK (y snapshots).
Metodología de diagnóstico reproducible
Aplica esta secuencia siempre que veas un pico de uso tras migraciones o copias voluminosas.
Paso 1 — Medir el estado del volumen en Windows
# Capacidad, libre y tipo de asignación
Get-Volume | Select-Object DriveLetter, FileSystem, Size, SizeRemaining, AllocationUnitSize
Uso por carpeta (método rápido si no tienes TreeSize)
gci "D:" -Recurse -ErrorAction SilentlyContinue |
? { -not $\_.PSIsContainer } |
Measure-Object Length -Sum
Comprobar soporte TRIM del sistema
fsutil behavior query DisableDeleteNotify
Información de NTFS (tamaño de clúster, MFT, etc.)
fsutil fsinfo ntfsinfo D: Paso 2 — Analizar con TreeSize como SYSTEM
Necesitas ver carpetas protegidas como System Volume Information y la Papelera de todos los usuarios.
rem 1) Abrir CMD como administrador y ubicarse en la carpeta de PsTools
cd <rutadePsTools>
rem 2) Lanzar TreeSize con permisos de SYSTEM (sesión interactiva)
psexec -s -i "\" En TreeSize, selecciona la unidad afectada, ordena por tamaño y expande las carpetas más pesadas hasta que ubiques el consumo real (VSS, $RECYCLE.BIN, rutas temporales, repositorios, etc.).
Paso 3 — Confirmar tamaño de clúster, compresión y archivos dispersos
# Tamaño de clúster
fsutil fsinfo ntfsinfo D:
Listado rápido de archivos comprimidos en una ruta
compact /Q /S\:D:\Carpeta\_ISO
¿Un archivo es sparse?
fsutil sparse queryflag "D:\Carpeta\_ISO\archivo.iso" Paso 4 — Revisar VSS, Papelera y temporales
# Ver uso de Shadow Copies (VSS)
vssadmin list shadowstorage
vssadmin list shadows
Reducir o reconfigurar almacenamiento de VSS (ejemplo)
vssadmin resize shadowstorage /for=D: /on=D: /maxsize=5%
Limpiar la Papelera de todos los usuarios
Clear-RecycleBin -DriveLetter D -Force
Limpieza de temporales típicos (ejemplos)
del /s /q "C:\Windows\Temp\*" 2>nul
del /s /q "%TEMP%\*" 2>nul Paso 5 — Comprobar snapshots y thin provisioning en VMware
- Si hay snapshots, consolídalos cuando ya no sean necesarios (desde el gestor de snapshots de la VM).
- Para discos finos, tras limpiar dentro de Windows, ejecuta ReTrim para comunicar bloques libres al hipervisor y facilitar la reclamación de espacio.
# Optimización/Desfragmentación en NTFS (on-line)
defrag D: /U /V
TRIM/ReTrim para notificar bloques libres (SSD/Thin)
Optimize-Volume D: -ReTrim -Verbose Resolución aplicada en el caso (y por qué funcionó)
El análisis con TreeSize y métricas del volumen reveló fragmentación elevada. La desfragmentación reorganizó los bloques, reduciendo el overhead y mejorando la capacidad de reutilización interna de NTFS. Al ejecutar Optimize-Volume -ReTrim después de limpiar VSS y la Papelera, el hipervisor pudo recuperar espacio en el datastore (especialmente con VMDK thin). Finalmente, al consolidar snapshots se eliminó la duplicación de bloques en discos delta.
Procedimiento práctico recomendado (paso a paso)
- Inventario de uso real: TreeSize como SYSTEM para ubicar carpetas de alto consumo.
- Limpiar “consumo oculto”:
- Shadow Copies (VSS): validar tamaño y reducir o purgar si procede.
- Papelera de todos los usuarios (
$RECYCLE.BIN). - Temporales del sistema y de aplicaciones.
- Optimizar NTFS:
defrag D: /U /V(o “Desfragmentar y optimizar unidades”). - ReTrim:
Optimize-Volume D: -ReTrim -Verbose. - VMware: consolidar snapshots; si el datastore sigue grande y la VM lo permite, considerar Storage vMotion o procedimientos de compactación para reclaim adicional.
- Verificar: comparar capacidad, libre y suma por carpetas; confirmar que “Tamaño” y “Tamaño en disco” no muestren anomalías inesperadas.
“Tamaño” vs “Tamaño en disco”: interpretar correctamente
| Concepto | Qué mide | Por qué difiere | Validación |
|---|---|---|---|
| Tamaño | Suma de bytes lógicos de los archivos. | Ignora tamaño de clúster, compresión/sparse, metadatos. | Get-ChildItem + Measure-Object; Propiedades del archivo. |
| Tamaño en disco | Bytes ocupados en clústeres asignados por NTFS. | Redondea a clúster; cambia con compresión, sparse y dedupe. | fsutil fsinfo ntfsinfo (clúster); compact; atributos del archivo. |
| Tamaño del VMDK | Bytes del archivo de disco virtual en el datastore. | Crece por escrituras y snapshots; no se reduce sólo por borrar dentro de la VM. | Panel de almacenamiento/archivos de la VM; comprobar snapshots y políticas de thin. |
Checklist rápido posmigración (copiar & pegar)
# 1) Medición
Get-Volume
fsutil fsinfo ntfsinfo D:
2) Auditoría de uso (usar TreeSize como SYSTEM)
psexec -s -i "C:\Tools\TreeSize\TreeSize.exe"
3) Limpieza
vssadmin list shadowstorage
vssadmin resize shadowstorage /for=D: /on=D: /maxsize=5%
Clear-RecycleBin -DriveLetter D -Force
4) Optimización
defrag D: /U /V
Optimize-Volume D: -ReTrim -Verbose
5) VMware
- Revisar y consolidar snapshots
- Verificar crecimiento del VMDK y del datastore
6) Verificación final
gci D:\ -Recurse -ErrorAction SilentlyContinue | ? { -not $\_.PSIsContainer } | Measure-Object Length -Sum Tabla de causas frecuentes, cómo detectarlas y cómo corregir
| Causa | Cómo se manifiesta | Cómo verificar | Acción correctiva |
|---|---|---|---|
| Fragmentación NTFS alta | Uso total exagerado; rendimiento bajo en copias. | defrag D: /A /V (análisis), tiempos de acceso. | defrag D: /U /V (o “Optimizar unidades”). |
| Snapshots activos | Datastore crece al escribir; duplicación de bloques cambiados. | Gestor de snapshots de la VM. | Consolidar/eliminar snapshots no necesarios. |
| Thin provisioning sin TRIM | El VMDK no se reduce tras borrar datos. | fsutil behavior query DisableDeleteNotify; tamaño del VMDK. | Optimize-Volume -ReTrim; operaciones de reclaim desde el hipervisor. |
| VSS/Shadow Copies grandes | GBs “ocultos” en System Volume Information. | vssadmin list shadowstorage. | Reducir/purgar copias; ajustar cuota de VSS. |
| Papelera y temporales | Espacio no liberado tras borrar. | TreeSize como SYSTEM; $RECYCLE.BIN. | Clear-RecycleBin; limpieza de temporales. |
| Compresión/sparse o clúster distinto | Diferencia notable entre “Tamaño” y “Tamaño en disco”. | fsutil fsinfo ntfsinfo, compact, fsutil sparse. | Reconfigurar compresión; evaluar clúster adecuado. |
Buenas prácticas para evitar sorpresas en futuras migraciones
- Planificar el orden de copias: primero datos grandes y contiguos; después pequeños/fragmentados.
- Evitar snapshots de larga duración durante migraciones pesadas.
- Hacer limpieza previa en origen (temporales, Papelera, VSS) para no arrastrar basura.
- Comprobar y documentar el tamaño de clúster; usar el mismo en origen y destino cuando sea posible.
- Post-copia: desfragmentar/optimizar, limpiar y ejecutar
-ReTrim. - Monitorizar el datastore durante 24–48 h tras migraciones (aplicaciones y antivirus pueden reindexar).
Preguntas frecuentes (FAQ)
¿Por qué “Tamaño en disco” de la carpeta es menor que el “uso total” de la unidad?
Porque el “uso total” incluye metadatos, MFT, archivos del sistema, VSS, Papelera y cualquier bloque ocupado fuera de esa carpeta concreta. Además, el datastore de VMware contabiliza el VMDK y sus snapshots.
¿Borrar archivos reduce el tamaño del VMDK?
No necesariamente. En discos finos, primero debes notificar los bloques libres (TRIM/ReTrim) y, si hay snapshots, consolidarlos. Algunas operaciones de “shrink” o Storage vMotion pueden ayudar a reclamar espacio a nivel de datastore.
¿Es seguro desfragmentar en producción?
La desfragmentación en Windows moderno es on-line, pero puede impactar IO. Programa la tarea en ventanas de baja actividad y monitoriza latencia.
¿Qué hago si TreeSize no muestra System Volume Information?
Ejecuta TreeSize como SYSTEM con PsExec, o usa vssadmin para medir VSS. Sin permisos adecuados, esa carpeta permanece oculta.
¿Cómo sé si TRIM está activo?
Con fsutil behavior query DisableDeleteNotify. Si devuelve 0, TRIM está habilitado.
Plantilla de trabajo (pasos ejecutivos)
- Medición inicial:
Get-Volume,fsutil fsinfo ntfsinfo, suma por carpetas. - Árbol de consumo: TreeSize como SYSTEM y captura de evidencias (pantallazos, tamaños por ruta).
- Higiene: limpiar VSS, Papelera y temporales; confirmar reducción de uso.
- Optimización: desfragmentar y ejecutar ReTrim.
- Hipervisor: consolidar snapshots; observar tamaño del VMDK y del datastore tras las acciones.
- Cierre: reportar métricas antes/después y documentar configuración final (clúster, TRIM, VSS).
Ejemplos de comandos útiles (Windows/PowerShell)
# 1) Resumen del volumen
Get-Volume D: | Format-List
2) Análisis de fragmentación (sin ejecutar aún la optimización)
defrag D: /A /V
3) Desfragmentación
defrag D: /U /V
4) TRIM/ReTrim
Optimize-Volume D: -ReTrim -Verbose
5) VSS
vssadmin list shadowstorage
vssadmin delete shadows /for=D: /oldest
6) Papelera
Clear-RecycleBin -DriveLetter D -Force
7) Tamaño por carpeta (PowerShell)
\$path = "D:\Datos"
gci \$path -Directory | ForEach-Object {
\$size = (gci \$*.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum
\[PSCustomObject]@{ Carpeta = \$*.Name; GB = \[Math]::Round(\$size / 1GB, 2) }
} | Sort-Object GB -Descending | Format-Table -AutoSize Métricas de éxito: cómo validar que “volvió a la normalidad”
- Volumen Windows: la diferencia entre “Capacidad – Libre” debe aproximarse a la suma de “Tamaño en disco” de las carpetas principales + overhead razonable (MFT, journal y VSS si existe).
- Datastore VMware: el VMDK y su delta deben dejar de crecer; después de ReTrim/consolidación, el almacenamiento debe reflejarlo.
- Comparativa antes/después: reporta GB por carpeta, número de fragmentos y tiempos de copia.
Notas y precauciones
- Snapshots no son backups: úsalos por periodos cortos; cuanto más duren, más crecen.
- ReTrim no compacta por sí solo el VMDK, pero comunica bloques libres al hipervisor para su reclamación.
- Clúster NTFS: en volúmenes con archivos muy grandes, un clúster mayor puede reducir fragmentación; evalúa impacto en archivos pequeños.
- Permisos: manipular VSS y
System Volume Informationrequiere privilegios elevados; realiza respaldos antes de cambios relevantes.
Resumen ejecutivo (para llevar)
- Diagnostica con visibilidad total: TreeSize como SYSTEM para hallar consumidores ocultos.
- Corrige lo obvio: limpia VSS, Papelera y temporales.
- Optimiza: desfragmenta/optimiza NTFS y ejecuta
-ReTrim. - Cuida el hipervisor: consolida snapshots y vigila el VMDK.
- Comprende las métricas: “Tamaño”, “Tamaño en disco” y “tamaño del VMDK” no son la misma cosa.
Apéndice: comandos de referencia rápida
| Objetivo | Comando |
|---|---|
| Ver clúster NTFS | fsutil fsinfo ntfsinfo X: |
| Analizar fragmentación | defrag X: /A /V |
| Optimizar/Desfragmentar | defrag X: /U /V |
| Ejecutar TRIM/ReTrim | Optimize-Volume X: -ReTrim -Verbose |
| Listar uso de VSS | vssadmin list shadowstorage |
| Eliminar copia VSS más antigua | vssadmin delete shadows /for=X: /oldest |
| Comprobar TRIM habilitado | fsutil behavior query DisableDeleteNotify |
| Ver archivos comprimidos | compact /Q /S:X:\Ruta |
| Abrir TreeSize como SYSTEM | psexec -s -i "C:\Tools\TreeSize\TreeSize.exe" |
Conclusión: cuando el uso del almacenamiento “se dispara” tras mover archivos a una VM en VMware, no es magia negra: es una combinación de cómo NTFS organiza los datos, cómo los VMDK finos expanden su tamaño y cómo snapshots/VSS retienen bloques. Siguiendo el itinerario de diagnóstico (TreeSize como SYSTEM), la limpieza de consumos ocultos, la optimización/desfragmentación, el ReTrim y la correcta gestión de snapshots, el espacio vuelve a valores coherentes con el volumen real de datos. Y para la próxima migración, aplica el checklist posmigración para evitar sorpresas.