- 標記の問題発生
- 【実録】64TB Time Machineが容量不足・First Aid失敗・Pegasus認識不良から復旧した方法
- STEP1 ディスクが認識しているか確認
- 確認ポイント
- STEP2 Time Machine設定確認
- STEP3 バックアップ一覧
- STEP4 ボリューム内を見る
- STEP5 容量確認
- STEP6 各バックアップ容量を調査
- STEP7 中断バックアップを確認
- STEP8 リネーム（安全確認）
- STEP9 削除
- STEP10 APFS容量確認
- STEP11 残った途中バックアップ確認
- STEP12 動作確認
- STEP13 途中バックアップ削除
標記の問題発生
MacのTimemachineが（古いバックアップを削除すればバックアップできるはずなのに）「Timemachine用のHHDの容量が足りなくてバックアップできませんでした」を繰り返すようになった。
なんでやねん。古いバックアップを自動的に消して保存スペースを確保できるでしょ？
そして仕様上、どの「古いバックアップ」を残すかどうかは通常のメニュー（メニューバーのTimeMachineのところとか、システム設定とか）では選べない。
ちなみに現環境は以下の通り。棒線は全て（今どき…）Thunderbolt3のディジーチェーン。
Mac Studio
│
R4
│
R8
│
R8(Time Machine) ←ここでMac Studioとそれ以降ストレージのバックアップを管理（当然HDD容量は余裕をもって用意）
そこで今回は次の手順で原因の究明と解決を試みた。
1. ChatGPTを使う
以上！
チャッPとの主なやりとり（理解できてる範囲で…）は以下の通り。
- どこが問題で現象が起きているかの特定
- チャッPの指示どおりにTerminalを使った検証の結果、バックアップの途中で止まっているデータ（＝要らないデータ）が大量にあることが判明（Time Machine用のストレージの半分以上だった…）
- そのデータを（またTerminalを使って）削除
便利な世の中になった反面、こんなTipsを綴ったブログの存在意義もなくなっていきますなぁ〜備忘録として書いたけども。
以下はチャッPが出力してくれた今回の作業内容。ブログ形式にして、と頼んだので参考になる場所がある方は参考にしていただければ、と。
【実録】64TB Time Machineが容量不足・First Aid失敗・Pegasus認識不良から復旧した方法
環境
- Mac Studio
- Promise Pegasus2 R8（64TB）
- APFS
- Time Machine専用ボリューム
症状
- Time Machineが「容量不足」でバックアップできない
- First Aid失敗
- Pegasusが認識しなくなることがある
- 空き容量93GBしかない
STEP1 ディスクが認識しているか確認
diskutil list確認ポイント
- APFS Containerが見えるか
- Time Machineボリュームが見えるか
例
Promise RAID 0 TMここで表示されればハードウェアはほぼ正常。
STEP2 Time Machine設定確認
tmutil destinationinfo正常
Name : Promise RAID 0 TM異常
No destinations configured.
今回は途中でこの状態になったため、最後に再設定した。
STEP3 バックアップ一覧
tmutil listbackups最初は
No backups foundになった。
これは
「バックアップが存在しない」
ではなく
Time Machineが管理情報を読めない
ことを意味していた。
STEP4 ボリューム内を見る
ls -la "/Volumes/Promise RAID 0 TM"表示例
.previous
.interrupted
.inprogressここが重要。
正常なTime Machineなら
2026-06-20-120000
2026-06-21-120000など日時だけのバックアップが並ぶ。
今回は
.interrupted
.inprogressしかなかった。
STEP5 容量確認
df -h "/Volumes/Promise RAID 0 TM"結果
58TB使用
93GB空き100%使用。
STEP6 各バックアップ容量を調査
sudo du -sh "/Volumes/Promise RAID 0 TM"/*結果
7.4TB previous
51TB interrupted
164GB inprogressここで
51TBの.interrupted
が原因と判明。
STEP7 中断バックアップを確認
ls -la "/Volumes/Promise RAID 0 TM/2026-04-27-172101.interrupted"Time Machine途中のデータだった。
STEP8 リネーム（安全確認）
sudo mv \
"/Volumes/Promise RAID 0 TM/2026-04-27-172101.interrupted" \
"/Volumes/Promise RAID 0 TM/2026-04-27-172101.interrupted.DELETE"対象確認。
STEP9 削除
sudo rm -rf "/Volumes/Promise RAID 0 TM/2026-04-27-172101.interrupted.DELETE"今回は
約51TB
解放された。
STEP10 APFS容量確認
diskutil apfs list結果
64TB
使用9TB
空き55TBここで復旧成功。
STEP11 残った途中バックアップ確認
sudo du -sh "/Volumes/Promise RAID 0 TM"/2026-06-28-*結果
560KB interrupted
782GB inprogressSTEP12 動作確認
tmutil status結果
Running = 0途中で停止していた。
STEP13 途中バックアップ削除
sudo rm -rf "/Volumes/Promise RAID 0 TM/2026-06-28-043030.inprogress"STEP14 Time Machine再設定
GUIから
システム設定
↓
一般
↓
Time Machine
↓
バックアップディスク追加Promise RAID 0 TM
を再登録。
これで正常にバックアップ開始。
Pegasusが認識しなかった原因
切り分けは
Mac
│
R4
│
R8
│
R8(Time Machine)ではなく
Time Machine用R8だけ直結
した。
これで認識したため
- Mac故障ではない
- Time Machine R8故障ではない
- デイジーチェーン側の問題
と判定できた。
今回一番重要だったコマンド
ディスク確認
diskutil list容量
df -h "/Volumes/Promise RAID 0 TM"バックアップ容量
sudo du -sh "/Volumes/Promise RAID 0 TM"/*APFS確認
diskutil apfs listTime Machine状態
tmutil status復旧前
- Pegasus認識不安定
- First Aid失敗
- 空き93GB
- Time Machine停止
- 51TBの壊れたバックアップ
復旧後
- Pegasus正常
- APFS正常
- 空き55TB
- Time Machine再設定完了
- バックアップ再開可能
注意事項
今回の方法は、.interrupted（中断されたバックアップ）が Time Machine に認識されておらず、容量だけを占有していることを十分確認したうえで削除しています。
同じ名前のフォルダがあるからといって、すぐに削除するのは避けてください。 状況によっては、tmutil status や diskutil apfs list、バックアップの状態を確認してから判断する必要があります。また、重要なバックアップが他に存在しない場合は、事前にデータ保全の方法も検討することをおすすめします。
この一連の流れは、「容量不足」や「First Aid失敗」の裏に、巨大な .interrupted バックアップが潜んでいるケースでは有効なトラブルシューティングの一例として参考になると思います。
