Швидко знайти великі файли: PowerShell кращий за будь-яку програму очищення

Чому PowerShell кращий за «програми очищення» (у продакшні)

Програми очищення обіцяють «один клік». Операційним інженерам слід боятися «одного кліка». Не тому, що ви проти зручності, а тому, що продакшн-системи потребують доказів, відтворюваності та плану відкату. PowerShell дає всі три.

У програм очищення три постійні проблеми

• Вони оптимізовані під враження, а не під судову експертизу. Ви отримуєте кругову діаграму і зелену кнопку. Ви не отримуєте аудиторський слід, який задовольнить безпеку, управління змінами чи ваше майбутнє «я».
• Вони здогадуються. «Сміття» — суб’єктивна категорія. Ваше «сміття» може бути кешем бізнес-додатку, який зберігає відновлення у 40 хвилин під час робочого часу.
• Вони розширюють радіус впливу. Встановлення сторонніх бінарників на сервери під час аварії — шлях, як дрібні інциденти перетворюються на тижневі розслідування.

PowerShell нудний — і нудьга виграє

PowerShell може сканувати, сортувати, фільтрувати, експортувати та повторно виконувати ту саму логіку наступного місяця. Ви можете переглянути скрипт у код-рев’ю. Ви можете логувати вивід у тікет. Ви можете пояснити своє рішення простою мовою: «Топ‑50 файлів за розміром під D:\Logs; видалені файли старші за 30 днів; збережено останні 7 днів логів IIS; підтверджено збільшення вільного місця на X.»

Також: PowerShell не вимагає прав адміністратора для виконання корисної роботи. У жорстко обмежених середовищах інвентар у режимі лише для читання часто достатній, щоб діагностувати проблему і передати правильний список відповідальному власнику.

Цитата для стіни: «Надія — це не стратегія.» — Джин Кранц

Жарт №1: Програми очищення схожі на дієтичні таблетки — деякі працюють, більшість ні, і всі ненавидять вашу печінку. Сервери печінки не мають, але мають журнали аудиту.

Кілька фактів і історія, що пояснюють сучасний безлад

Зайняття дискового простору не з’явилося нізвідки. Це передбачуваний результат десятиліть поведінки Windows, звичок корпоративного ПЗ і економіки зберігання. Ось конкретні факти, що зустрічаються в реальних середовищах:

1. NTFS підтримує альтернативні потоки даних з 1990‑х. Більшість інструментів їх не показують. Багатьом авторам шкідливого ПЗ вони подобаються. Більшість «очищувачів» їх ігнорують.
2. Кеш Windows Installer (MSI) зроблений навмисно. Він зберігає копії інсталяційних даних у C:\Windows\Installer, щоб ремонти та патчі могли запускатися пізніше. Видаляти його «працює» — поки не перестає працювати.
3. Компонентне сховище Windows Update (WinSxS) — не простий кеш. Це частина обслуговування. Розмір на диску часто менший, ніж показує Провідник через жорсткі посилання.
4. Файл підкачки і гібернація міняють диск на стабільність і швидкість. Багато ноутбуків постачаються з увімкненою гібернацією; багато VM мають файл підкачки, розмірений під гірший сценарій навантаження пам’яті.
5. VSS‑знімки можуть тихо споживати величезний простір. Продукти резервного копіювання, «Попередні версії» та знімки консистентності додатків використовують shadow storage, який росте до ліміту — або до вашого вільного місця.
6. «Логи — дешеві» перестало бути правдою з появою швидких SSD. Високопродуктивне логування плюс малі системні диски — класичний режим відмови Windows Server.
7. Точки підключення (junction) і reparse point можуть заплутати прості скани. Якщо рекурсувати без обережності, можна зациклитися у перенаправленнях типу C:\Users\All Users і двічі порахувати.
8. USN Change Journal існує не просто так. Він відстежує зміни файлової системи для індексації/реплікації/бекапів. Деякі навантаження сильно його «трясуть»; він може збільшитися на завантажених томах.
9. PST‑файли Outlook нікуди не поділися. Навіть з сучасними поштовими платформами ви все ще знайдете багатогігабайтні PST‑архіви на шарінгах — зазвичай у найменш резервованому місці.

План швидкої діагностики: знайдіть вузьке місце до того, як «почистите»

Сповіщення про диск часто приховують реальну проблему: процес безконтрольно пише, збійний бекап, застряглий спулер або політика утримання, яка ніколи не існувала. Цей план — те, що робити, коли у вас є 10 хвилин і Slack‑канал уже галасує.

По-перше: перевірте симптом і масштаб

• Який том реально має мало місця? Не «сервер». Сам том. C: може бути в порядку, а змонтований VHDX тоне.
• Чи падає вільне місце зараз? Якщо так — ви полюєте на писача (логи, дампи, temp). Якщо ні — ви шукаєте накопичення (ретеншн, бекапи, інсталятори).
• Це один сервер чи багато? Багато серверів вказує на політику, патчинг або розгортання додатку. Один сервер вказує на локальне навантаження або корупцію.

По-друге: вирішіть, що вам потрібно — «хто пише» чи «що велике»

• Якщо вільне місце швидко падає: дивіться журнали подій, запущені процеси та директорії, що ростуть (логи, temp, spool, дампи).
• Якщо вільне місце стабільно, але мало: інвентаризуйте найбільші директорії й файли; фокусуйтеся на даних, що належать людям, та кешах додатків.

По-третє: визначте зони «не чіпати»

Більшість інцидентів погіршується через видалення неправильних речей. Перш ніж щось видаляти, позначте ці зони як «обережно»:

• C:\Windows і особливо C:\Windows\Installer
• C:\Windows\WinSxS
• Файли дисків Hyper‑V/VMware (.vhdx, .vmdk)
• Шляхи даних/логів баз даних (SQL, Exchange тощо)
• Репозиторії резервних копій і сховище теневих копій

По‑четверте: оберіть найменш ризиковий клапан для полегшення

Якщо вам потрібен негайний простір, щоб зупинити відмови, найменш ризикові варіанти зазвичай:

• Ротація/сжаття логів (логи додатків, IIS) з відомою політикою утримання
• Очищення %TEMP% для відповідного сервісного облікового запису (обережно)
• Видалення старих дампів, якщо ви вже зафіксували потрібні дані
• Переміщення великих, відомих наборів даних на більший том (попередивши власників)

Практичні завдання (команди, значення виводу та рішення)

Нижче — реальні завдання, які можна виконати на Windows‑хостах. Команди показані так, ніби ви на shell‑промпті; важлива частина — PowerShell, який ви виконуєте. Кожне завдання включає: команду, що означає вивід і яке рішення з нього випливає.

Завдання 1: Підтвердити, які томи реально мають мало місця

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

Що це означає: E: — це вогнище. C: — ні. Це запобігає класичній помилці: очищати неправильний диск, бо хтось сказав «сервер заповнений».

Рішення: Сконцентруйте скани на E:\. Якщо E: призначений для логів — перевірте ретеншн і писачів.

Завдання 2: Перевірити, чи падає вільне місце в реальному часі (швидка перевірка)

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

Що це означає: Ви втрачаєте простір зараз. Це писач, а не історичне накопичення.

Рішення: Пріоритезуйте директорії, що ростуть прямо зараз (логи/temp/spool) і файли з недавніми часовими відмітками.

Завдання 3: Знайти топ‑50 найбільших файлів під шляхом

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

Що це означає: Винуватці очевидні: лог трасування і дампи падають на диск.

Рішення: Зупиніть або переналаштуйте писача перед видаленням, інакше доведеться чистити що 10 хвилин.

Завдання 4: Знайти найбільші директорії (досить швидко, без додаткових модулів)

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

Що це означає: Підтверджує «великі зони», щоб не витрачати час на крихітні папки.

Рішення: Заглибіться в топ‑1–2 директорії; ігноруйте решту, доки не буде повернуто достатньо місця.

Завдання 5: Виявити недавній ріст (найбільші файли, записані за останні 24 години)

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

Що це означає: Підтверджує, що файли свіжі. Якщо найбільші файли старі — проблема в ретеншні. Якщо вони нові — це активний інцидент.

Рішення: Ескалюйте власнику додатку з доказами: точні шляхи й часові відмітки.

Завдання 6: Показати типи файлів, що споживають місце (групування за розширенням)

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

Що це означає: Місткість займають переважно логи і дампи. Це операційно вирішувано.

Рішення: Впровадьте ротацію/сжаття для .log, налаштуйте ретеншн дампів або перемістіть їх на більший том.

Завдання 7: Знайти великі файли в шляхах «Users» (часто спричинені людьми)

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

Що це означає: У профілі користувача розміщено те, що належить на диску даних, а не на системному диску.

Рішення: Перемістіть (не видаляйте) якщо це легітимно, або втілюйте політики очищення профілів, якщо це сміття.

Завдання 8: Перевірити розмір Кошика (дивовижно ефективно на спільних хостах)

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

Що це означає: Видалені файли все ще займають диск. На RDS‑хостах і спільних серверах це може бути тихим вбивцею.

Рішення: Очистьте кошики через політику або цільову операцію — після підтвердження очікувань щодо даних користувачів на хості.

Завдання 9: Інспектувати використання shadow copy storage (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%)

Що це означає: VSS зайняв 20 GB. Для 50 GB лог‑тому це агресивно.

Рішення: Якщо VSS не потрібен на цьому томі — зменшіть максимум або перемістіть його. Попередньо погодьтеся з власниками бекапів/відновлення.

Завдання 10: Виявити дампи Windows Error Reporting та артефакти краху

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

Що це означає: Краші залишають сліди. Добре для відладки, погано для малих дисків.

Рішення: Якщо інцидент триває — збережіть найновіші артефакти і видаліть старі після того, як інженери їх зафіксують.

Завдання 11: Перевірити розмір логів IIS і застосувати безпечний ретеншн

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

Що це означає: Ви можете повернути місце, видаливши логи старші за політику утримання. Прев’ю показує, які файли постраждають.

Рішення: Якщо 30 днів прийнятні для вашої організації — видаліть старі логи (або стисніть їх). Завжди переглядайте перед виконанням.

Завдання 12: Експортувати інвентар для аудиту та ескалації

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

Що це означає: Тепер у вас є об’єкт, яким можна ділитися: доказ для тікетів, погоджень і подальших дій.

Рішення: Додайте CSV до інциденту. Передайте власність іншій команді з даними, а не з враженнями.

Завдання 13: Знайти файли більші за поріг (суджена цільова операція)

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

Що це означає: Короткий список файлів, про які варто сперечатися.

Рішення: Для кожного файлу: зберегти, перемістити, стиснути або видалити — з визначеним власником і причиною.

Завдання 14: Знайти директорії з великою кількістю дрібних файлів (проблема продуктивності та бекапу)

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

Що це означає: Проблема не завжди у великих файлах. Величезна кількість файлів уповільнює скани, бекапи й антивірус.

Рішення: Ротувати, архівувати в ZIP або змінити підхід до логування. Для «архівних» папок розгляньте щомісячні ZIP і видалення оригіналів після перевірки.

Завдання 15: Виявити reparse point/junction, щоб уникнути подвійного підрахунку

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

Що це означає: Рекурсія без уваги може зациклитися або повторно проходити перенаправлені шляхи.

Рішення: Виключайте або обробляйте reparse point явно під час глибоких сканів на системних томах.

Завдання 16: Перевірити, чи сенс сканувати мережеву шара (спочатку латентність)

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

Що це означає: Просте перелічення займає ~2 секунди. Це прийнятно; якби воно тривало 30–60 секунд, рекурсивний скан був би катастрофою.

Рішення: Якщо шара повільна — скануйте в неробочий час, скануйте верхній рівень спочатку або виконуйте скан на сервері файлів локально.

Жарт №2: Інструменти очищення люблять казати «Знайдено 38 GB сміття». Якби це справді було сміттям, воно не лежало б на вашому найдорожчому сховищі.

Три корпоративні міні-історії з передової проблем дискового простору

Міні-історія 1: Інцидент, спричинений хибним припущенням

Команда отримала Windows Server VM, який запускав API для клієнтів. Сповіщення було простим: «C: менше 5% вільного». Інженер на виклику зробив те, що багато з нас робили під тиском: відкрив Провідник, клікнув правою кнопкою по C: і запустив «Очищення диска». Це звільнило трохи місця, і сповіщення втихло. На годину.

Сповіщення повернулося й стало гірше. Цього разу сервіс почав таймаутити. Інженер припустив, що «логи ростуть», і видалив кілька файлів .log з папки додатку. Сервіс відновився знову — недовго. Потім він повністю впав.

Справжній винуватець не був у логах додатку. Це була нова діагностична настройка, що увімкнула детальне трасування запитів у C:\Windows\Temp під сервісним обліковим записом. Сервіс безупинно писав величезні трасувальні файли. Видалення файлів лікувало симптом, а не хворобу.

Коли вони використали PowerShell, щоб перерахувати «найбільші файли, записані за останню годину», патерн став очевидним: гігабайти свіжих тимчасових трас. Вони відключили налаштування, перемістили шлях трас до більшого тома даних і додали ретеншн.

Хибне припущення було: «це стандартне заповнення диска». Насправді це був активний інцидент запису. У продакшні напрямок часу має значення: диск заповнюється зараз чи накопичувався місяцями?

Міні-історія 2: Оптимізація, що дала зворотний ефект

Інша компанія мала файловий сервер, де користувачі скаржилися на повільний пошук і перегляд папок. Хтось запропонував «оптимізацію»: дедуплікувати сховище, архівувавши старі директорії у ZIP і перемістивши їх у один шар \Archive. Менше безладу, менше файлів, менше проблем — на папері.

Вони запустили скрипт, що заархівував усе старіше за 180 днів. Це зменшило кількість файлів. Але це створило новий режим відмови: гігантські ZIP‑архіви, які змінювалися при додаванні одного файлу, змушували бекап повторно копіювати багатогиґабайтні архіви. Вікно бекапу розширилося і почало накладатися на робочий час.

Гірше: антивірус мусив розпаковувати величезні архіви, спричиняючи піки CPU. «Очищення» також стало регресією продуктивності. Користувачі не були в захваті від «ефективності стиснення», коли Провідник зависав.

Виправлення не полягало в скасуванні очищення. Треба було робити правильно: архівувати іммутабельно (щомісяця, закриті набори), робити архіви тільки для читання і узгоджувати політику з бекапом. PowerShell допоміг кількісно оцінити зміну: кількість файлів, загальний розмір і «файли, змінені за останні N днів», щоб уникнути мучення архівів.

Оптимізація провалюється, коли ігноруєте downstream‑системи: бекап, AV, індексацію і відновлення. Дисковий простір ніколи не буває лише дисковим простором.

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

У регульованому середовищі Windows‑сервер додатка обробляв нічні пакетні імпорти. Команда мала нудну практику: кожне розгортання включало звіт використання диска, прикріплений до тікета зміни. Це був невибагливий PowerShell‑скрипт, що експортував топ‑директорії й типи файлів у CSV.

Однієї ночі вільне місце впало швидше, ніж зазвичай. Інженер на виклику не здогадався. Він дістав останні три CSV і порівняв їх. У D:\Data\Import\Staging з’явилася нова папка з різким збільшенням файлів .tmp. Часові відмітки збігалися з новим імпортером.

Розробник на виклику спочатку наполягав, що це «не наш випадок», бо імпортер очищає тимчасові файли. Звіт не переймався аргументами. Він показав 120 000 тимчасових файлів, створених під час роботи й ніколи не видалених, коли процес аварійно завершився.

Оскільки команда вже мала рутинний звіт, реагування було хірургічним: видалити тимчасові файли старші за 7 днів, виправити імпортер, щоб чистився при збоях, і обмежити простір для стаджингу. Без панічних кліків, без загадкових інструментів, без випадкового видалення інсталяторів або системних файлів.

Ось чому нудні практики виграють. Вони формують базові показники. Базові показники перетворюють суперечки на виправлення.

Поширені помилки: симптом → корінна причина → виправлення

1) «Провідник каже, що WinSxS величезний»

Симптом: Ви бачите величезну папку C:\Windows\WinSxS в Провіднику і панікуєте.

Корінна причина: Провідник перебільшує розмір, бо не враховує обслуговуючі жорсткі посилання так, як ви думаєте.

Виправлення: Не видаляйте файли в WinSxS. Використовуйте підтримувані методи очищення обслуговування (і координуйте вікна патчів). Спочатку скануйте PowerShell‑ом на предмет не‑системного надлишку.

2) «Ми щось видалили, але диск знову заповнюється негайно»

Симптом: Ви вивільнили 10 GB; вони зникли за 15 хвилин.

Корінна причина: Активний писач (детальне логування, безупинне генерування дампів, циклічні тимчасові файли, застрягла черга).

Виправлення: Ідентифікуйте недавні записи (LastWriteTime), потім зупиніть/переналаштуйте писача. Видалення без фіксації проблеми — це просто жертвування вашим сном ентропії.

3) «Cleaner програма звільнила місце, а потім оновлення зламалися»

Симптом: Після «очищення» патчі або ремонт додатку зазнають помилок через відсутні ресурси інсталятора.

Корінна причина: Хтось видалив кеш MSI або системні файли інсталятора (C:\Windows\Installer).

Виправлення: Якщо можливо — відновіть з резервної копії; інакше перевстановіть уражені додатки. У майбутньому: тримайте системні директорії як доступні тільки за погодженими процедурами постачальника.

4) «Скан диска виконується вічно або зациклюється»

Симптом: Рекурсивні скани ніколи не закінчуються, показують дублі або спричиняють піки CPU.

Корінна причина: Слідування за reparse point/junction; сканування мережевих шар через повільні лінки; втручання антивірусу.

Виправлення: Виявляйте reparse point, скануйте з боку сервера і починайте з верхнього рівня, перш ніж іти в глибоку рекурсію.

5) «Після очищення бекапи раптом стали величезні»

Симптом: Роботи бекапу почали передавати значно більше даних.

Корінна причина: Архівування чи стиснення змінило багато файлів або створило монолітні архіви, що викликають повторну передачу.

Виправлення: Використовуйте іммутабельні межі архівів, уникайте перезапису великих архівів і координуйте стратегію бекапу з очищенням.

6) «Ми видалили логи і додаток перестав логувати»

Симптом: Після видалення додаток не може писати логи або поводиться дивно.

Корінна причина: Додаток мав відкритий дескриптор; видалення спричинило плутанину в ротації логів; зламалися дозволи/успадкування ACL; додаток очікує, що шлях існує.

Виправлення: Віддавайте перевагу усіченню/ротації, зберігайте структуру директорій, перезапустіть сервіси за потреби і встановіть явні політики ретеншну.

Чеклисти / покроковий план

Чеклист A: «Ми зараз маємо мало місця» (режим інциденту)

1. Визначити том (Завдання 1). Запишіть його в тікет.
2. Перевірити, чи падає місце (Завдання 2). Якщо так — поводьтеся як з активним писачем.
3. Отримати топ найновіших великих файлів (Завдання 5). Зафіксуйте топ‑30 і часові відмітки.
4. Знайти топ типів файлів (Завдання 6). Логи/дампи/temp — часті винуватці.
5. Оберіть найменш ризиковий варіант полегшення: старі логи, старі дампи, тимчасові файли старші за вікно.
6. Експортуйте докази (Завдання 12) перед видаленням чогось значного.
7. Виправте писача: зміна налаштувань, ротація, релокація шляху, ретеншн або виправлення багу.
8. Перевірте відновлення: вільне місце стабільне; сервіси здорові; моніторинг мовчить.

Чеклист B: «Ми регулярно втрачаємо місце щомісяця» (інженерний режим)

1. Базуйте використання диска щотижня за допомогою скриптів (топ‑дири, топ‑типи файлів).
2. Відокремте томи логів від системних де це можливо. Маленькі C: і гучні додатки не уживаються.
3. Визначте ретеншн для кожного типу логів (журнали безпеки відрізняються від debug‑логів).
4. Впровадьте обмеження: VSS, staging папки, spool‑директорії.
5. Зробіть власників видимими: зіставте топ‑шляхи з командами або додатками; опублікуйте просту таблицю відповідальності.
6. Автоматизуйте очищення тільки після доказовості безпечності з прев’ю і dry‑run.

Чеклист C: «Потрібно просканувати величезну файлову шару» (режим здорового глузду)

1. Запустіть скан на сервері файлів, якщо можливо (зменшує мережеве навантаження).
2. Починайте з верхнього рівня директорій; не рекурсируйте всюди відразу.
3. Виміряйте базову латентність перелічення директорій (Завдання 16). Якщо повільно — заплануйте на неробочий час.
4. Експортуйте результати в CSV і дозвольте власникам даних вирішувати, що видаляти.

FAQ

1) Чому не просто використовувати GUI‑інструмент типу WinDirStat або TreeSize?

На робочій станції — годиться. На сервері під час інциденту PowerShell кращий, бо він рідний, скриптовий, підлягає перегляду і легко запускається віддалено. Також: можна експортувати докази.

2) Чи безпечне сканування PowerShell на продакшн‑серверах?

Скани в режимі лише читання зазвичай безпечні, але вони можуть бути інтенсивними по I/O на зайнятих томах. Починайте цілеспрямовано (верхній рівень, недавні записи) і уникайте повних сканів мережевих шар у пікові години.

3) Який найшвидший спосіб знайти «що змінилося»?

Фільтруйте за LastWriteTime (Завдання 5) і сортуйте за розміром. Це показує, що недавно зросло, і зазвичай достатньо, щоб ідентифікувати писача.

4) Чи можна видаляти файли безпосередньо з PowerShell?

Можна, але робіть це лише після прев’ю й експорту. Видаляти легко; пояснити це потім важко. Використовуйте правила ретеншну (старші за X днів) і зберігайте запис дій.

5) Чому мій скан пропускає деякі файли?

Часто через дозволи та заблоковані директорії. Використовуйте -ErrorAction SilentlyContinue для інвентаризації, але якщо вам потрібна повнота — запускайте з відповідними правами і логуйте помилки.

6) Чому «розмір папки» не сходиться між інструментами?

Жорсткі посилання, reparse point, і відмінності інструментів у тому, що вони рахують. Також деякі інструменти рахують виділений розмір проти логічного. Для прийняття рішень зосереджуйтеся на «великих файлах за шляхом» і на «що росте».

7) Як впоратися з VSS, що займає місце на томі?

Спочатку підтвердіть, чи має цей том мати VSS (Завдання 9). Якщо ні — зменшіть максимум або перемістіть shadow storage, попередньо погодивши з власниками бекапів/відновлення.

8) Як сканувати мережеву шару, щоб не зробити всім життя нестерпним?

Запустіть скан на сервері файлів, обмежте глибину рекурсії спочатку і плануйте глибокі скани в неробочий час. Експортуйте результати і дайте власникам вирішити, що видаляти.

9) Який найбільший «не робіть цього» при очищенні Windows?

Не видаляйте випадково речі під C:\Windows (особливо Installer і WinSxS) бо якийсь блог сказав, що це «безпечно». Використовуйте підтримувані інструменти обслуговування і чистіть тільки дані додатків.

10) Як зробити це відтворюваним для моєї команди?

Перетворіть Завдання 1, 3/4, 5, 6 і 12 у невеликий скрипт, що записує CSV у відоме місце і прикріплюйте його до інструкцій інциденту. Відтворюваність — це головна мета.

Висновок: наступні кроки, які вас не переслідуватимуть

Програми очищення продають історію: використання диска — це таємниця і лише їхня магічна кнопка може це вирішити. Продакшн — навпаки. Використання диска піддається пізнанню. Це просто файли, часові позначки й власність. PowerShell перетворює «нам не вистачає місця» на список дій.

Зробіть це далі

1. Виберіть один хост, який регулярно заповнюється, і виконайте Завдання 1, 4, 6 і 12. Збережіть CSV.
2. Визначте топ‑3 винуватців (директорії або типи файлів) і призначте власників.
3. Впровадьте одну політику ретеншну (логи, дампи, temp) з прев’ю‑робочим процесом.
4. Повторіть ті самі команди наступного тижня і порівняйте. Якщо той самий винуватець повернувся — ви не виправили писача, а лише докази.
5. Запишіть це в runbook: «Коли мало місця: запускайте ці команди, експортуйте цей CSV, контактуйте цих власників.» Зробіть це навмисно нудним.

Якщо ви хочете систему, яка залишається чистою — перестаньте купувати «очищення». Почніть купувати «вимірювання». PowerShell — це вимірювальна шкала, яка у вас уже є.