TIL: Appleが「Time Machine」を再びタホで壊した

2026年2月2日原文(taoofmac.com)

概要

Time Machine のバックアップが 突然停止 し、通知もエラーもなし
macOSのSMB設定変更 が原因で、 Synology NAS との互換性問題発生
設定修正 で一時対応可能だが、将来的な再発リスクあり
Proxmox+Docker による代替バックアップ案の検討
Appleの透明性不足とバグ への不満

Time Machineのバックアップ問題と原因

Obsidian vault のトラブルをきっかけに Time Machine から復元を試みるも、バックアップが 2ヶ月間停止 していた事実を発見
Synology NAS を SMB経由 でTime Machineターゲットとして長年利用、これまで問題なし
macOSのSMBデフォルト設定変更 （signing_required=no→yes）が原因で、 通知やエラーなし にバックアップが停止
バックアップ停止 は復元時まで気づかず、 データ損失リスク の顕在化

一時的な解決策：macOS側のSMB設定変更

Macの /etc/nsmb.conf ファイルを編集し、以下を追加
- [default]
  - signing_required=yes
  - streams=yes
  - soft=yes
  - dir_cache_max_cnt=0
  - protocol_vers_map=6
  - mc_prefer_wired=yes
Appleの設定変更 により、 NAS側SMB設定 が合わない場合は手動対応が必須
.sparsebundle名 に 非ASCII文字 が含まれていると認識エラーの可能性（今回は該当せず）

Synology NAS側のSMB推奨設定

コントロールパネル > ファイルサービス > SMB > 詳細設定 で以下を推奨
- 最大SMBプロトコル： SMB3
- Opportunistic Locking ：有効
- SMB2 Lease ：有効
- SMB Durable Handles ：有効
- Server signing ：無効または自動
- Transport encryption ：無効
DSMのUIによって表記は異なるが、上記設定で 安定運用 可能

バックアップの今後とDockerによる新構成

Appleの度重なる仕様変更 と 情報不足 により、 SMB依存のTime Machine 運用に限界
Proxmox+ZFS 環境に mbentley/timemachine Dockerイメージを利用し、 独自SMBサーバー 構築を検討
docker-compose例：
- image: mbentley/timemachine:smb
- container_name: timemachine
- restart: always
- network_mode: host
- 環境変数（TM_USERNAME, PASSWORD等）
- ZFSボリュームを /opt/timemachine にマウント
Dockerソリューション は SMB実装の柔軟性 と Synology依存回避 が可能

Appleへの要望と追加の不満

Time Machine は多くのユーザーにとって 重要なインフラ
Appleは 仕様変更の透明性 と 通知改善 を強化すべき
iOS新端末の復元バグ （Restore in Progress 100MB問題）は 6年間未解決
Reset Network Settings や再起動で一時対応も、 根本解決されず
OS体験重視の開発体制 への改善を強く希望

Hackerたちの意見

macOSの年次アップデートは始まってからあまり良くなかったけど、Tahoeは新たな低さだね。Appleは本当に方向転換が必要だよ。

└

ハイシエラの頃から、次のメジャーリリースには8月までアップグレードしない習慣に変えた。その頃には、だいたい半ダースくらいパッチが当たってるからね。そう、基本的にいつも1年遅れだけど、新機能は必要ないし。

Tahoeにアップグレードしてから、Time Machineの問題を解決しようとしてるんだけど、USBバックアップなんだ。今のところ、最近の修正方法はどれも効果がない。新しくフォーマットしたディスクへの初回バックアップは実行されるけど、すごく遅い。100%に達するかもしれないけど、決して終わらない。どこかのタイミングでパーセンテージが変わって、バックアップは10%近くで止まったまま。バックアップをキャンセルして再実行すると、また10%くらいまで行って止まる。複数のドライブで試したし、再フォーマットもした。セーフモードで起動したり、ネットワークをオフにしたり、色々やったけど。TimeMachineMechanicアプリも特に役立つフィードバックはないし。同じディスクにフルtarバックアップはできるけど、原因は全く分からない。ネットワーク共有へのバックアップは試してないけど、こんなに難しいはずじゃないよね。明らかに、これを出すときに色々なエッジケースをテストしなかった人がいる。

もっと大きな疑問は、なぜTime Machineがバックアップにネットワークファイルシステムを使い続けるのかってことだよね。あれは脆弱すぎて信頼できない。最近はAPFSのおかげで少し良くなったかもしれないけど、それは単に災害の間隔が少し長くなっただけ（データが消えて再初期化されて、バックアップが全部失われる）。カスタムプロトコルを使ってブロックを保存・復元するT.M.も時々失敗するけど、既存のバックアップを全部ダメにすることはない。追記：私は毎日のバックアップにArqを使ってるけど、時間ごとはT.M.を使ってる。T.M.が最終的にストレージをダメにしたときには、クラウドにしっかりした日次バックアップがあるから心配ないよ。

└

そもそも、Time Machineがバックアップにネットワークファイルシステムを使い続ける理由は何なんだろう？問題は彼らが失敗することだよ。他の人気のバックアップソリューションはちゃんとできてるし、失敗を黙って隠すこともない。

└

そもそも、Time Machineがバックアップにネットワークファイルシステムを使い続ける理由は何なんだろう？何と比べて？ネットワーク上のドライブにバックアップできる必要がある時に？

└

外部からの意見だけど（Time Machineは使ったことない）、最初に思ったのはrsyncがローカルでもネットワーク越しでも素晴らしく動くってこと。ネットワーク越しだと何が問題になるのか全然想像できないよ。部分的な転送を再開できて、チェックサムを比較して一致を確認できるなら、何が問題なの？

SuperDuperの大ファンなんだ。[1] 毎日の差分バックアップをセカンダリSSDに使ってる。Time Machineの時間ごとのバックアップはないけど、SuperDuperのバックアップはシステムディスクが壊れたときに直接ブートできるから安心。cronとrsyncを使えば同じことができると思うけど、面倒だからやってない。[1] https://shirt-pocket.com/SuperDuper/SuperDuperDescription.ht...

└

これ、ずっと買うリストに入ってるんだ。多分買った方がいいと思う。内蔵のリカバリーインターフェースからの復元は問題ないけど、オフラインのブート可能なバックアップも素晴らしいよね。それに、Time Machineを「標準」のバックアップとして使うのにも干渉しないし。多分、毎月外付けディスクにブート可能なイメージをダンプするためのカレンダーの予定を設定できる。

└

Time Machineのような時間ごとのバックアップはないけど、SuperDuperのバックアップはシステムディスクが壊れたときに直接ブートできるんだ。まあ、Appleがアップデートでそれを壊さなければだけど。

Time Machineはなぜか高く評価されてるけど（ファイルを復元する時の豪華なスクロールインターフェースとか？）、実際には使えないよね。ネットワーク越しのバックアップが可能だと見せかけてるけど、ネットワーク上では完全に不安定で、数ヶ月後にはバックアップが壊れたって言って、最初からやり直さなきゃいけないって言われる。

└

わからないけど、私にはうまくいってる。極めて稀にノートパソコンを交換しなきゃいけないとき、ケーブルを繋いでネットワークのバックアップを指示するだけで、1時間後には「私のノートパソコン」に戻ってる。

Hacker Newsで議論の続きを見る

ハクソク