Каково ожидаемое поведение Time Machine для больших папок с небольшим количеством измененных файлов?

Как Time Machine (на MacBook Pro High Sierra с APFS) узнает, какие файлы в папке изменились с момента последней резервной копии? Я знаю, что TM использует FSEvents для поиска каталогов с измененными файлами. Чего я не знаю, так это того, что делает ТМ, когда узнает, что 1+ файлов в папке изменились. Я ищу подробное техническое объяснение, а не информацию высокого уровня о самой Time Machine. Конкретно:

  • Какую информацию о каждом файле (например, в папке с 1 измененным файлом и 999 файлами, не изменившимися с момента последней резервной копии) использует TM, чтобы определить, какие файлы совпадают с последней резервной копией? TM смотрит только на размер файла и время модификации? Он действительно читает содержимое файла? Он читает атрибуты файлов?
  • Какие вызовы API файловой системы использует Time Machine для проверки того, какие файлы были изменены? В частности, делает ли он один (или небольшое количество) вызовов для каждой папки, например, для получения списка каталогов? Или он будет делать 1+ вызовов для каждого файла, чтобы получить дополнительную информацию, такую ​​как содержимое файла, атрибуты и т. д.?
  • Если ответы на приведенные выше вопросы различаются (например, «иногда TM делает XXX, иногда YYY»), то по каким причинам TM будет делать много вызовов файловой системы для каждого неизмененного файла в папке?

Я спрашиваю, потому что пытаюсь диагностировать медленные инкрементные резервные копии Time Machine на моем MacBook Pro конца 2015 года, работающем под управлением High Sierra. Каждое «ежечасное» резервное копирование занимает более 30 минут, даже если объем данных, резервируемых каждый раз, составляет менее 2 ГБ.

Глядя на журналы активности диска Time Machine (с использованием sudo fs_usage -f filesys backupd), виновником, по-видимому, является доступ к файловой системе неизмененных файлов сообщений и вложений, связанных с Outlook 2016 Mac.

Outlook создает 256 папок для сообщений и 256 папок для вложений и равномерно распределяет новые сообщения и вложения по этим папкам. Например, в моем профиле Outlook содержится около 250 000 сообщений, большинство из которых имеют более 1 вложения. Каждая из этих 512 папок содержит около 1000 сообщений. Я получаю около 500 новых сообщений в день, поэтому, если с момента последнего резервного копирования прошел день, в каждой из этих 512 папок будет 1-3 новых файла и около 1000 неизмененных файлов.

Глядя на журналы файловой системы, Time Machine делает много вызовов файловой системы для каждого файла, хотя только несколько сотен файлов были изменены из более чем 500 000 файлов в этих папках. Доступ к файловой системе для каждого неизмененного файла быстрый (~0,075 секунды в приведенном ниже примере журнала), но если вы умножите 0,075 секунды на 500 000 файлов, это составит более 10 часов! Time Machine запускает несколько потоков, поэтому каждое добавочное резервное копирование занимает не 10 часов, а более 30 минут для каждого «ежечасного» резервного копирования.

Это большой расход батареи и доступ к диску для просмотра более 500 000 файлов каждый час, которые не изменились. Обратите внимание, что 30+ минут — это скорость TM после того, как я использовал sudo sysctl debug.lowpri_throttle_enabled=0. Без этого изменения он еще медленнее.

Я пытаюсь выяснить основную причину проблемы:

  • Так устроен мой компьютер? Могу ли я внести изменения в свои файлы, в настройки Time Machine и т. д., которые заставят TM перестать тратить так много времени на проверку неизмененных файлов при каждом инкрементном резервном копировании?
  • Является ли проблема фундаментальной для того, как Outlook 2016 Mac хранит сообщения и файлы вложений, поэтому у каждого пользователя Outlook на Mac с большим и активным почтовым ящиком будет эта проблема? Например, делает ли Outlook что-то необычное с атрибутами, из-за чего TM тратит дополнительное время на изучение файлов Outlook по сравнению с другими приложениями, которые создают множество маленьких файлов?
  • Или основная причина в конструкции Time Machine, где ожидается, что если какие-либо файлы в папке изменились, то TM будет делать относительно дорогие вызовы файловой системы для каждого файла, чтобы проверить, какие файлы были изменены?

Вот образец журнала (для одного файла, который не изменился с момента последней резервной копии), который предполагает, что Time Machine выполняет много обращений к файловой системе для каждого неизмененного файла. Я насчитал 11 (!!!) обращений к файловой системе для этого одного 901-байтового файла, резервная копия которого уже сохранена и не изменилась с момента последней резервной копии.

09:14:19.783112  getattrlist                            .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000027   backupd.944294
09:14:19.783424  fsctl                                  .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000006   backupd.944294
09:14:19.783428  fsctl                                  .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000004   backupd.944294
09:14:19.783542  getattrlist                            .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000057   backupd.944294
09:14:19.783603  listxattr                              .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000016   backupd.944294
09:14:19.783612  listxattr                              .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000008   backupd.944294
09:14:19.805903  listxattr                              .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.022290   backupd.944294
09:14:19.806028  listxattr                              .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000109   backupd.944294
09:14:19.856232    HFS_update               (__M__c__)  .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000013   backupd.948297
09:14:19.856258  link                                   .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.050019   backupd.948297
09:14:19.856394  getattrlist                            .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000051   backupd.948297

Я знаю, что могу исключить папки Outlook из резервных копий Time Machine, но не решаюсь сделать это, поскольку это может помешать мне восстанавливать сообщения.

Я уже пытался удалить журналы FSEvents (с помощью sudo mv /.fseventsd /.fseventsd.bakперезагрузки) и разрешить их повторное создание, что значительно ускорило резервное копирование, так что оно займет всего несколько минут, если я не запускал Outlook с момента последнего резервного копирования. . Но после запуска Outlook резервное копирование занимает более 30 минут. Просматривая журналы, я убедился, что дополнительное время связано не с объемом данных резервного копирования — Outlook.sqlliteфайл размером 1,3 ГБ копируется каждый раз за 1–2 минуты — а вместо этого, похоже, вызван сотнями тысяч файлов, которые Машина времени смотрит, но не отступает.

Это не проблема сети и не проблема скорости моего резервного NAS-накопителя: когда TM резервирует большие файлы, он копирует 10-30 мегабайт в секунду через WiFi (у меня быстрый WiFi!). Кроме того, прямое подключение к моей гигабитной сети не увеличивает скорость, когда TM перебирает все эти крошечные файлы Outlook.

ОБНОВЛЯТЬ:

Как посоветовал Monomeeth в своем ответе ниже, я скачал и запустил Time Machine Mechanic (действительно полезный инструмент!). Вот результаты за последние 12 часов.

Analysis from 2018-05-23 19:38:58 +0000 to 2018-05-24 05:38:58 +0000 for 10 hours:
Backing up to /dev/disk2s2: /Volumes/Time Machine Backups/Backups.backupdb
on which there were 411.74 GB, 411.74 GB, 411.74 GB, 411.74 GB, 411.74 GB, 411.74 GB available.
Started 6 auto backups, and 0 manual backups; completed 7 backups successfully,
last backup completed successfully 7.0 minutes ago,
backed up a total of 16417 files, range 639 to 4666 in each backup,
total data for each backup was 2.09 GB, 2.1 GB, 1.89 GB, 1.58 GB, 1.66 GB, 1.59 GB, 1.54 GB.
Times taken for each auto backup were 93.8, 37.8, 29.8, 34.4, 35.4, 87.6 minutes,
intervals between the start of each auto backup were 140.5, 70.8, 63.4, 69.9, 65.9 minutes.
Created 0 new backups, and deleted 7 old backups,
cancelled 4 backups.
7 errors reported:
2018-05-23 13:27:42.967395-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr: error in user parameter list" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-23-113921.inProgress/B14EC326-8AE7-4C23-8F37-17BDEFCF9F1C
2018-05-23 20:33:49.535143-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-36 "ioErr: I/O error (bummers)" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-21-163447
2018-05-23 20:33:49.536821-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr: error in user parameter list" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-22-193257
2018-05-23 20:33:49.536960-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr: error in user parameter list" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-22-183736
2018-05-23 20:33:49.537620-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr: error in user parameter list" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-22-150607
2018-05-23 20:33:49.537704-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr: error in user parameter list" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-22-134626
2018-05-23 20:33:49.539118-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr: error in user parameter list" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-22-120245

Обратите внимание, что глубокого сканирования нет, и каждая резервная копия занимала не менее 30 минут, чтобы создать резервную копию 1,5–2 ГБ. Большую часть занимает один файл Outlook.sqllite объемом 1,3 ГБ, резервная копия которого, судя по журналам файловой системы, создается примерно за 2 минуты, что составляет около 10 мегабайт в секунду. Но большую часть времени (опять же согласно журналам файловой системы) занимает чтение/проверка 100 000 неизмененных файлов.

Это нормально? Кажется неожиданным, что TM знает, какие файлы были изменены (через FSEvents), но все равно должен просматривать каждый файл. Есть ли что-то необычное в файлах Outlook, из-за чего это происходит с файлами Outlook, но не с файлами других приложений? Может быть, Outlook использует расширенные атрибуты (например, атрибуты «Автор» и «Получатель» в файлах сообщений электронной почты), и именно эти атрибуты вызывают замедление?

Я не уверен, что делать с ошибками, но они имеют в виду удаление резервных копий. Возможно, это не связано с моими медленными резервными копиями?

Ответы (1)

КОРОТКИЙ ОТВЕТ

Да, это ожидаемое поведение.

Time Machine создает резервные копии только новых или измененных данных и ведет учет любых удаленных данных. Это включает в себя библиотеки, которые могут содержать десятки тысяч файлов (например, ваша библиотека фотографий) и другие местоположения (например, каталоги/папки, содержащие большое количество файлов (например, используемые MS Outlook). Он не делает новую резервную копию Вся библиотека/папка каждый раз, когда вы вносите в нее изменения, но создает резервные копии только тех элементов, которые были изменены.Чтобы Time Machine делала это правильно, необходимо проверять каждый элемент, чтобы определить, что изменилось с момента последнего резервного копирования.

ДЛИННЫЙ ОТВЕТ

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

  • Отредактировано , так как последняя резервная копия снова заархивирована в следующей резервной копии
  • Создано с момента резервного копирования последней резервной копии в следующей резервной копии
  • Удалено, так как последняя резервная копия не включена в следующую резервную копию (т. е. в этой резервной копии нет записи о нем, но сам файл все еще хранится для любых более старых резервных копий, частью которых он был)

Теперь путаница обычно возникает из-за того, как Time Machine фактически делает резервную копию. Я попытаюсь объяснить это ниже.

  1. Первоначальная резервная копия, которую TM делает на новом резервном диске, представляет собой полную резервную копию вашего Mac. Итак, если ваш Mac использовал 80 ГБ диска емкостью 1 ТБ, то первая резервная копия займет 80 ГБ места на новом диске резервного копирования.
  2. Все оставшиеся инкрементные резервные копии не делают полную резервную копию. Вместо этого TM создает резервную копию любых новых данных (т. е. недавно добавленных данных и любых отредактированных данных ) и ведет учет любых удаленных данных .
  3. В случае таких файлов, как «Пакеты» (например, пакет «Библиотека фотографий»), TM идентифицирует:
    • новые данные (например, новые фотографии в папке Masters в пакете библиотеки фотографий) и создайте их резервную копию.
    • измененные данные в вашем пакете библиотеки фотографий (например, отредактированные фотографии) и создайте их резервную копию
    • удаленные данные в вашем пакете библиотеки фотографий (например, фотографии, которые вы удалили) и сохраните запись об изменении
  4. Когда на резервном диске заканчивается место, TM удалит столько самых старых резервных копий, сколько необходимо, чтобы иметь возможность сделать следующее резервное копирование (и именно здесь пользователи могут потерять данные, которые не были частью более поздних резервных копий).
  5. Независимо от того, является ли это первоначальной полной резервной копией или инкрементной резервной копией, TM покажет ее пользователю, как если бы все они были отдельными полными резервными копиями. Это разработано на основе дизайна взаимодействия с пользователем (UX), чтобы пользователям было проще просматривать и находить данные, а также убеждать пользователей, что все это есть. Согласно Apple:

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

...Что отличает Time Machine от других приложений для резервного копирования, так это то, что оно не только хранит запасную копию каждого файла, но и запоминает, как ваша система выглядела в любой конкретный день, поэтому вы можете вернуться к своему Mac, как он выглядел в прошлом.

Источник: Mac Basics: Time Machine (веб-архив документа базы знаний Apple)

Так что да, это ожидаемое поведение. Используя пример в вашем вопросе, хотя вы считаете 11 случаев, все они вместе взятые заняли доли секунды для обработки Time Machine, и, с моей точки зрения, это стоит того спокойствия и удобства использования, что Time Предлагает машина.

Короче говоря, я бы не рекомендовал пытаться вмешиваться в это.

[ОБНОВЛЯТЬ]

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

Как вы знаете, Time Machine сверяется с базой данных событий файловой системы (FSEvents), хранящейся на каждом томе, чтобы определить, какие файлы были изменены с момента последнего резервного копирования.

Однако, если база данных FSEvents отсутствует или Time Machine определяет, что она повреждена или неполна, она выполнит глубокое сканирование. Если он выполняет глубокое сканирование, это означает, что он проверит отметку времени последнего изменения всех файлов (и каталогов) на соответствующем томе . В рамках этого глубокого сканирования Time Machine создает список всех элементов, которые изменились с момента последнего резервного копирования. Очевидно, что если вы выполняете резервное копирование на удаленное устройство (особенно через Wi-Fi), это действительно замедляет работу.

Хотя вы можете отключить запись FSEvent на томе, это вам не поможет, потому что вы хотите использовать Time Machine для резервного копирования своих данных, и это действие только заставит его выполнить глубокое сканирование.

В свете дополнительной информации, которую вы предоставили, вам нужно определить две вещи:

  1. Выполняет ли Time Machine глубокое сканирование каждый раз при резервном копировании?
  2. Если да, то почему это делается?

Чтобы ответить на первый вопрос, вы можете скачать и установить Time Machine Mechanic (T2M2) . Это анализирует ваши журналы, чтобы проверить, работают ли резервные копии Time Machine нормально или нет.

Главное в вашем случае — проверить, указывает ли T2M2 следующее:

started 1 deep traversal scans

completed 1 deep traversal scans

Если использование вышеуказанного инструмента указывает на то, что Time Machine действительно выполняет глубокое сканирование, это может вызывать беспокойство. Не так сильно, если это случайная вещь, так как это все равно может произойти после определенных событий (например, недавняя загрузка с другого тома, после полного восстановления, после отключения питания и т. д.), но если это происходит постоянно, то это происходит звонить в тревожные звоночки. В этом случае я отсылаю вас к Time Machine — Устранение неполадок с общими сообщениями резервного копирования .

Привет @Monomeeth - спасибо за ответ, но я действительно искал более подробную техническую информацию о том, как Time Machine решает, какие файлы в папке изменились. Я обновил свой вопрос, чтобы уточнить, что я ищу. Проблема, с которой я сталкиваюсь, заключается не в том, что TM создает резервную копию слишком большого количества данных, а в том, что TM требует слишком много времени, чтобы решить, какие файлы были изменены. 0,075 секунды на неизмененный файл умножить на 500 000 неизмененных файлов — это 10+ часов. Даже при многопоточности это все еще 30+ минут для «ежечасного» резервного копирования… и много потраченной батареи! Я пытаюсь выяснить, могу ли я ускорить процесс.
@JustinGrant Сначала он делает снимок APFS, а затем проверяет атрибуты файла. Я думаю, что он никогда не полагался на FSEvent.
@mspasov - Забавно, я переключился с другого решения для резервного копирования на Time Machine именно из-за другого ответа на вопрос «Спросите другого», в котором говорилось: «Поскольку 10.7 (Lion) macOS предоставляет механизм под названием FSEvents, который позволяет приложению получать уведомления об изменениях, чтобы оно могло выполнять свои функции. работу гораздо более эффективным способом. Time Machine использует FSEvents». apple.stackexchange.com/a/323718/61097 Ответ Мэтта неверен? Или просто TM в APFS работает иначе (и использует моментальные снимки, а не FSEvents), чем TM в старой файловой системе?
Извините я не прав. TM использует базу данных fseventd, чтобы найти, что изменилось, и, если база данных недоступна, сканирует изменения (но backupd не использует живые события fsevent с устройства fsevents).
@JustinGrant Извиняюсь за задержку с моим ответом - мне потребовалось больше времени, чем ожидалось, чтобы догнать некоторые из моих сообщений. Я обновил свой ответ - дайте мне знать, если я могу добавить что-нибудь еще.
@Monomeeth - не беспокойтесь, большое спасибо за полезную дополнительную информацию, особенно за указатель на инструмент Time Machine Mechanic. Я запустил этот инструмент и обновил свой ответ результатами. Резюме: никакого глубокого сканирования, только медленное резервное копирование и никаких ошибок, кроме проблем с удалением старых резервных копий (что, как я полагаю, не связано с медлительностью). Есть идеи, с чего начать устранение неполадок дальше?
Хм, должен признать, я немного удивлен. Описанные вами симптомы идеально совпадают с тем, что Time Machine выполняет глубокое сканирование вашего тома. Было бы хорошо провести прямое сравнение с использованием вашей текущей настройки, поэтому мне интересно, есть ли у вас внешний диск, который вы можете подключить напрямую к MBP для использования с TM в течение дня? Если это так, первое резервное копирование займет много времени, но последующие резервные копии меня заинтересуют. Еще один простой тест — выйти из MS Outlook перед следующей парой резервных копий, чтобы увидеть, вызывает ли это проблему с процессом TM. Дайте мне знать в любом случае.
@Monomeeth - когда я выхожу из Outlook, резервное копирование занимает всего несколько минут. Кажется, что проблема ограничена (или, по крайней мере, хуже всего) теми 512 папками Outlook, в каждой из которых 1-3 измененных файла в день. Если в этих папках нет изменений, то TM не будет сканировать каждый файл в них на наличие изменений. Как будто идет глубокое сканирование, но только папок с измененными файлами. В этом суть моего вопроса: нормально ли, что ТМ (индивидуально) обращается к каждому файлу в папке с небольшим количеством измененных файлов и гораздо большим количеством неизмененных файлов? Если нет, то могу ли я что-нибудь сделать, чтобы предотвратить такое поведение?
@JustinGrant Хм, это нормальное поведение для TM, но только тогда, когда он считает, что база данных FSEvents неверна. Симптомы, которые вы описываете, действительно соответствуют этому сценарию, за исключением того, что из T2M2 видно, что TM не выполняет глубокое сканирование. Может быть, использовать его снова (я думаю , что он восходит к 48 часам назад, так что, может быть, вернуться так далеко), чтобы посмотреть, что он найдет? Рад, что вы все еще делитесь результатами, чтобы я мог на них посмотреть. Если вы по-прежнему ничего не находите и поскольку проблема возникает только при запущенном Outlook, возможно, вы могли бы попробовать восстановить базу данных Outlook на всякий случай, если это имеет значение?
@Monomeeth - повторный запуск T2M2 дает практически идентичные результаты с результатами, которые я опубликовал ранее. Outlook больше не имеет функции «восстановления базы данных» в версии 2016 года, см. support.office.com/en-us/article/… . Кроме того, проблема не в «базе данных» (файл sqllite) — это отдельные файлы сообщений и вложений. Я также попытался удалить все резервные копии моей машины времени и начать заново - с теми же результатами. Я также попытался восстановить свой профиль Outlook - с теми же результатами. Любые другие идеи?
@Monomeeth - также я только что получил ответ от службы поддержки Microsoft об этой проблеме. Их резюме: Ожидается, что Time Machine действительно проверит все файлы в папке с 1+ измененными файлами. Это действительно удивительно. Разве FSEvents не сообщает TM, какие файлы были изменены? Или, как говорит инженер службы поддержки Microsoft, использование TM FSEvents только позволяет узнать, какие каталоги изменились, но не дает эффективного способа узнать, какие файлы были изменены?
Вот что именно сказал инженер службы поддержки Outlook: «TimeMachine проверяет изменения для папки, из-за структуры профиля Outlook у нас много папок с отдельными для писем, вложений, и когда приходит письмо с вложением, он меняет пару папок и TimeMachine сканирует изменения и все файлы внутри (сообщения, источники сообщений, вложения сообщений). Это то, что Outlook не может контролировать, и именно так работает TimeMachine: мы просто сохраняем данные на жестком диске».
@Monomeeth - Ага! Кажется, я понял, что происходит. Я создал тестовый каталог с 10 000 файлов, запустил резервную копию, изменил один файл и запустил резервную копию, одновременно записывая журналы файловой системы. TM действительно выполняла работу с файловой системой для каждого неизмененного файла в каталоге. Но вызовы файловой системы происходили на резервном диске. инструмент fs_usage, даже с -wопцией, обрезал переднюю часть пути, из-за чего было невозможно определить, был ли это диск моего ноутбука или удаленный резервный диск, на который читались и записывались. (продолжение ниже)
В любом случае, когда каталог не изменяется, TM создает папку на резервном диске с жесткой ссылкой на ранее заархивированный каталог. Но когда в папке есть изменения, TM должен создать новый каталог и заполнить его жесткими ссылками на каждый файл в папке. Если в папках с изменениями 100 000 неизмененных файлов, создание всех этих ссылок занимает много времени . Резюме: поведение TM, к сожалению, ожидаемо в этом случае. ;-( Спасибо за вашу помощь в расследовании этой проблемы!
Не беспокойся. И спасибо, что поделились своими находками! Это и интересно/полезно знать. :)
Каково ожидаемое поведение Time Machine для больших папок с небольшим количеством измененных файлов?
СпросиСетьПолитика конфиденциальности1y, 0v