Time Machineが66.1%で21時間止まり、真犯人はUSB2.0ハブ3段だった

何が起きたか

2026年8月23日、Time Machineのバックアップが「66.1%」と表示されたまま動かなくなった。 そのまま21時間。画面上は3分の2まで来ているように見えたが、実際に書き終えていたのは 884GB中の84GB、わずか9.5%だった。

進まないバックアップが、進んでいるふりをしていた。

現場の混乱

診断は罠の連続だった。

まず、数字が嘘をついた。画面の66.1%はtmutil statusのPercentをそのまま出したものではなく、 0.1 + Percent × 0.9という表示用の値だった。本当の進み具合はbytesとtotalBytesの生値を 割り算するまで分からなかった。

次に、止まっているのか遅いだけなのかが分からなかった。書き込みは毎秒10MBほど出ているのに、 宛先の空き容量は6時間まったく変わらない。確保済みのブロックに書き直し続けるループに はまっていた。この判別にはdf -kの定点観測がいちばん速かった。

止めようとしても止まらなかった。tmutil stopbackupのキャンセル要求は60秒でタイムアウトし、 backupdは「キャンセルに時間がかかりすぎた」と言い残して自分で落ちた。そのあともゾンビとして 居座った。出口は再起動しかなかった。

決め手になったのはspindumpだった。採った927サンプルのすべてが、 Copy Engine Writer → close() → HFS.kext → IOUSBMassStorageDriverという同じ場所で 詰まっていた。fs_usageを見ると、128KBの書き込みが一律0.2秒かかっている。毎秒640KB。 この時点では「HFS+宛先のclose()詰まり」に見えた。

原因

本当の原因が分かったのは翌日だった。外付けドライブは、USB 3.0バスの先に USB 2.0ハブを3段つなぎ、そのさらに先のHDDドッキングステーションにぶら下がっていた。 実リンクは480 Mb/s。ドックそのものはUSB 3.0対応で、ボリューム名には「USB 3.0」と 入っていたが、それはただのラベルで、実際の速度とは何の関係もなかった。

USB 2.0の転送方式は1コマンドずつ往復する。小さなファイルが大量にあるTime Machineでは、 帯域より先に往復回数が限界になる。毎秒640KBという数字も、USB 2.0で同期書き込みを flushしたときの速度そのものだった。2時間分のログにI/Oエラーは1件もなく、 ドライブの故障ではなかった。

対策

ハブを外してMacへ直結したら、リンクは5 Gb/sになった。転送速度は5.6MB/sから79.9MB/s、 ディスクのIOPSは29から464、処理できるファイル数は毎分2,800件から13,905件に増えた。 効いたのは帯域よりも、IOPSが16倍になったことだ。

宛先もHFS+からAPFSの専用ボリュームに移した。初回のフルバックアップは 471.04GBを2時間27分、平均53.4MB/sで完走した。

教訓は一つ。外付けが遅いときは、ドライブを買い替える前にケーブルの経路を疑う。 system_profiler SPUSBDataTypeでリンク速度にGb/sが出ているかを最初に見る。