Time Machineは役に立ちます。
バックアップさえ取っておけば
過去の状態に戻せるし、Macが壊れても復元できる。
実際にそれで助かったこともあります。
ただ、ひとつ気になっていることがあります。
このNAS、容量が多すぎないか。
そもそも、満杯になるのだろうか。
まず結論（現実解）
必要な容量の決め方は、次のようにするのが現実的です。
まず最初に、
Time Machineの容量は、
簡単には計算できません。
代わりに、シンプルに見積もります。
- 最も古いバックアップがどこまで残っているかを見る
- 空き容量がどれくらいあるかを見る
これで、
今の使い方でどれくらい持つかの目安が分かります。
例えば、
- 3ヶ月で半分使っているなら、このままなら半年くらい
- 1年分残っているなら、十分
厳密ではありませんが、実用上はこれで困りません。
最初に用意する際は、
「内蔵SSDの2倍程度」が目安と言われています。
根拠ははっきりしませんが、
普通に使う分には問題ないようです。
とはいえ、もう少し根拠のある見積もりができないかと、
足掻いて挫折した記録がこの続きです。
ここから先（つまづいた話）
なぜ計算できないのかを知りたい人向けに、
少しだけ踏み込んで整理しておきます。
※できない理由の説明なので、正直あまり面白くはありません。
きっかけ（違和感）
最初は単純に考えました。
1回のバックアップでどれくらい増えるのか。
仮に1GBずつ増えるとしたらどうなるか。
でも、ここで違和感が出ます。
1GBというのは、とんでもない量です。
文字データで考えると、
- 1文字 ≒ 1バイト
- 1GB ≒ 約10億文字
原稿用紙（400字）で考えると、数千枚レベルになります。
それを1時間ごとに増やすというのは、現実的ではありません。
これを元にざっくり計算すると、
1TBあれば10年単位で使えることになります。
本当なのでしょうか。
計算できるのでは？と思った
そこで考えました。
何が追加されて、何が削除されたかが分かれば、
容量も計算できるのではないか。
Time Machineには、バックアップ同士の違いを調べる仕組みがあります。
tmutil を使うと、
- 新しく追加されたファイル
- 削除されたファイル
- 変更されたファイル
を確認できます。
また、
- どの日時のバックアップがあるか
- どのくらいの間隔で実行されているか
といった履歴も分かります。
つまり、「何が変わったか」は分かります。
ログで何が分かるか
さらにログも見てみました。
ログから分かるのは、次のような内容です。
- バックアップの実行タイミング
- 成功・失敗
- 処理時間
- 実行された処理内容（スキャン・コピーなど）
- エラーやスキップ
ただし、
- 容量がどれくらい増えたか
- どのファイルがどれくらい容量を使ったか
は分かりません。
情報は足りるのか
ここまで分かれば、
自分の使い方でどのくらい容量が増えるか、
測れそうに見えます。
ところが、うまくいきません。
なぜ計算できないか
差分は単純ではない
Time Machineは、ファイル単位ではなく変更部分で管理されます。
ファイルサイズとディスク使用量は違う
ディスクには最小単位があり、
ファイルサイズと実際の使用量は一致しません。
削除してもすぐには消えない
削除したファイルも、過去のバックアップが参照していれば残ります。
見えているのは一部
各バックアップはその時点の状態だけを示しており、
他のバックアップ用のデータは見えません。
結論（挫折）
ここまでやって分かりました。
理論的には計算できるかもしれませんが、
現実的ではありません。
理由は、
- 情報が分散している
- 完全なデータが取れない
- 誤差が大きい
最初の結論に戻ります
Time Machineの容量は、
正確に計算するものではなく、
足りているかを確認できれば十分です。
実用的な判断方法
見るのは次の2つだけです。
- 最も古いバックアップ
- 空き容量
これで、
どれくらい持つかは十分に分かります。
まとめ
最初は、ちゃんと計算したいと思っていました。
でも実際にやってみると、
これは計算するものではないと分かりました。
欲しかったのは、
正確な数値ではなく、
どれくらい前まで戻れるかという目安です。
Time Machineは、
正確に管理する仕組みではなく、
安心して任せるための仕組みです。
そう理解したところで、
この興味はいったん置いとくことにしました。
学んだこと（つまづいて学んで、雑学が増えました）
今回、Time Machineの容量を調べていて、
結果としていくつかのことを学びました。
整理すると、次の3つです。
1. ネットワークの変化
AFP → SMB
以前は、Apple独自のAFP（Apple Filing Protocol）が使われていました。
AFPはMacに最適化されたプロトコルで、
Mac特有のファイル属性（アイコン情報やリソースフォークなど）を扱うことに強みがありました。
その後、環境が変わります。
- WindowsやLinuxとの共存
- NASの普及
- クラウドやネットワーク利用の拡大
こうした流れの中で、より標準的な仕組みが求められるようになりました。
そこで採用されたのが、SMB（Server Message Block）です。
SMBの利点は次の通りです。
- OSを問わず使える（Windows / Linux / macOS）
- NASとの互換性が高い
- ネットワーク機器側の対応が充実している
つまり、
Mac専用の仕組みから、
世界標準の仕組みに移行した、ということです。
また、SMB側も進化しており、
Mac特有のファイル属性を扱えるような拡張も取り込まれています。
2. ファイルシステムの変化
HFS+ → APFS
以前はHFS+（Mac OS Extended）が使われていました。
これはハードディスク（回転するディスク）を前提に設計されたファイルシステムです。
特徴としては、
- 長いファイル名の管理
- Mac特有の属性管理
- 大容量ディスクへの対応
などがあります。
ただし、その前提は「回転するディスク」です。
その後、SSDが主流になります。
SSDは回転しないため、
- ランダムアクセスが速い
- 書き込み特性が異なる
といった違いがあります。
この特性に最適化されたのが、APFS（Apple File System）です。
APFSの利点は次の通りです。
- コピーが高速（実体コピーではなく参照コピー）
- コピーオンライト（変更時に新しいデータを作る）
- スナップショット機能
- 強力な暗号化
この仕組みによって、
見た目は同じでも、内部のデータの持ち方が大きく変わりました。
結果として、
- 容量の増え方が直感と一致しない
- 同じデータが複数のバックアップで共有される
といった現象が起きます。
また、SMBとAPFSの組み合わせにより、
Time Machineは安定性や速度の面で大きく改善されています。
そこで、 Time Capsuleに変わって、今僕が使っているのがこれです。
3. 文字の扱いの変化
NFD → NFC（＋混在）
ここは、今回実際にハマったポイントです。
以前は、ファイル名をNFD形式で扱っていました。
例えば「が」は、
- 「か」＋濁点
という2文字で管理されます。
一方、現在のSMBではNFC形式が使われます。
- 「が」を1文字として扱う
見た目は同じですが、内部的には別のデータです。
さらにややこしいのは、互換性の問題です。
過去のデータとの関係で、
- NFD（2文字）
- NFC（1文字）
が混在することがあります。
どこで問題になるか
通常のファイル操作では問題になりにくいのですが、
- NASのマウント
- バックアップ先の指定
- Time Machineの処理
といった場面で影響が出ることがあります。
この問題は日本語だけではなく、
ウムラウトなどを使う言語でも発生します。
現実的な対策
現時点での対策としては、
- アルファベット
- 数字
- 記号
でバックアップ先の名前を付けるのが安全です。
少し制約はありますが、
トラブルを避けるという意味では現実的な方法です。
こんな対策をしています。これが一番簡単な方法だと思います。
学びのまとめ
今回の話をまとめると、
- ネットワーク（AFP → SMB）
- ファイルシステム（HFS+ → APFS）
- 文字コード（NFD → NFC）
この3つの変化が重なって、
Time Machineの挙動が分かりにくくなっています。
シンプルに見える仕組みですが、
その裏側はかなり複雑です。
思ったより、奥は深かったです。
最後に一言
結局、容量の見積もりは計算ではなく観察に戻りました。
感覚としては、10年以上は持ちそうです。
コメント