Вы открываете свойства папки с документами — там 500 ГБ. Открываете другую папку, куда вы скопировали те же самые файлы «для резервной копии» — ещё 500 ГБ. Логика подсказывает: на диске должно быть занято 1 ТБ. Но система показывает, что свободно осталось… намного меньше, чем вы ожидали. Или, наоборот, вы удалили 40 ГБ файлов, а свободное место не увеличилось ни на байт.
Что происходит? Windows не всегда честна с вами насчёт того, сколько места на самом деле занимают файлы. Существуют механизмы, которые создают иллюзию дублирования, скрывают реальное потребление и даже «прячут» освободившееся пространство до тех пор, пока вы не попросите систему его вернуть.
В этом материале разберём три главных способа, которыми Windows управляет дубликатами файлов — часто без вашего ведома. Вы узнаете, что такое жёсткие ссылки (hard links), почему они не занимают места, но выглядят как полноценные копии. Поймёте, как работает дедупликация данных (Data Deduplication) — функция, которая может сэкономить терабайты, но при этом скрывает от вас истинный объём хранимой информации. И наконец, разберёмся с копированием при записи (Copy-on-Write) — технологией, которая делает разработчиков счастливее, а подсчёт занятого места — запутаннее.
🔥 Хотите понимать, как на самом деле работают ваши файлы и куда девается место на диске? Подписывайтесь на наш канал в мессенджере МАХ: https://max.ru/bugfeature и телеграм-канал: https://t.me/+mahA5qMKb5lhMzZi. Здесь мы публикуем эксклюзивные разборы о скрытых механизмах Windows, оптимизации хранилищ и фичах, о которых молчат официальные инструкции. «Не баг, а фича» — ваш проводник в мир, где технологии раскрываются на 100%.
📌 Часть 1. Иллюзия дублирования: почему два файла могут занимать место одного
Начнём с самого распространённого сценария, который вводит в заблуждение даже опытных пользователей. Вы копируете файл в другую папку. В проводнике появляются два файла с одинаковым содержимым. Вы смотрите на свойства каждого — размер одинаковый. Логично предположить, что они занимают в два раза больше места, чем один файл.
Но это не всегда так.
В файловой системе NTFS существует механизм жёстких ссылок (hard links). Это не то же самое, что обычное копирование. Когда создаётся жёсткая ссылка, система не дублирует данные. Вместо этого она создаёт второе имя для одних и тех же данных на диске .
Как это работает технически:
На диске каждый файл представлен структурой, которая называется MFT-запись (Master File Table). В ней хранятся атрибуты файла (имя, дата создания, права доступа) и ссылки на кластеры, где лежат реальные данные. Жёсткая ссылка — это вторая MFT-запись, которая указывает на те же самые кластеры .
Для пользователя это выглядит как два независимых файла. Их можно редактировать, перемещать, удалять. Но есть нюансы:
- Изменение одного файла меняет другой. Поскольку оба имени указывают на одни и те же данные, если вы откроете файл через любую ссылку и измените содержимое, изменения увидят обе ссылки .
- Удаление одного файла не освобождает место. Система хранит счётчик ссылок. Когда вы удаляете файл, счётчик уменьшается на единицу. Данные физически стираются только тогда, когда счётчик достигает нуля — то есть когда удалены все жёсткие ссылки на эти данные .
- Жёсткие ссылки не занимают дополнительного места. Размер на диске (Size on disk) для жёсткой ссылки будет указан как полный объём файла, но физически он не добавляет новых байтов .
Где это встречается в реальной жизни:
- Система Windows активно использует жёсткие ссылки в папке C:\Windows\WinSxS. Это хранилище компонентов, где одна и та же версия DLL-библиотеки может быть «прилинкована» к разным приложениям через жёсткие ссылки. Снаружи кажется, что каждая программа занимает свою копию DLL, но физически библиотека хранится в единственном экземпляре.
- Программы резервного копирования иногда используют жёсткие ссылки для создания «инкрементальных» снимков без дублирования неизменённых файлов.
- Git на некоторых конфигурациях использует жёсткие ссылки для оптимизации хранения объектов.
Почему это скрыто от вас: Проводник Windows не делает различий между обычным файлом и жёсткой ссылкой. В свойствах файла вы не увидите счётчика ссылок. Единственный способ обнаружить, что перед вами жёсткая ссылка, — использовать командную строку fsutil hardlink list "путь_к_файлу" или специализированные утилиты вроде Link Shell Extension.
🧩 Часть 2. Дедупликация данных: когда Windows прячет терабайты в «одном» файле
Теперь переходим к механизму, который может скрывать от вас десятки гигабайт (или даже терабайты) занятого места. Речь о Data Deduplication — технологии, которая изначально появилась в Windows Server 2012, но постепенно проникает и в клиентские версии Windows .
Как это работает
Представьте, что у вас есть тысяча виртуальных машин, на каждой из которых стоит одна и та же версия Windows. Без дедупликации системные файлы занимали бы место тысячи раз. С дедупликацией — один раз.
Принцип работы: Система разбивает файлы на небольшие блоки (обычно 32–128 КБ) и вычисляет для каждого блока хеш-сумму. Если два разных файла содержат одинаковые блоки, эти блоки физически хранятся только один раз. Каждый файл становится «сборником» ссылок на эти общие блоки плюс уникальные фрагменты.
Что происходит с файлом после дедупликации:
Когда вы смотрите на свойства файла, вы видите его логический размер — тот, который был до оптимизации. Но реальный размер на диске может быть в сотни раз меньше .
Вот реальный пример, описанный администратором файлового сервера: на диске объёмом 1,9 ТБ хранилось почти 3,5 ТБ данных за счёт дедупликации. Экономия составила более 45% . При этом в свойствах папки система показывала логический объём, а свободное место рассчитывалось исходя из физического.
Куда «исчезают» данные
Самое интересное — и самое запутывающее — происходит, когда вы удаляете файл на дедуплицированном томе.
Важный момент: если вы просто удаляете файл через проводник, свободное место не увеличивается . Почему? Потому что файл, который вы видите, — это всего лишь «обёртка» из метаданных. Его реальные данные (те самые блоки) хранятся отдельно, в скрытой системной папке System Volume Information\Dedup .
Когда вы удаляете файл, система:
- Удаляет метаданные (саму «обёртку»).
- Уменьшает счётчик ссылок на те блоки данных, которые были уникальны для этого файла.
- Не трогает сами блоки данных, на которые есть другие ссылки.
И только после запуска специального процесса Garbage Collection (сборки мусора) система физически удаляет блоки, на которые больше нет ссылок, и освобождает место .
Как увидеть реальную картину:
В Windows Server для управления дедупликацией используются PowerShell-командлеты:
powershell
# Показать статус дедупликации на томе
Get-DedupStatus
# Узнать, сколько места можно освободить
Measure-DedupFileMetadata -Path "путь_к_файлу"
# Принудительно запустить сборку мусора
Start-DedupJob E: –Type GarbageCollection -full
В клиентских версиях Windows (10/11) дедупликация по умолчанию не включена, но её можно активировать через компоненты системы или использовать сторонние аналоги.
⚡ Часть 3. Copy-on-Write (копирование при записи): когда копии не занимают места
Третий механизм, который заставляет вас ошибаться в подсчёте занятого места, — Copy-on-Write (CoW) или блочное клонирование (block cloning) .
Что это такое
CoW — это технология, которая позволяет создать копию файла без физического копирования данных. Вместо этого создаётся метаданная ссылка на исходные данные. Файл-клон занимает на диске лишь несколько килобайт — до тех пор, пока вы не начнёте его изменять .
Сравнение с жёсткими ссылками:
- Жёсткая ссылка: оба имени указывают на одни и те же данные. Изменение через любое имя меняет данные для всех.
- CoW-клон: при изменении клона система копирует только изменяемый блок в новое место, остальные блоки остаются общими. Клон становится независимым в момент первой записи .
Где это поддерживается
CoW доступна не на всех файловых системах:
Для Windows CoW становится доступной при использовании ReFS (Resilient File System) или специальных Dev Drive томов, которые появились в Windows 11 23H2 .
Почему это важно для обычного пользователя
CoW активно используется в сценариях разработки и виртуализации, но постепенно проникает и в повседневное использование.
Пример: Вы создаёте образ виртуальной машины размером 50 ГБ. Без CoW каждый клон этого образа занимал бы ещё 50 ГБ. С CoW вы можете создать 10 клонов, и они займут всего 50 ГБ + небольшие изменения .
Microsoft сообщает о впечатляющих результатах: при использовании Dev Drive с CoW время сборки проектов сокращается на 28% по сравнению с обычным NTFS, а дисковое пространство экономится за счёт того, что пакеты зависимостей (NuGet, npm, pip) не дублируются в каждой папке сборки .
Как настроить: Для использования CoW в Windows 11 нужно создать том Dev Drive (через Параметры → Система → Хранилище → Дополнительные параметры хранилища → Диски и тома → Создать Dev Drive) и переместить на него кэши пакетов, установив переменные окружения:
- NUGET_PACKAGES — для NuGet
- npm_config_cache — для npm
- PIP_CACHE_DIR — для pip
🔍 Часть 4. Как Windows скрывает истинный размер: практические примеры
Теперь, когда мы разобрали три механизма, давайте посмотрим, как они превращаются в «скрытые» терабайты на реальных системах.
Сценарий 1. Файловый сервер с дедупликацией
Администратор настраивает сервер для хранения пользовательских документов. На диске 2 ТБ. Пользователи загружают файлы, многие из которых дублируются (один и тот же шаблон договора, одинаковые фотографии, повторяющиеся вложения в письмах). Включается дедупликация.
Что видит администратор:
- В свойствах диска: «Занято 1,8 ТБ из 2 ТБ».
- В оснастке дедупликации: «Логический объём данных — 3,5 ТБ, физический — 1,8 ТБ».
Что скрыто:
Если администратор просто посмотрит на папки через проводник, он увидит 3,5 ТБ «логических» данных. Но место на диске занято только 1,8 ТБ. Удаление файлов без запуска Garbage Collection не освободит место .
Сценарий 2. Разработчик с Dev Drive
Разработчик работает над проектом на C#. У него установлено 20 пакетов NuGet, каждый весит по 10–50 МБ. При сборке проекта MSBuild копирует эти пакеты в папку bin\debug. Без CoW каждая сборка создавала бы новые копии, и к концу дня папка проекта «раздувалась» до десятков гигабайт.
Что видит разработчик:
- Папка bin\debug показывает логический размер 500 МБ.
- На самом деле физически занято всего 50 МБ — остальное — CoW-ссылки на кэш NuGet .
Что скрыто:
Если разработчик просто удалит папку bin\debug, место не освободится немедленно — нужно дождаться, пока система очистит неиспользуемые CoW-блоки.
Сценарий 3. Системная папка WinSxS
Папка C:\Windows\WinSxS — это классический пример использования жёстких ссылок. В ней хранятся все версии компонентов Windows.
Что видит пользователь:
- В свойствах папки WinSxS — 15–25 ГБ.
- В свойствах системных файлов (System32, SysWOW64) — ещё десятки гигабайт.
Что скрыто:
Большинство файлов в System32 — это жёсткие ссылки на файлы в WinSxS. Физически данные хранятся только в WinSxS, а в System32 лежат ссылки на них . Если сложить логические размеры всех системных папок, получится 50+ ГБ, но физически занято 20–25 ГБ.
🛠️ Часть 5. Как увидеть правду: инструменты для анализа реального размера
Стандартный проводник Windows не показывает разницу между логическим и физическим размером файлов. Для детального анализа нужны специализированные инструменты.
1. TreeSize Free
Программа умеет отображать как логический, так и физический размер файлов. При работе с дедуплицированными томами или ReFS она покажет реальное потребление.
Как использовать: Запустите TreeSize от имени администратора, выберите диск, затем в меню «Вид» выберите «Размер на диске» вместо «Размер». Это покажет, сколько места физически занимают файлы с учётом жёстких ссылок и дедупликации.
Ссылка: https://www.jam-software.com/treesize_free
2. WizTree
Одна из самых быстрых утилит для анализа диска. Считывает MFT напрямую, что позволяет за секунды просканировать терабайтные диски.
Показывает количество жёстких ссылок на файл и может подсвечивать дубликаты.
Ссылка: https://wiztreefree.com/
3. PowerShell — командлеты для профессионалов
Для точной диагностики лучше всего подходят встроенные средства Windows:
powershell
# Получить информацию о файле с количеством жёстких ссылок
Get-Item "путь_к_файлу" | Select-Object FullName, LinkType, Target
# Для дедуплицированных томов (требуется права администратора)
Get-DedupStatus -Volume "E:"
# Получить детали по конкретному файлу на дедуплицированном томе
Measure-DedupFileMetadata -Path "путь_к_файлу"
📋 Часть 6. Что делать, если место «пропало» или не освобождается
Если вы столкнулись с ситуацией, когда удалённые файлы не освобождают место или диск показывает «непонятные» терабайты, следуйте этому алгоритму.
Шаг 1. Определите, включена ли дедупликация
Запустите PowerShell от имени администратора и выполните:
powershell:
Get-DedupStatus
Если команда вернула информацию о томе — дедупликация активна.
Шаг 2. Запустите сборку мусора
Для дедуплицированных томов:
powershell:
Start-DedupJob E: -Type GarbageCollection -full
Это займёт от нескольких минут до часов в зависимости от объёма данных .
Шаг 3. Проверьте, не мешают ли точки восстановления
Иногда место «съедают» теневые копии (System Protection) или история файлов.
powershell
# Посмотреть использование теневых копий
vssadmin list shadowstorage
Шаг 4. Используйте очистку диска с системными файлами
Запустите «Очистку диска» (cleanmgr), нажмите «Очистить системные файлы», отметьте все пункты. Это удалит старые обновления Windows и другие временные данные, которые могли остаться после дедупликации.
🔥 Итог: Windows не обманывает, она оптимизирует
То, что выглядит как «скрытые дубликаты» или «пропавшее место», на самом деле — сложные механизмы оптимизации хранения, которые Microsoft встраивает в свои файловые системы. Жёсткие ссылки, дедупликация и Copy-on-Write позволяют хранить терабайты данных на дисках вдвое меньшего объёма, но ценой прозрачности для пользователя.
Теперь, когда вы знаете о существовании этих механизмов, вы сможете:
- Не пугаться, когда после удаления файлов место не освобождается сразу.
- Целенаправленно запускать сборку мусора на дедуплицированных томах.
- Использовать Dev Drive и CoW для экономии места при разработке.
- Пользоваться правильными инструментами для анализа реального размера папок.
🔥 Хотите получать такие разборы регулярно? Подписывайтесь на наш канал в мессенджере МАХ: https://max.ru/bugfeature и телеграм-канал: https://t.me/+mahA5qMKb5lhMzZi. Здесь мы публикуем материалы о скрытых возможностях Windows, оптимизации дисков и фичах, которые экономят вам терабайты и часы работы. «Не баг, а фича» — ваш гид по миру IT.