{"id":34661,"date":"2022-01-10T16:50:26","date_gmt":"2022-01-10T21:50:26","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=34661"},"modified":"2022-01-25T16:39:25","modified_gmt":"2022-01-25T21:39:25","slug":"has-time-machine-slowed-for-small-files","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/01\/10\/has-time-machine-slowed-for-small-files\/","title":{"rendered":"Has Time Machine Slowed for Small Files?"},"content":{"rendered":"

Howard Oakley<\/a>:<\/p>\n

\n

The only common factor is that, when trying to back up folders containing seriously large numbers of very small files, some of which may be hard links, the rate of copying falls to ridiculously low numbers.<\/p>\n

[…]<\/p>\n

Looking back before 10.15.3, Time Machine never seemed to have problems with copying Xcode, or with the .DocumentRevisions-V100 folder. Exclude those, and anything like them, from backups now, and it performs well, even to a NAS via SMB.<\/p>\n

[…]<\/p>\n

Monterey introduced a new hidden feature in Time Machine: before making its first backup to a new backup set, backupd<\/code> runs a speed test.<\/p>\n

[…]<\/p>\n

It’s unclear what Time Machine does with those results, or why it should perform the second test using many small files, unless Apple knows there’s a problem, perhaps.<\/p>\n<\/blockquote>\n\n

I’ve been seeing this problem, too, except that it’s also triggered by small files that I do<\/em> want to back up. I had to restructure my folders to prevent it from grinding away 24\/7.<\/p>\n\n

Previously:<\/p>\n