Диск Mac забит снимками, а не файлами. Вот как это доказать

macOSTahoe ·
Диск Mac забит снимками, а не файлами. Вот как это доказать

Перед обновлением до macOS 27 найдите место, которое скрывает macOS: снимки APFS, освобождаемое (purgeable) содержимое, Preboot и своп. С командами и тем, что нельзя удалять ни в коем случае.

Вы удаляете 40 ГБ видео, очищаете корзину — а показатель свободного места почти не сдвигается. Или наоборот: Finder бодро сообщает о 300 ГБ свободного места, а установщик macOS 27 отказывается запускаться из-за нехватки места. Это одно и то же явление. В APFS «свободное место» — величина договорная, и разницу объясняют части диска, которые не видны через Finder: снимки (snapshots), освобождаемое (purgeable) содержимое и соседние тома, делящие один и тот же контейнер. Поскольку крупное обновление выходит 14 сентября, стоит научиться читать реальные цифры.

Основные выводы

  • df и Finder лгут намеренно. Число, важное для установщика, — это свободное место контейнера APFS, которое читается командой diskutil info /.
  • На системном томе есть снимок, который нельзя удалять никогда — это запечатанный подписанный системный том, с которого вы загрузились. Он отображается в diskutil, но не в tmutil, и именно в этом различии заключается вся диагностика.
  • Локальные снимки Time Machine — обычная причина, когда место исчезает. Они удаляются через 24 часа или когда места становится мало, но «мало» оказывается меньше, чем хотелось бы.
  • Освобождаемое (purgeable) место — это реальное место, которое macOS освободит под давлением — но крупное обновление может не создать нужное давление в нужный момент.
  • Другие тома в контейнере тоже учитываются. На этом Mac Preboot занимает 9 ГБ, а том VM — 18 ГБ свопа, и ни один из них нигде не отображается в Finder.

Четыре числа, один диск

Начните с того, чтобы увидеть расхождение, а не спорить с ним. На этом Mac, работающем под macOS 26.5.2 на SSD объёмом 1 ТБ:

$ df -h / /System/Volumes/Data
Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/disk3s1s1   926Gi    12Gi   395Gi     3%    /
/dev/disk3s5     926Gi   493Gi   395Gi    56%    /System/Volumes/Data

Два тома, каждый заявляет о размере 926 ГиБ, каждый сообщает об одинаковых 395 ГиБ доступного места. Ни один из них не ошибается, но ни один и не говорит всей правды: тома APFS делят один контейнер и растут внутрь него, поэтому «размер» — это размер контейнера, а «доступно» — свободное место контейнера, повторённое для каждого тома.

Теперь спросите напрямую сам контейнер:

$ diskutil apfs list disk3 | grep -E "Capacity|Volume Disk|Consumed"
    Size (Capacity Ceiling):      994662584320 B (994.7 GB)
    Capacity In Use By Volumes:   570712170496 B (570.7 GB) (57.4% used)
    Capacity Not Allocated:       423950413824 B (424.0 GB) (42.6% free)
    |   APFS Volume Disk (Role):   disk3s1 (System)
    |   Capacity Consumed:         12568809472 B (12.6 GB)
    |   APFS Volume Disk (Role):   disk3s2 (Preboot)
    |   Capacity Consumed:         8995532800 B (9.0 GB)
    |   APFS Volume Disk (Role):   disk3s3 (Recovery)
    |   Capacity Consumed:         1304084480 B (1.3 GB)
    |   APFS Volume Disk (Role):   disk3s5 (Data)
    |   Capacity Consumed:         529380937728 B (529.4 GB)
        APFS Volume Disk (Role):   disk3s6 (VM)
        Capacity Consumed:         18253713408 B (18.3 GB)

Вот честный подсчёт. Пять томов, и только один из них — Data, на 529 ГБ — можно просматривать в Finder. Preboot занимает 9 ГБ. Том VM — 18 ГБ. Вместе они занимают больше места, чем папка «Документы» у большинства людей, и ни один интерфейс управления хранилищем на Mac их вам не покажет.

Единственное число, которое важно для установщика:

$ diskutil info / | grep "Container Free Space"
   Container Free Space:      423.9 GB (423947014144 Bytes)

Ориентируйтесь именно на него. Если оно расходится с показаниями Finder на десятки гигабайт, всё, что написано ниже, объясняет, куда делась разница.

Снимок, который нельзя удалять никогда

Запустите очевидную команду — и результат выглядит тревожно:

$ diskutil apfs listSnapshots /
Snapshot for disk3s1s1 (1 found)
|
+-- B8B12570-09B5-402F-99BB-F383487AD69D
    Name:        com.apple.os.update-5B92CE4BA1034457A0921532291F4A4AD939CBE...
    XID:         17495484
    Purgeable:   No
    NOTE:        This snapshot limits the minimum size of APFS Container disk3

Снимок, помечен как не подлежащий освобождению (Purgeable: No), в явном виде описан как ограничивающий минимальный размер контейнера. Возникает соблазн решить, что именно он и съедает ваш диск.

Это не так. Это операционная система, под которой вы сейчас работаете.

Начиная с macOS 11 системный том запечатан и криптографически проверяется, и Mac загружает не сам том, а его снимок. diskutil apfs list говорит об этом прямо:

|   APFS Volume Disk (Role):   disk3s1 (System)
|   Snapshot:                  B8B12570-09B5-402F-99BB-F383487AD69D
|   Snapshot Disk:             disk3s1s1
|   Snapshot Mount Point:      /
|   Snapshot Sealed:           Yes

Snapshot Sealed: Yes, смонтирован в /. Префикс com.apple.os.update- — это соглашение об именовании снимка, создаваемого при применении обновления ОС. Удалить его — не значит навести порядок, это значит удалить работающую систему. macOS, как правило, откажется это делать, но слово «как правило» — не то, что хочется видеть между собой и незагружающимся Mac.

Признак, который отличает его от снимка, который можно удалить:

$ tmutil listlocalsnapshots /
Snapshots for disk /:

$ tmutil listlocalsnapshots /System/Volumes/Data
Snapshots for disk /System/Volumes/Data:

Оба списка пусты. tmutil показывает только снимки Time Machine — те, что создаются для резервных копий, и которые безопасно прореживать. diskutil показывает вообще все снимки APFS, включая запечатанный системный. Если снимок виден в diskutil, но не виден в tmutil — удалять его не вам.

Практическое правило: действуйте на основании того, что показывает tmutil. diskutil читайте, чтобы понять, а не чтобы принимать решение.

Снимки, которые на самом деле съедают ваш диск

Time Machine создаёт локальные снимки прямо на самом Mac, а не только на диске для резервных копий, и именно они обычно оказываются ответом на вопрос «куда делись 80 ГБ?».

Механизм прост, а вот последствия — нет. Снимок сохраняет состояние тома на определённый момент. Если после этого изменить файл, исходные блоки приходится хранить вместе с новыми. Удалите видео на 20 ГБ, существовавшее на момент создания снимка, — место не освободится, потому что снимок по-прежнему на него ссылается. Исключение — файлы, которые были и созданы, и удалены между двумя снимками: они действительно исчезают безвозвратно.

Автоматическая уборка Apple работает по двум критериям — возрасту и давлению: снимки старше 24 часов удаляются, а более старые вычищаются, когда свободного места становится критически мало. Между этими двумя правилами Mac с активным расписанием Time Machine и напряжённым днём, полным изменений файлов, может удерживать десятки гигабайт, которые не освободятся, пока не сработает либо таймер, либо порог давления.

На этом Mac не настроено ни одного места назначения для Time Machine:

$ tmutil destinationinfo
tmutil: No destinations configured.

— именно поэтому список снимков пуст, и именно поэтому его том Data показывает No snapshots for disk3s5. Если у вас Time Machine настроена (а она должна быть настроена — см. актуальное руководство по стратегии резервного копирования), ожидайте увидеть там несколько снимков.

Как увидеть их в Дисковой утилите

Если не хочется работать в Терминале: откройте Дисковую утилиту, затем Вид → Показать все устройства, выберите том Data и включите Вид → Показать снимки APFS. Вы получите список с размерами и контекстное меню для удаления отдельных снимков. Стоит повторить совет Говарда Оукли (Howard Oakley) — оставляйте самый последний снимок, потому что удаление всех сразу может заставить Time Machine при следующем запуске выполнить полное резервное копирование.

Дисковая утилита со списком снимков APFS для тома данных Mac

Целенаправленное прореживание

Официально поддерживаемый способ освободить место, занятое снимками, — команда thinlocalsnapshots, которая принимает точку монтирования, количество байт, которое нужно попытаться освободить, и уровень срочности от 1 до 4:

# Ask macOS to free roughly 20 GB from Data volume snapshots, highest urgency
sudo tmutil thinlocalsnapshots /System/Volumes/Data 20000000000 4

Уровень срочности 4 — самый агрессивный: при необходимости он удалит все снимки, кроме самого последнего. Именно так macOS поступает сама с собой под давлением нехватки места; запуск вручную — это просто выполнение того же самого заранее.

Чтобы удалить конкретный снимок, а не прореживать весь том:

# List them first
tmutil listlocalsnapshots /System/Volumes/Data

# Delete one by its date stamp
sudo tmutil deletelocalsnapshots 2026-09-10-140233

А вот низкоуровневый эквивалент, который работает с любым снимком APFS по UUID, XID или имени:

diskutil apfs deleteSnapshot disk3s5 -uuid <snapshot-UUID>

Используйте tmutil, где это возможно. diskutil apfs deleteSnapshot без колебаний согласится указать не на тот том, а «не тот том» здесь — это тот, с которого вы загрузились.

Что на самом деле означает «purgeable»

macOS помечает часть места как purgeable (освобождаемое): это содержимое, которое система готова удалить автоматически при заполнении диска. Сюда входят снимки, вышедшие за пределы срока хранения, кэшированные файлы iCloud, которые уже есть в облаке, оригиналы Photos, уже загруженные в облако, скачанные медиафайлы и различные кэши.

Purgeable-место действительно можно вернуть — но освобождение происходит реактивно. macOS высвобождает его, когда что-то требует места, причём это требование должно прийти в форме, которую macOS распознаёт. Крупная операция cp его запустит; а установщик, который заранее проверяет свободное место и отказывается работать ещё до записи чего-либо, может его не запустить.

Это как раз тот сценарий сбоя, что случается в день обновления: сотни гигабайт помечены как purgeable, установщик не запускается, и нет очевидного способа убедить систему начать действовать. Грубый, но безопасный способ форсировать это — создать реальное давление на диск:

# Write a large file to force macOS to reclaim purgeable space, then delete it
mkfile -n 30g ~/Desktop/ballast
rm ~/Desktop/ballast

mkfile -n создаёт разреженный (sparse) файл, поэтому сама запись выполняется быстро; освобождение места запускает именно выделение блоков. Удалите файл, как только показатель свободного места сдвинется.

Тома, о которых никто не вспоминает

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

Preboot — 9,0 ГБ на этом Mac. Он хранит загрузочные ресурсы для каждой установки ОС, которая когда-либо была в этом контейнере, включая среды восстановления и криптографические материалы для каждого тома. Он растёт с каждым крупным обновлением и не вычищается автоматически. Это также не то, что стоит чистить вручную: удаление не того файла там приводит к тому, что Mac не запустится. Считайте это фиксированной платой за уже выполненные обновления.

VM — 18,3 ГБ на этом Mac. Это своп. Можно точно увидеть, что там находится:

$ ls -lh /System/Volumes/VM/
-rw-------  1 root  wheel   1.0G ... swapfile0
-rw-------  1 root  wheel   1.0G ... swapfile1
-rw-------  1 root  wheel   1.0G ... swapfile10
...

$ sysctl vm.swapusage
vm.swapusage: total = 17408.00M  used = 16258.81M  free = 1149.19M  (encrypted)

Семнадцать своп-файлов по одному гигабайту, 16 ГБ из них используется. macOS увеличивает своп по мере необходимости и не спешит его уменьшать; перезагрузка — надёжный способ вернуть это место. Если места перед обновлением не хватает, перезагрузка Mac — не суеверие: она реально возвращает несколько гигабайт на машине, которая работала без перезагрузки неделями.

Сколько места нужно для macOS 27?

Заявленный Apple минимум для крупных обновлений исторически составлял 25–45 ГБ в зависимости от исходной версии, а сам полный установщик занимает около 17 ГБ — у Tahoe это 17 953 734 КиБ согласно каталогу установщика, и Golden Gate будет примерно того же порядка.

Практическое число выше заявленного. Планируйте иметь 60 ГБ свободного места в контейнере перед началом крупного обновления — по трём причинам: загрузка установщика, рабочее пространство, нужное самой установке, и снимок, который macOS делает с вашей системы перед обновлением и который нельзя проредить в процессе.

Проверяйте это, а не оценивайте на глаз:

diskutil info / | grep "Container Free Space"

Ещё одно оптимистичное число: iCloud и Photos

Две функции намеренно показывают место так, чтобы диск выглядел лучше, чем есть.

Функция iCloud Drive «Оптимизировать хранилище Mac» выгружает содержимое файлов, которые вы давно не использовали, оставляя заглушку, которая загружается по требованию. Finder показывает файл в полном размере, а диск при этом хранит почти ничего. Это отличное поведение — пока установщик не спросит, сколько места доступно, потому что выгруженное содержимое считается purgeable, а не свободным.

Функция «Оптимизировать хранилище Mac» в Photos делает то же самое с оригиналами, оставляя локально только уменьшенные версии. Библиотека на 200 ГБ может занимать на диске всего 30 ГБ и может незаметно массово скачаться обратно, если открыть не тот раздел не в тот момент.

Ни то, ни другое не является проблемой, которую нужно исправлять. Однако именно из-за них Mac может перейти от состояния «места полно» к «диск заполнен», хотя вы ничего не делали, и именно поэтому показатель свободного места, измеренный на прошлой неделе, сегодня уже ничего не стоит. Измеряйте место непосредственно перед обновлением, а не накануне вечером.

Аудит места перед обновлением за пять команд

Выполните их по порядку — и меньше чем за минуту вы будете точно знать, как обстоят дела:

# 1. The number that matters
diskutil info / | grep "Container Free Space"

# 2. Every volume in the container, with what it is consuming
diskutil apfs list $(diskutil info / | awk '/Part of Whole/ {print $4}') | grep -E "Capacity|Volume Disk"

# 3. Snapshots that are actually yours to remove
tmutil listlocalsnapshots /System/Volumes/Data

# 4. Swap, which a restart returns
sysctl vm.swapusage

# 5. The largest directories in your home folder
du -sh ~/* 2>/dev/null | sort -rh | head -10

Если шаг 1 показал больше 60 ГБ — остановитесь, вы готовы. Если нет, шаги со 2 по 5 подскажут, за какой из четырёх источников браться, примерно в том порядке, который возвращает место при наименьшем риске.

Освобождение места в порядке безопасности

  1. Перезагрузка. Освобождает своп, очищает кэши, удаляет часть снимков. Стоит две минуты и часто возвращает 10–20 ГБ.
  2. Прореживание снимков Time Machine. sudo tmutil thinlocalsnapshots /System/Volumes/Data 20000000000 4. Безопасно, официально поддерживается, обратимо в том смысле, что следующая резервная копия воссоздаст всё важное.
  3. Очистите корзину, в том числе в Photos и Mail, где удалённые элементы 30 дней лежат во внутренней корзине приложения.
  4. Принудительное освобождение purgeable-места с помощью описанного выше трюка с файлом-балластом, если цифры всё ещё не сходятся.
  5. Кэши разработчика, если применимо. На этом Mac /System/Library/AssetsV2 занимает в сумме 25 ГБ — из них 16 ГБ приходится на среды выполнения iOS Simulator. Derived data, device support и архивы Xcode на рабочей машине разработчика регулярно добавляют 50+ ГБ. Панель Settings → Components в самом Xcode корректно удаляет среды выполнения симулятора.
  6. Крупные файлы, которые действительно принадлежат вам. Инструменты анализа хранилища находят их быстрее, чем ручной просмотр. А если диск заполнен, но видимых причин этому нет, стоит заглянуть ещё в скрытые логи в корне диска.
  7. Перенос на внешний накопитель. Медленный, но правильный ответ на случай, когда диск просто слишком маленький.

Чего делать не стоит

  • Не удаляйте снимок com.apple.os.update- на системном томе. Это работающая ОС.
  • Не выполняйте rm -rf ни для чего внутри /System/Volumes/. Preboot, VM и Recovery — несущие элементы системы.
  • Не отключайте локальные снимки Time Machine, чтобы «сэкономить место». Вы теряете возможность откатить неудачное обновление — а это именно та страховка, которая нужна во время недели обновления.
  • Не устанавливайте для этого приложение-чистильщик. Каждая операция выше — это встроенная команда. Стороннее приложение с доступом Full Disk Access, обещающее освободить место, удаляя системные файлы, — риск худший, чем заполненный диск.
  • Не удаляйте своп-файлы вручную. macOS пересоздаёт их, а удаление файла, который используется, приводит к сбою.

Вывод Терминала со сравнением свободного места контейнера до и после освобождения места от снимков

Решение распространённых проблем

tmutil thinlocalsnapshots сообщает об успехе, но место не освобождается

Удалённые снимки ссылались на блоки, на которые ссылаются и другие снимки. Удаление одного из нескольких пересекающихся снимков ничего не освобождает; удаление последнего освобождает всё сразу. Запустите команду повторно с уровнем срочности 4 или удалите оставшиеся снимки по одному.

Дисковая утилита не показывает снимков, а место всё равно пропало

Значит, дело не в снимках. Проверьте разбивку по томам контейнера — Preboot и VM обычно и оказываются сюрпризом — и проверьте purgeable-место. Mac с большой библиотекой iCloud Photos также хранит оптимизированные оригиналы, показатели которых выглядят странно.

Установщик говорит, что места не хватает, а diskutil говорит, что его много

Убедитесь, что вы смотрите показатели контейнера, а не тома, и что речь идёт о внутреннем диске, а не о внешнем. Если оба источника согласны, что место есть, сбой обычно вызван чем-то другим, что маскируется под ошибку нехватки места, — чаще всего это сторонний kext, не прошедший авторизацию. Руководство по обновлению в день релиза описывает проверку kext.

Место продолжает исчезать за ночь

Сработала Time Machine. Это система работает так, как должна. Если объём изменений действительно неоправданно велик, ищите причину в том, что именно пишет на диск — клиент синхронизации, перезаписывающий крупные файлы, образ диска виртуальной машины или база данных, — а не в самой Time Machine.

Mac не загружается после удаления снимка

Загрузитесь в Recovery и используйте восстановление системы через Time Machine, чтобы откатиться к более раннему снимку, если он остался; в противном случае переустановите macOS поверх текущей системы — это сохранит том Data. Именно этот сценарий и призвано предотвратить правило «никогда не удаляйте запечатанный снимок».

Часто задаваемые вопросы

Являются ли снимки APFS резервной копией?

Нет. Снимок находится на том же диске, что и данные, на которые он ссылается. Если SSD выйдет из строя, снимки выйдут из строя вместе с ним. Они защищают от ошибок и неудачных обновлений, а не от отказа оборудования. Настоящая резервная копия находится в другом месте — см. руководство по стратегии резервного копирования.

Стоит ли удалять снимки перед обновлением до macOS 27?

Лучше проредить их, а не удалять все, и оставить самый последний. Само обновление создаст свежий снимок вашей системы в состоянии до обновления — именно он понадобится, если что-то пойдёт не так.

Почему Finder показывает другое число свободного места?

Finder показывает доступное место тома, включая purgeable-содержимое, — это оптимистичная оценка. diskutil info / показывает реальное свободное место контейнера. Когда речь идёт об установщике, доверяйте второму числу.

Можно ли запретить macOS создавать локальные снимки?

Можно полностью отключить Time Machine — это остановит создание снимков, но это плохой обмен. 24-часовой срок хранения плюс автоматическое прореживание по давлению означают, что на исправном Mac снимки саморегулируются.

Нормально ли, что Preboot занимает 9 ГБ?

Это на верхней границе нормы, но не повод для беспокойства для Mac, прошедшего через несколько крупных обновлений. Он растёт с каждой установкой ОС, которая была в этом контейнере. Официального способа его почистить не существует, и пытаться не стоит.

Действительно ли перезагрузка освобождает место?

Да, и вполне ощутимо. Основной вклад вносит своп — 18 ГБ на этом Mac, — а также кэши и просроченные снимки. Это первое, что стоит попробовать, и единственный способ, который ничего не стоит.

Заключение

Показатель свободного места в Finder — это сводка, написанная для успокоения; а показатель контейнера — это то, что решает, запустится ли обновление в понедельник. Разница между ними — это снимки, которые можно проредить, purgeable-содержимое, которое macOS освободит под давлением, и два невидимых тома, которые представляют собой просто плату за работу современного Mac.

Если запомнить из всей этой статьи только одну команду, пусть это будет diskutil info / | grep "Container Free Space". Всё остальное здесь — лишь объяснение того, почему это число отличается от ожидаемого, но именно оно окажется верным.

Похожие материалы: Руководство по обновлению macOS 27 Golden Gate в день релиза · Почему macOS 27 не появляется в Обновлении ПО · Скрытые логи в корне диска, заполняющие ваш накопитель · Решение проблем с Time Machine