Encuentra archivos grandes rápido: PowerShell supera a cualquier aplicación ‘limpiadora’

Por qué PowerShell supera a las aplicaciones “limpiadoras” (en producción)

Las apps limpiadoras prometen “un clic”. Las personas de Operaciones deberían temer el “un clic”. No porque seas alérgico a la conveniencia, sino porque los sistemas de producción exigen evidencia, repetibilidad y un plan de reversión. PowerShell te da las tres cosas.

Las apps limpiadoras tienen tres problemas recurrentes

• Optimizan por apariencia, no por forense. Obtienes un gráfico de pastel y un botón verde. No obtienes un registro de auditoría que satisfaga seguridad, gestión de cambios o a tu yo del futuro.
• Adivinan. “Basura” es una categoría subjetiva. Tu “basura” puede ser una caché de negocio que evita una reconstrucción de 40 minutos durante horario laboral.
• Aumentan tu radio de impacto. Instalar binarios de terceros en servidores durante una caída es cómo los pequeños incidentes se vuelven investigaciones de una semana.

PowerShell es aburrido—and el aburrimiento gana

PowerShell puede escanear, ordenar, filtrar, exportar y volver a ejecutar la misma lógica el mes siguiente. Puedes revisar un script en code review. Puedes registrar la salida en un ticket. Puedes explicar tu decisión en lenguaje claro: “Top 50 archivos por tamaño bajo D:\Logs; eliminados archivos mayores a 30 días; conservados últimos 7 días de logs de IIS; verificado incremento de espacio libre en X.”

Además: PowerShell no requiere privilegios de administrador para hacer trabajo útil. En entornos cerrados, inventarios solo de lectura suelen ser suficiente para diagnosticar el problema y entregar la lista correcta al propietario adecuado.

Una cita para tener en la pared: “La esperanza no es una estrategia.” — Gene Kranz

Broma #1: Las apps limpiadoras son como pastillas para adelgazar—algunas funcionan, la mayoría no, y a todas les disgusta tu hígado. Los servidores no tienen hígado, pero sí tienen registros de auditoría.

Algunos hechos e historia que explican el desorden actual

La hinchazón de disco no apareció de la nada. Es el resultado predecible de décadas de comportamiento de Windows, hábitos de software empresarial y economía del almacenamiento. Aquí hay hechos concretos que aparecen en entornos reales:

1. NTFS soporta flujos de datos alternativos desde los años 90. La mayoría de las herramientas no los muestran. A muchos autores de malware les encantan. La mayoría de las apps “limpiadoras” los ignoran.
2. El caché de Windows Installer (MSI) es deliberado. Mantiene copias de los datos del instalador en C:\Windows\Installer para que las reparaciones y parches puedan ejecutarse después. Borrarlo “funciona” hasta que deja de funcionar.
3. El almacén de componentes de Windows Update (WinSxS) no es un caché simple. Forma parte del servicing. El tamaño en disco suele ser menor de lo que Explorer sugiere debido a hardlinks.
4. Pagefile e hibernación intercambian disco por estabilidad y velocidad. Muchos portátiles traen hibernación activada; muchas máquinas virtuales tienen pagefiles dimensionados para la peor presión de memoria.
5. Las instantáneas VSS pueden consumir espacio en silencio. Productos de backup, “Versiones anteriores” y snapshots consistentes con la aplicación usan shadow storage que crece hasta alcanzar su límite—o tu espacio libre.
6. “Los logs son baratos” se volvió mentira cuando los SSD se hicieron rápidos. Logging de alto rendimiento más discos OS pequeños es un modo clásico de fallo en Windows Server.
7. Los puntos de unión y reparse points pueden engañar a escaneos ingenuos. Si recorres recursivamente sin cuidado, puedes entrar en redirecciones estilo C:\Users\All Users y contar doble.
8. El USN Change Journal existe por una razón. Rastrea cambios del sistema de archivos para indexación/replicación/backup. Algunas cargas de trabajo lo churnean; puede crecer mucho en volúmenes ocupados.
9. Los PST de Outlook no han dejado de existir. Incluso con plataformas de correo modernas, aún encontrarás archivos PST de varios GB en recursos compartidos—normalmente en el lugar menos respaldado posible.

Guía de diagnóstico rápido: encuentra el cuello de botella antes de “limpiar”

Las alertas de disco a menudo ocultan el problema real: un proceso fuera de control, un trabajo de backup fallido, un spooler atascado o una política de retención que nunca existió. Esta guía es lo que haces cuando tienes 10 minutos y un canal de Slack que se está volviendo ruidoso.

Primero: verifica el síntoma y el alcance

• ¿Qué volumen está realmente bajo? No “el servidor.” El volumen. C: podría estar bien mientras un VHDX montado se está ahogando.
• ¿Está disminuyendo el espacio libre ahora mismo? Si sí, buscas a un escritor (logs, dumps, temp). Si no, buscas acumulación (retención, backups, instaladores).
• ¿Es una máquina o muchas? Muchas máquinas apunta a política, parcheo o despliegue de una app. Una máquina apunta a carga de trabajo local o corrupción.

Segundo: decide si necesitas “quién está escribiendo” o “qué es grande”

• Espacio libre cayendo rápido: mira los registros de eventos, procesos en ejecución y directorios que crecen (logs, temp, spool, crash dumps).
• Espacio libre estable pero bajo: haz inventario de los directorios y archivos más grandes; céntrate en datos propiedad de personas y caches de apps.

Tercero: identifica las zonas “no tocar”

La mayoría de los incidentes empeoran al borrar lo incorrecto. Antes de eliminar nada, marca esto como “manejar con cuidado”:

• C:\Windows y especialmente C:\Windows\Installer
• C:\Windows\WinSxS
• Archivos de disco de Hyper-V/VMware (.vhdx, .vmdk)
• Rutas de datos/log de bases de datos (SQL, Exchange, etc.)
• Repositorios de backup y almacenamiento de shadow copy

Cuarto: elige la válvula de alivio de menor riesgo

Si necesitas espacio inmediato para detener una caída, las opciones de menor riesgo suelen ser:

• Rotar/comprimir logs (logs de aplicaciones, logs de IIS) con retención conocida
• Limpiar %TEMP% para la cuenta de servicio relevante (con cuidado)
• Eliminar dumps antiguos si ya capturaste lo necesario
• Mover conjuntos de datos grandes a un volumen mayor (con los propietarios notificados)

Tareas prácticas (comandos, significado de la salida y decisiones)

A continuación hay tareas reales que puedes ejecutar en hosts Windows. Los comandos se muestran como si estuvieras en un prompt; la parte importante es el PowerShell que ejecutas. Cada tarea incluye: comando, qué significa la salida y qué decisión tomar a partir de ella.

Task 1: Confirma qué volúmenes están realmente bajos

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Sort-Object -Property DriveLetter | Select DriveLetter,FileSystemLabel,FileSystem,SizeRemaining,Size | Format-Table -AutoSize"
DriveLetter FileSystemLabel FileSystem SizeRemaining          Size
----------- -------------- ---------- -------------          ----
C           OS             NTFS       8.21 GB         127.87 GB
D           Data           NTFS       412.50 GB       931.51 GB
E           Logs           NTFS       900.12 MB        50.00 GB

Qué significa: E: es el fuego. C: no lo es. Esto evita el error clásico: limpiar la unidad equivocada porque alguien dijo “el servidor está lleno”.

Decisión: Enfoca los escaneos en E:\. Si E: está destinada a logs, revisa retención y escritores.

Task 2: Ver si el espacio libre está bajando en tiempo real (chequeo rápido)

cr0x@server:~$ powershell -NoProfile -Command "$d='E'; 1..5 | ForEach-Object { Get-Volume -DriveLetter $d | Select DriveLetter,SizeRemaining; Start-Sleep -Seconds 3 }"
DriveLetter SizeRemaining
----------- -------------
E           900.12 MB
E           892.44 MB
E           881.03 MB
E           870.77 MB
E           861.65 MB

Qué significa: Estás perdiendo espacio activamente. Eso es un escritor, no acumulación histórica.

Decisión: Prioriza directorios que están creciendo ahora (logs/temp/spool) y archivos con timestamps recientes.

Task 3: Encuentra los 50 archivos más grandes bajo una ruta

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'E:\' -File -Recurse -ErrorAction SilentlyContinue | Sort-Object Length -Descending | Select-Object -First 50 FullName, @{n='GB';e={[math]::Round($_.Length/1GB,2)}}, LastWriteTime | Format-Table -AutoSize"
FullName                                   GB  LastWriteTime
--------                                   --  -------------
E:\Logs\app\trace-2026-02-05.log           9.8 2/5/2026 2:10:12 AM
E:\Dumps\serviceA_2026_02_05_0211.dmp      4.2 2/5/2026 2:11:43 AM
E:\Logs\iis\W3SVC1\u_ex260205.log          1.1 2/5/2026 2:05:01 AM

Qué significa: Los grandes ofensores son obvios: un log de trazas y dumps de fallos se están comiendo el disco.

Decisión: Detén o reconfigura al escritor antes de borrar, o estarás haciendo la misma limpieza cada 10 minutos.

Task 4: Encuentra los directorios más grandes (rápido, sin módulos extra)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'E:\' -Directory -Force | ForEach-Object { $size=(Get-ChildItem -LiteralPath $_.FullName -File -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum; [pscustomobject]@{Path=$_.FullName; GB=[math]::Round($size/1GB,2)} } | Sort-Object GB -Descending | Select-Object -First 15 | Format-Table -AutoSize"
Path                 GB
----                 --
E:\Logs              38.44
E:\Dumps             10.21
E:\Temp               1.02

Qué significa: Confirma las “áreas grandes” para que no pierdas tiempo en directorios pequeños.

Decisión: Profundiza en los 1–2 directorios principales; ignora el resto hasta que hayas recuperado suficiente espacio.

Task 5: Identificar crecimiento reciente (archivos más grandes escritos en las últimas 24 horas)

cr0x@server:~$ powershell -NoProfile -Command "$since=(Get-Date).AddHours(-24); Get-ChildItem -LiteralPath 'E:\' -File -Recurse -ErrorAction SilentlyContinue | Where-Object LastWriteTime -ge $since | Sort-Object Length -Descending | Select-Object -First 30 FullName, @{n='MB';e={[math]::Round($_.Length/1MB,1)}}, LastWriteTime | Format-Table -AutoSize"
FullName                                   MB   LastWriteTime
--------                                   --   -------------
E:\Logs\app\trace-2026-02-05.log           10032.0 2/5/2026 2:10:12 AM
E:\Dumps\serviceA_2026_02_05_0211.dmp       4300.4 2/5/2026 2:11:43 AM

Qué significa: Confirma que son archivos frescos. Si los archivos más grandes son antiguos, el problema es retención. Si son nuevos, es un incidente en vivo.

Decisión: Escala al propietario de la aplicación con evidencia: rutas exactas y timestamps.

Task 6: Mostrar tipos de archivos que consumen espacio (agrupar por extensión)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'E:\' -File -Recurse -ErrorAction SilentlyContinue | Group-Object Extension | ForEach-Object { $sum=($_.Group | Measure-Object Length -Sum).Sum; [pscustomobject]@{Ext=$_.Name; Count=$_.Count; GB=[math]::Round($sum/1GB,2)} } | Sort-Object GB -Descending | Select-Object -First 15 | Format-Table -AutoSize"
Ext   Count GB
---   ----- --
.log   1242 29.10
.dmp     14 10.21
.zip    188  3.44

Qué significa: Tu espacio es mayormente logs y dumps. Eso es solucionable operativamente.

Decisión: Implementa rotación/compresión para .log, y configura retención de dumps o muévelos a un volumen mayor.

Task 7: Encuentra archivos enormes en rutas de “Users” (a menudo causados por humanos)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'C:\Users' -File -Recurse -ErrorAction SilentlyContinue | Where-Object Length -gt 2GB | Sort-Object Length -Descending | Select FullName, @{n='GB';e={[math]::Round($_.Length/1GB,2)}}, LastWriteTime | Format-Table -AutoSize"
FullName                                                  GB LastWriteTime
--------                                                  -- -------------
C:\Users\jdoe\Downloads\vm-image.vhdx                    22.5 1/12/2026 4:44:02 PM
C:\Users\jdoe\AppData\Local\Temp\installer-cache.bin      3.1 2/4/2026 9:01:15 AM

Qué significa: Un perfil de usuario aloja algo que pertenece en un disco de datos, no en el disco del OS.

Decisión: Muévelo (no lo borres) si es legítimo, o aplica políticas de limpieza de perfiles si es basura.

Task 8: Comprueba el tamaño de la Papelera (sorprendentemente efectivo en hosts compartidos)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'C:\$Recycle.Bin' -Force -ErrorAction SilentlyContinue | Select Name,FullName | Format-Table -AutoSize"
Name                                   FullName
----                                   --------
S-1-5-21-2222222222-3333333333-4444444444-1001 C:\$Recycle.Bin\S-1-5-21-2222222222-3333333333-4444444444-1001

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'C:\$Recycle.Bin' -Force -Recurse -ErrorAction SilentlyContinue | Measure-Object Length -Sum | Select @{n='GB';e={[math]::Round($_.Sum/1GB,2)}}"
GB
--
14.72

Qué significa: Los archivos eliminados aún consumen disco. En hosts RDS y servidores compartidos, esto puede ser un asesino silencioso.

Decisión: Vacía las papeleras mediante políticas o limpieza dirigida—tras confirmar las expectativas sobre datos de usuario en el host.

Task 9: Inspeccionar uso de almacenamiento de shadow copy (VSS)

cr0x@server:~$ powershell -NoProfile -Command "vssadmin list shadowstorage"
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2013 Microsoft Corp.

Shadow Copy Storage association
   For volume: (E:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
   Shadow Copy Storage volume: (E:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
   Used Shadow Copy Storage space: 18.432 GB (36%)
   Allocated Shadow Copy Storage space: 20.000 GB (40%)
   Maximum Shadow Copy Storage space: 20.000 GB (40%)

Qué significa: VSS ha reclamado 20 GB. En un volumen de logs de 50 GB, eso es agresivo.

Decisión: Si VSS no es necesario para ese volumen, reduce el tamaño máximo o reubícalo. Coordina primero con los propietarios de backup/restore.

Task 10: Identificar dumps de Windows Error Reporting y artefactos de crash

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'C:\ProgramData\Microsoft\Windows\WER' -Recurse -File -ErrorAction SilentlyContinue | Sort-Object Length -Descending | Select-Object -First 20 FullName,@{n='MB';e={[math]::Round($_.Length/1MB,1)}},LastWriteTime | Format-Table -AutoSize"
FullName                                                                 MB  LastWriteTime
--------                                                                 --  -------------
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_serviceA... 950.2 2/5/2026 1:58:03 AM

Qué significa: Los fallos están dejando evidencia. Bueno para depuración, malo para discos pequeños.

Decisión: Si el incidente está en curso, conserva los artefactos más recientes y purga los más antiguos después de haberlos capturado para ingeniería.

Task 11: Comprobar tamaño de logs de IIS y aplicar retención con seguridad

cr0x@server:~$ powershell -NoProfile -Command "$p='C:\inetpub\logs\LogFiles'; Get-ChildItem -LiteralPath $p -File -Recurse -ErrorAction SilentlyContinue | Measure-Object Length -Sum | Select @{n='GB';e={[math]::Round($_.Sum/1GB,2)}}"
GB
--
33.87

cr0x@server:~$ powershell -NoProfile -Command "$p='C:\inetpub\logs\LogFiles'; $cut=(Get-Date).AddDays(-30); Get-ChildItem -LiteralPath $p -File -Recurse -ErrorAction SilentlyContinue | Where-Object LastWriteTime -lt $cut | Select-Object -First 5 FullName,LastWriteTime | Format-Table -AutoSize"
FullName                                      LastWriteTime
--------                                      -------------
C:\inetpub\logs\LogFiles\W3SVC1\u_ex251201.log 12/1/2025 12:00:00 AM
C:\inetpub\logs\LogFiles\W3SVC1\u_ex251202.log 12/2/2025 12:00:00 AM

Qué significa: Puedes recuperar espacio eliminando logs anteriores a la retención. La vista previa muestra qué archivos se verían afectados.

Decisión: Si 30 días es aceptable para tu organización, elimina esos logs antiguos (o comprímelos). Siempre haz una vista previa primero.

Task 12: Exportar un inventario para auditoría y escalado

cr0x@server:~$ powershell -NoProfile -Command "$root='E:\'; Get-ChildItem -LiteralPath $root -File -Recurse -ErrorAction SilentlyContinue | Sort-Object Length -Descending | Select-Object FullName,Length,LastWriteTime | Select-Object -First 500 | Export-Csv -NoTypeInformation -Path 'C:\Temp\top500-files.csv'; Get-Item 'C:\Temp\top500-files.csv' | Select Name,Length"
Name              Length
----              ------
top500-files.csv  189432

Qué significa: Ahora tienes un artefacto compartible: evidencia para tickets, aprobaciones y seguimiento.

Decisión: Adjunta el CSV al incidente. Haz que la propiedad sea responsabilidad de alguien más con datos, no con sensaciones.

Task 13: Encontrar archivos mayores que un umbral (objetivo quirúrgico)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'E:\' -File -Recurse -ErrorAction SilentlyContinue | Where-Object Length -gt 1GB | Sort-Object Length -Descending | Select FullName, @{n='GB';e={[math]::Round($_.Length/1GB,2)}}, LastWriteTime | Format-Table -AutoSize"
FullName                                   GB  LastWriteTime
--------                                   --  -------------
E:\Logs\app\trace-2026-02-05.log           9.8 2/5/2026 2:10:12 AM
E:\Dumps\serviceA_2026_02_05_0211.dmp      4.2 2/5/2026 2:11:43 AM

Qué significa: Una lista corta de archivos “sobre los que vale la pena discutir”.

Decisión: Para cada archivo: conservar, mover, comprimir o eliminar—con un propietario y una razón.

Task 14: Encontrar directorios con grandes contajes de archivos pequeños (dolor para rendimiento y backup)

cr0x@server:~$ powershell -NoProfile -Command "$p='E:\Logs'; Get-ChildItem -LiteralPath $p -Directory -Recurse -ErrorAction SilentlyContinue | ForEach-Object { $c=(Get-ChildItem -LiteralPath $_.FullName -File -ErrorAction SilentlyContinue).Count; if($c -gt 5000){ [pscustomobject]@{Path=$_.FullName; FileCount=$c} } } | Sort-Object FileCount -Descending | Select-Object -First 10 | Format-Table -AutoSize"
Path                     FileCount
----                     ---------
E:\Logs\app\debug-archive 18234

Qué significa: No siempre son “archivos grandes.” Un conteo masivo de archivos ralentiza escaneos, backups y antivirus.

Decisión: Rota, comprime en archivos o rediseña el logging. Para carpetas de “archivo”, considera ZIP mensuales y eliminar originales tras verificación.

Task 15: Detectar reparse points/junctions para evitar doble conteo

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'C:\' -Directory -Force -ErrorAction SilentlyContinue | Where-Object { $_.Attributes -match 'ReparsePoint' } | Select FullName,Attributes | Format-Table -AutoSize"
FullName                     Attributes
--------                     ----------
C:\Documents and Settings     Directory, ReparsePoint

Qué significa: Recorrer sin cuidado puede provocar bucles o volver a atravesar rutas redirigidas.

Decisión: Excluye o maneja reparse points explícitamente en escaneos profundos en volúmenes del SO.

Task 16: Ver si escanear un recurso compartido de red tiene sentido (latencia primero)

cr0x@server:~$ powershell -NoProfile -Command "Test-Path '\\fileserver01\deptshare'; (Get-Date); Get-ChildItem '\\fileserver01\deptshare' -ErrorAction Stop | Select-Object -First 5 Name | Format-Table -AutoSize; (Get-Date)"
True
02/05/2026 02:20:01
Name
----
Accounting
Engineering
Legal
Marketing
Projects
02/05/2026 02:20:03

Qué significa: Listar básico toma ~2 segundos. Eso es manejable; si tomara 30–60 segundos, un escaneo recursivo sería un suplicio.

Decisión: Si el share es lento, escanea fuera de horario, escanea primero el nivel superior o ejecuta el escaneo localmente en el servidor de archivos.

Broma #2: Las herramientas de limpieza adoran decir “Encontrados 38 GB de basura.” Si realmente fueran basura, no estarían en tu almacenamiento más caro.

Tres mini-historias corporativas desde las trincheras del espacio en disco

Mini-historia 1: El incidente causado por una suposición incorrecta

Un equipo heredó una VM Windows Server que ejecutaba una API orientada al cliente. La alerta fue simple: “C: por debajo del 5% libre.” El ingeniero on-call hizo lo que muchos hemos hecho bajo presión: abrió Explorer, clic derecho en C: y pulsó “Liberar espacio en disco”. Liberó un poco de espacio, y la alerta se silenció. Durante una hora.

La alerta regresó, más dura. Esta vez el servicio comenzó a tener timeouts. El ingeniero asumió “los logs están creciendo” y borró un puñado de archivos .log de una carpeta de la aplicación. El servicio se recuperó de nuevo—brevemente. Luego se cayó por completo.

El verdadero culpable no eran los logs de la app. Era una nueva configuración de diagnóstico que activó trazas verbosas de solicitudes en C:\Windows\Temp bajo una cuenta de servicio. El servicio escribía archivos de traza enormes continuamente. Borrar archivos trató el síntoma, no la enfermedad.

Una vez que usaron PowerShell para listar “los archivos más grandes escritos en la última hora”, el patrón fue obvio: gigabytes de trazas temporales frescas. Desactivaron la configuración, movieron la ruta de trazas a un volumen de datos más grande y añadieron retención.

La suposición equivocada fue “esto es hinchazón de disco estándar.” Era un incidente de amplificación de escritura activo. En producción, la dirección del tiempo importa: ¿el disco se está llenando ahora, o se llenó durante meses?

Mini-historia 2: La optimización que salió mal

Otra empresa tenía un servidor de archivos donde los usuarios se quejaban de búsquedas lentas y carpetas que tardaban en abrir. Alguien propuso una “optimización”: deduplicar almacenamiento archivando directorios antiguos en ZIPs y moviéndolos a un único recurso \Archive. Menos desorden, menos archivos, menos problemas—en papel.

Ejecutaron un script que comprimía todo lo anterior a 180 días. Sí redujo el conteo de archivos. También creó un nuevo modo de fallo: ZIPs gigantes que cambiaban cuando se añadía un solo archivo, provocando que los backups volvieran a copiar archivos de varios GB repetidamente. La ventana de backup se amplió y empezó a chocar con horario laboral.

Peor aún, el antivirus tenía que abrir enormes archivos para escanearlos, provocando picos de CPU. Una “limpieza” también se convirtió en una regresión de rendimiento. A los usuarios no les impresionó la “eficiencia comprimida” cuando Explorer se congelaba.

La solución no fue abandonar la limpieza. Fue hacerlo correctamente: archivar de forma inmutable (mensual, conjuntos cerrados), mantener los archivos de archivo como solo lectura y usar políticas de retención alineadas con la estrategia de backup. PowerShell les ayudó a cuantificar el cambio: conteo de archivos, tamaño total y “archivos modificados en los últimos N días” para evitar churn en los archivos.

La optimización sale mal cuando ignora sistemas descendentes: backups, AV, indexación y restauraciones. El espacio en disco nunca es solo espacio en disco.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

En un entorno regulado, un servidor de aplicaciones Windows manejaba importaciones por lotes cada noche. El equipo tenía una práctica aburrida: cada despliegue incluía un informe de uso de disco adjunto al ticket de cambio. No era glamoroso. Era un pequeño script PowerShell que exportaba los directorios principales y tipos de archivo a CSV.

Una noche, el espacio libre disminuyó más rápido de lo habitual. El ingeniero on-call no adivinó. Sacó los últimos tres CSVs y los comparó. Apareció una carpeta nueva bajo D:\Data\Import\Staging con un aumento brusco de archivos .tmp. Los timestamps coincidían con un importador recién desplegado.

El desarrollador en turno inicialmente argumentó que “no podía ser nuestro” porque el importador limpia archivos temporales. El informe no se dejó convencer. Mostró 120.000 archivos temporales creados durante el job y nunca eliminados cuando el job falló a mitad de ejecución.

Como el equipo ya tenía un informe rutinario, la respuesta al incidente fue quirúrgica: eliminar archivos temp mayores a 7 días, arreglar el importador para limpiar en rutas de fallo y limitar el espacio de staging. Sin clics frenéticos, sin herramientas misteriosas, sin borrado accidental de instaladores o archivos del sistema.

Por eso las prácticas aburridas ganan. Crean líneas base. Las líneas base convierten disputas en soluciones.

Errores comunes: síntoma → causa raíz → solución

1) “Explorer dice que WinSxS es enorme”

Síntoma: Ves una carpeta gigante C:\Windows\WinSxS en Explorer y entras en pánico.

Causa raíz: Explorer sobreestima el tamaño porque no tiene en cuenta los hardlinks de servicing como piensas.

Solución: No borres archivos en WinSxS. Usa métodos de limpieza de servicing soportados (y coordina ventanas de parches). Usa escaneos PowerShell para encontrar bloat no sistema primero.

2) “Borramos cosas pero el disco se llena inmediatamente otra vez”

Síntoma: Liberas 10 GB; desaparecen en 15 minutos.

Causa raíz: Escritor activo (logging verboso, generación masiva de dumps, archivos temp en bucle, cola atascada).

Solución: Identifica escrituras recientes (LastWriteTime), luego detén/reconfigura al escritor. Borrar sin arreglar es regalar tu sueño a la entropía.

3) “La app limpiadora liberó espacio y luego las actualizaciones fallaron”

Síntoma: Tras la “limpieza”, el parcheo o reparación de apps falla por recursos del instalador faltantes.

Causa raíz: Alguien borró el caché MSI o archivos del instalador del sistema (C:\Windows\Installer).

Solución: Restaura desde backup si es posible; de lo contrario reinstala las apps afectadas. En adelante: trata los directorios del sistema como solo lectura a menos que tengas un procedimiento aprobado por el proveedor.

4) “El escaneo de uso de disco tarda una eternidad o entra en bucle”

Síntoma: Los escaneos recursivos nunca terminan, muestran duplicados o disparan CPU.

Causa raíz: Seguir reparse points/junctions; escanear shares de red en enlaces lentos; interferencia de antivirus.

Solución: Detecta reparse points, escanea desde el lado del servidor y comienza por directorios de nivel superior antes de recurrir a recursión profunda.

5) “Los backups de repente crecieron tras la limpieza”

Síntoma: Los jobs de backup comienzan a transferir mucha más data.

Causa raíz: Archivar/comprimir cambió muchos archivos o creó archivos monolíticos que churnean.

Solución: Usa límites de archivo inmutables, evita reescribir grandes archivos de archivo y coordina la estrategia de backup con la limpieza.

6) “Borramos logs y la app dejó de loguear”

Síntoma: Tras la eliminación, la app no puede escribir logs o se comporta raro.

Causa raíz: La app tenía un handle abierto; la eliminación causó confusión en la rotación de logs; permisos/ACL se rompieron; la app espera que la ruta exista.

Solución: Prefiere truncamiento/mecanismos de rotación, conserva la estructura de directorios, reinicia servicios si hace falta y establece políticas de retención explícitas.

Listas de verificación / plan paso a paso

Checklist A: “Estamos bajos de disco ahora mismo” (modo incidente)

1. Identificar el volumen (Task 1). Anótalo en el ticket.
2. Comprobar si el espacio está cayendo (Task 2). Si sí, trátalo como escritor activo.
3. Obtener los archivos recientes más grandes (Task 5). Captura los top 30 y sus timestamps.
4. Encontrar los tipos de archivo principales (Task 6). Logs/dumps/temp son comunes.
5. Elegir el alivio de menor riesgo: logs antiguos, dumps antiguos, temp mayores que una ventana.
6. Exportar evidencia (Task 12) antes de borrar algo significativo.
7. Arreglar al escritor: cambio de configuración, rotación, reubicación de ruta, retención o corrección de bug.
8. Verificar la recuperación: espacio libre estable; servicios sanos; monitorización quieta.

Checklist B: “Seguimos quedándonos sin disco cada mes” (modo ingeniería)

1. Establecer línea base de uso de disco semanal con exportes scriptados (top dirs, top tipos de archivo).
2. Separar volúmenes de logs de volúmenes del SO cuando sea posible. Discos C: pequeños y apps verbosas no conviven tranquilamente.
3. Definir retención por tipo de log (logs de seguridad difieren de logs de depuración).
4. Aplicar límites: almacenamiento VSS, carpetas de staging, directorios spool.
5. Hacer visibles a los propietarios: mapear rutas principales a equipos o aplicaciones; publicar una tabla simple de propietarios.
6. Automatizar la limpieza solo después de probar que es segura con vistas previas y dry runs.

Checklist C: “Necesitamos escanear un gran recurso compartido” (modo sensatez)

1. Ejecuta el escaneo desde el servidor de archivos si es posible (reduce ruido de red).
2. Comienza por directorios de nivel superior; no recorras todo recursivamente de entrada.
3. Mide la latencia de listado de directorios básica (Task 16). Si es lento, programa fuera de horas.
4. Exporta resultados a CSV y deja que los dueños de datos decidan qué eliminar.

Preguntas frecuentes

1) ¿Por qué no usar una herramienta GUI como WinDirStat o TreeSize?

En una estación de trabajo, bien. En un servidor durante un incidente, PowerShell gana porque es nativo, scriptable, revisable y fácil de ejecutar remotamente. Además: puedes exportar evidencia.

2) ¿Es seguro escanear con PowerShell en servidores de producción?

Los escaneos de solo lectura son generalmente seguros, pero pueden ser intensivos en I/O en volúmenes ocupados. Empieza de forma dirigida (directorios de nivel superior, escrituras recientes) y evita escanear recursos compartidos enteros en horas pico.

3) ¿Cuál es la forma más rápida de encontrar “qué cambió”?

Filtra por LastWriteTime (Task 5) y ordena por tamaño. Te dice qué creció recientemente y suele ser suficiente para identificar al escritor.

4) ¿Puedo eliminar archivos directamente desde PowerShell?

Sí, pero hazlo solo tras una vista previa y una exportación. Eliminar es fácil; explicarlo después es lo difícil. Usa reglas de retención (más antiguo que X días) y guarda un registro.

5) ¿Por qué mi escaneo omite algunos archivos?

Los permisos y directorios bloqueados son comunes. Usa -ErrorAction SilentlyContinue para inventario, pero si necesitas completitud, ejecuta con los derechos apropiados y registra los errores.

6) ¿Por qué difiere el “tamaño de carpeta” entre herramientas?

Hardlinks, reparse points y diferencias entre herramientas en qué cuentan. Además, algunas herramientas cuentan tamaño asignado vs tamaño lógico. Para decisiones, céntrate en “archivos grandes por ruta” y “qué está creciendo”.

7) ¿Cómo manejo que VSS ocupe espacio en un volumen?

Primero confirma si debe existir en ese volumen (Task 9). Si no, reduce el máximo o mueve el almacenamiento shadow—tras coordinar con requisitos de backup/restore.

8) ¿Cómo escaneo un recurso compartido de red sin volverme odioso?

Ejecuta el escaneo en el servidor de archivos, limita la profundidad de recursión inicialmente y programa escaneos profundos fuera de horas. Exporta resultados y deja que los propietarios decidan qué es borrable.

9) ¿Cuál es el mayor “no hagas esto” en limpieza de Windows?

No borres cosas al azar bajo C:\Windows (especialmente Installer y WinSxS) porque algún blog dijo que es “seguro.” Usa herramientas de servicing soportadas y limpia datos de aplicaciones en su lugar.

10) ¿Cómo hago esto repetible para mi equipo?

Convierte las Tasks 1, 3/4, 5, 6 y 12 en un pequeño script que escriba CSVs en una ubicación conocida y adjúntalo a runbooks de incidentes. La repetibilidad es todo el punto.

Conclusión: siguientes pasos que no te perseguirán

Las apps limpiadoras venden una historia: el uso de disco es un misterio y solo su botón mágico puede arreglarlo. La producción es lo opuesto. El uso de disco es conocible. Son solo archivos, timestamps y propiedad. PowerShell convierte “nos quedamos sin espacio” en una lista sobre la que puedes actuar.

Haz esto a continuación

1. Elige un host que rutinariamente se llene y ejecuta las Tasks 1, 4, 6 y 12. Guarda el CSV.
2. Identifica los 3 principales ofensores (directorios o tipos de archivo) y asigna propietarios.
3. Implementa una política de retención (logs, dumps, temp) con un flujo de trabajo de vista previa.
4. Vuelve a ejecutar los mismos comandos la próxima semana y compara. Si el mismo ofensor vuelve, no arreglaste al escritor—solo la evidencia.
5. Escríbelo en tu runbook: “Cuando disco bajo: ejecuta estos comandos, exporta este CSV, contacta a estos propietarios.” Hazlo aburrido a propósito.

Si quieres un sistema que se mantenga limpio, deja de comprar “limpieza”. Empieza a comprar “medición”. PowerShell es la regla de medición que ya tienes.