Time Machine не работает? 12 решений для самых частых ошибок бэкапа

Time Machine находится на неудобном пересечении подсистем. Чтобы завершить один бэкап, ему нужно скоординировать файловую систему, демон событий файловой системы, сетевые монтирования, SMB или AFP, оболочку sparsebundle, слои шифрования, снапшоты и предположение самого пользователя, что ничто из этого не упадёт одновременно. Когда что-то падает, поверхностная ошибка — обычно общее «произошла ошибка» без полезного контекста, а настоящая причина — одна из примерно двенадцати конкретных вещей.

Это руководство — выверенный практикой список этих двенадцати вещей. Каждое решение следует одной форме: как выглядит симптом, что на самом деле происходит под капотом и какие именно шаги вернут вас к работающему бэкапу.

Сначала: прочитайте логи

Прежде чем что-либо менять, посмотрите, что Time Machine на самом деле говорит сам себе. Откройте Терминал и запустите:

log show --predicate 'subsystem == "com.apple.TimeMachine"' --info --last 1h

Это выдаст последний час активности Time Machine. Прокрутите и поищите слова error, fail, denied или copying. Фактическая первопричина почти всегда написана где-то там, даже когда диалоговое окно для пользователя не говорило ничего полезного.

Для более быстрой сортировки:

tmutil status
tmutil latestbackup

Первая команда печатает живое состояние движка бэкапа. Вторая показывает, когда был завершён последний успешный снапшот. Если latestbackup отстаёт на дни или недели — уведомления «Time Machine завершил бэкап» вас обманывают.

Решение 1: бэкап идёт вечно

Симптом: Полоса прогресса ползёт часами, но никогда не доходит до конца. Оставшееся время продолжает расти.

Диагностика: Две частые причины. Либо это действительно первый бэкап большого объёма данных (тогда он реально медленный), либо fseventsd сошёл с ума и Time Machine делает полное сканирование вместо инкрементального.

Решение:

1. Если это первый бэкап вообще, просто дайте ему закончиться. Начальный бэкап 1 ТБ по USB 3 занимает 6–12 часов; тот же бэкап по Wi-Fi может занять дни. Если у вас облачное место назначения — подключите Ethernet.
2. Если это не первый бэкап, подозревайте fseventsd. Запустите sudo rm -rf /.fseventsd на исходном томе, затем перезагрузите. Следующий бэкап будет медленным из-за пересборки базы событий, но последующие вернутся к нормальной скорости.
3. Проверьте Мониторинг системы на backupd и backupd-helper. Если CPU высокий, а I/O диска низкий — узкое место в сканировании метаданных, а не в передаче данных. Снова главный подозреваемый — fseventsd.

Решение 2: застряло на «Подготовка резервной копии...»

Симптом: Статус «Подготовка резервной копии...» часами и без продвижения.

Диагностика: На фазе «подготовки» Time Machine делает снапшот исходного тома и обходит лог изменений, чтобы определить, что бэкапить. Если лог изменений повреждён или sparsebundle на месте назначения имеет устаревшие метаданные, эта фаза может зависнуть навсегда.

Решение:

1. Откройте значок Time Machine в строке меню, нажмите «Пропустить резервное копирование». Это убьёт зависшую задачу.
2. Подождите 30 секунд, затем запустите «Создать резервную копию сейчас» из того же меню.
3. Если новый запуск тоже зависает, отключите и снова смонтируйте диск назначения.
4. Если зависание остаётся, запустите эквивалент fsck на исходном томе из Дисковой утилиты (Первая помощь).
5. Крайняя мера: пересоберите базу fseventsd через sudo rm -rf /.fseventsd, перезагрузите и попробуйте снова.

Решение 3: диск бэкапа заполнен, sparsebundle растёт

Симптом: Time Machine сообщает, что диск бэкапа заполнен, хотя вы установили щедрый лимит размера.

Диагностика: Sparsebundle не сжимаются автоматически при удалении снапшотов. Когда Time Machine прореживает старые снапшоты, освобождённое место отображается внутри sparsebundle, но сам файл sparsebundle остаётся того размера, до которого вырос. На месте назначения, разделяемом с другими данными, файловая система хоста закончится раньше, чем Time Machine это заметит.

Решение:

1. Сожмите sparsebundle. Сначала отключите от Time Machine, смонтируйте вручную, затем запустите: hdiutil compact /Volumes/Backups/MyMac.sparsebundle.
2. Если сжать не удаётся, возможно, придётся скопировать живые данные, пересоздать sparsebundle меньшего размера и скопировать обратно.
3. Установите жёсткое ограничение размера sparsebundle, если ваше место назначения это поддерживает. Сам macOS не показывает это в UI — нужно использовать tmutil setdestination или административный инструмент на сервере.
4. Рассмотрите место назначения, выделенное только под Time Machine, чтобы другие файлы не конкурировали за пространство. Облачные места назначения вроде Capsule Backup выделяют фиксированную квоту, которую ничто не может съесть.

Решение 4: Time Machine не находит диск бэкапа

Симптом: «Time Machine не удалось найти диск резервной копии», хотя вы видите его в Finder.

Диагностика: Диск смонтирован, но Time Machine потерял устойчивую ссылку на него (несоответствие UUID или идентификатора тома), либо SMB-шара отвалилась и автомонтаж не сработал.

Решение:

1. Для локальных дисков: откройте Системные настройки → Основные → Time Machine, удалите место назначения, добавьте заново. Time Machine обнаружит существующую папку бэкапа и продолжит, а не начнёт сначала.
2. Для сетевых шар: размонтируйте и переподключитесь через ⌘K в Finder. Сохраните учётные данные в Связке ключей, чтобы автомонтаж работал в будущем.
3. Убедитесь, что файловая система диска поддерживается Time Machine: APFS или HFS+ для локальных дисков, SMB3 для сети. exFAT и NTFS не поддерживаются.

Решение 5: «Произошла ошибка» без другой информации

Симптом: Классический общий диалог об ошибке без чего-либо пригодного для действий.

Диагностика: Это UI macOS сдаётся. Настоящая ошибка в логах.

Решение:

1. Запустите запрос к логу выше, чтобы найти первопричину.
2. Ошибка обычно один из других пунктов этого списка: права, сеть, повреждение sparsebundle, заполненный диск или поломка после обновления. Сопоставьте и примените соответствующее решение.

Решение 6: повреждение sparsebundle

Симптом: Time Machine отказывается монтировать место назначения, или посреди бэкапа жалуется на повреждённый sparsebundle.

Диагностика: Sparsebundle — это папка из маленьких файлов-«полос», вместе образующих виртуальный диск. Если полоса повреждена (часто из-за того, что источник отключили в момент записи или сеть упала во время критичного обновления метаданных), том становится немонтируемым.

Решение:

1. Смонтируйте шару, найдите sparsebundle и попробуйте смонтировать вручную двойным кликом. Если macOS предложит починить — соглашайтесь.
2. Из Терминала: hdiutil verify /path/to/MyMac.sparsebundle. Это сообщит, восстанавливаем ли том.
3. Если verify падает, попробуйте: hdiutil attach -noverify -nomount /path/to/MyMac.sparsebundle — подключить без монтирования, затем запустить Первую помощь Дисковой утилиты против подключённого образа.
4. Если починка удалась, немедленно запустите свежий бэкап в другое место назначения. Sparsebundle, которому однажды потребовалась починка, живёт на одолженном времени.
5. Если починка не удалась: ваша история снапшотов потеряна. Начните новый бэкап в новом месте. Подробнее в руководстве по восстановлению.

Решение 7: сетевая шара постоянно отваливается

Симптом: Бэкап стартует, идёт час-два, потом падает с сетевой ошибкой. Часто в паре с уведомлением Finder о том, что сервер отключился.

Диагностика: SMB-сессия обрывается. Причины — от нестабильности Wi-Fi до таймаутов NAT роутера, политики простоя на сервере и неуместных настроек энергосбережения, усыпляющих Mac посреди передачи.

Решение:

1. Переключитесь с Wi-Fi на Ethernet. Потери пакетов Wi-Fi за многочасовую передачу накапливаются.
2. Системные настройки → Экономия энергии → снимите «Усыплять диски, когда это возможно» и «Просыпаться для доступа из сети».
3. Системные настройки → Экономия энергии → увеличьте интервал «Выключать дисплей через» и убедитесь, что «Предотвращать автоматический сон, когда дисплей выключен» включено на десктопе.
4. Для специфических SMB-обрывов отредактируйте (или создайте) /etc/nsmb.conf и добавьте: [default] notify_off=yes signing_required=yes. Первое уменьшает чрезмерно болтливый путь уведомлений, который некоторые серверы плохо переносят.
5. Если ваш сервер навязывает таймаут простоя, запланируйте keep-alive активность или переместитесь на место назначения, спроектированное под длительные сессии Time Machine.

Решение 8: медленные инкрементальные бэкапы

Симптом: Ежечасные бэкапы, которые должны занимать секунды, занимают по 20–40 минут каждый.

Диагностика: Либо fseventsd перестраивается (см. Решение 1), либо на исходном диске столько мелких файлов, что фаза метаданных естественно медленная.

Решение:

1. Добавьте частых нарушителей в список исключений: node_modules, ~/.gradle, ~/.m2, образы дисков виртуальных машин, большие кеши контейнеров. Они легко пересоздаются и являются чистым шумом в бэкапе.
2. Из Терминала программно: tmutil addexclusion ~/projects/big-monorepo/node_modules. Повторите для каждого пути.
3. Подтвердите исключение: tmutil isexcluded ~/projects/big-monorepo/node_modules.

Решение 9: ошибки прав (Operation Not Permitted)

Симптом: Логи сообщают «Operation not permitted» по конкретным путям. Частые цели — ~/Library/Mail, ~/Library/Messages или песочницы сторонних приложений.

Диагностика: macOS использует TCC (Transparency, Consent, and Control), чтобы регулировать доступ к определённым пользовательским данным. backupd нужен Full Disk Access для чтения этих мест.

Решение:

1. Системные настройки → Конфиденциальность и безопасность → Полный доступ к диску.
2. Убедитесь, что Time Machine в списке и переключатель включён. Если её нет, добавьте вручную через кнопку + и перейдите к /System/Applications/Utilities/ или просто найдите её поиском.
3. Для некоторых версий macOS нужно добавить backupd напрямую. Путь: /System/Library/CoreServices/backupd.bundle/Contents/MacOS/backupd.
4. Перезагрузитесь. Запустите ручной «Сейчас» и проверьте логи на остаточные ошибки прав.

Решение 10: список исключений игнорируется

Симптом: Вы добавили папку в исключения, но она всё ещё в бэкапе или влияет на размер.

Диагностика: Исключение добавлено для старого пути (папку переименовали или переместили), либо добавлено через один механизм, а Time Machine читает из другого.

Решение:

1. Перечислите текущие исключения: sudo tmutil listexclusions.
2. Если исключение неверное, удалите: tmutil removeexclusion /path/to/folder.
3. Добавьте заново по канонически абсолютному пути.
4. Принудительно обновите оценку размера через tmutil calculatedrift или просто дождитесь следующего планового бэкапа; исключение вступит в силу немедленно.

Решение 11: зашифрованный диск не разблокируется

Симптом: Time Machine запрашивает пароль шифрования при каждом бэкапе или отказывается принимать правильный пароль.

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

Решение:

1. Откройте Связку ключей и найдите имя тома бэкапа. Удалите дублирующиеся или устаревшие записи.
2. Запустите «Сейчас» и заново введите пароль по запросу. Отметьте «Сохранить в Связке ключей».
3. Если пароль отклоняется как «неверный», но вы уверены в правильности, попробуйте ввести его через Дисковую утилиту. Смонтируйте sparsebundle через «Подключить» в Дисковой утилите и используйте пароль там. Если Дисковая утилита принимает — проблема чисто в записи Связки ключей, и повторное сохранение её решит.
4. Если Дисковая утилита тоже отклоняет: убедитесь, что вы не вводите пароль FileVault по ошибке, и почитайте разбор шифрования бэкапа Mac о различии двух слоёв. Для действительно забытого пароля шифрования Time Machine путей восстановления нет.

Решение 12: Time Machine сломан после обновления macOS

Симптом: Вчера работало. Сегодня, после минорного релиза Sequoia, бэкапы падают.

Диагностика: Обновления macOS регулярно подкручивают SMB-стек, базу TCC или внутренности Time Machine. Поломка почти всегда укладывается в одно из трёх ведёр: потерян Full Disk Access, потеряны SMB-учётки, или sparsebundle нужно «переблагословить» под новую версию.

Решение:

1. Заново дайте Full Disk Access для backupd, как в Решении 9.
2. Заново смонтируйте SMB-шару через ⌘K и пересохраните учётные данные в Связке ключей.
3. Если место назначения — сетевой sparsebundle, отключите и подключите заново. macOS иногда требуется заново проверить метаданные sparsebundle против новой ОС.
4. Если ничего из этого не работает, удалите место назначения в Системных настройках → Основные → Time Machine и добавьте заново. Существующие снапшоты будут обнаружены и продолжены, не стёрты.

Профилактика

Большинство сбоев Time Machine можно предотвратить небольшими постоянными вложениями.

• Проверяйте бэкапы ежеквартально. Восстановите случайный файл через браузер Time Machine. Подтвердите, что содержимое совпадает. По календарю. Если не делали полгода — сделайте сегодня.
• Запускайте hdiutil verify по sparsebundle раз в месяц. Смонтируйте, сначала отключив от Time Machine, потом проверьте. Ловит повреждения, пока они не съели вашу историю.
• Держите два места назначения. Локальный USB SSD для быстрого восстановления плюс облачное внешнее для аварийного. macOS ротирует автоматически.
• Запишите пароль шифрования. В менеджер паролей. Сегодня. День, когда забудете — день, когда он понадобится.
• Смотрите на значок в строке меню. Кликайте раз в день. Если последний успешный бэкап старше суток — разбирайтесь.

Когда начинать заново (крайняя мера)

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

1. Добавьте новое место назначения на отдельном диске и дайте ему завершить полный начальный бэкап.
2. Проверьте новый бэкап тестовым восстановлением.
3. Только после этого удалите сломанное место.

Никогда не удаляйте единственную копию истории снапшотов в надежде, что новый бэкап заработает — потому что если нет, вы остаётесь вовсе без бэкапов. Подробности о выборе нового внешнего места назначения — в руководстве по настройке облачного Time Machine или сразу в пошаговой инструкции.

Шире взгляд

Time Machine блистателен, когда работает, и удручающ, когда падает, потому что режимы сбоя так непрозрачны. Двенадцать решений выше покрывают примерно 95% сбоев, которые мы встречаем в реальной жизни. Остальные 5% обычно сводятся к реальной смерти железа, и тогда никакая починка не оживит диск — правильный ответ — другое место назначения, идеально такое, которое вы контролируете от и до. Capsule Backup отчасти существует, чтобы облачные места назначения Time Machine обходили многие из этих режимов сбоя, убирая «диск как точку отказа» как таковую.