Time Machineがバックアップ履歴を継続しているか、再作成しているかをテストする方法

移行、共有名の変更、認証情報の変更、または sparsebundle の修復後にMacをNASへ再接続する際、保存先の識別情報、継承されたバックアップ履歴、最近のスナップショット一覧、そして最初の新しい実行が増分転送になるか完全転送になるかを確認して、継続性を検証できます。

この判断は、移行、共有名の変更、認証情報の変更、または sparsebundle の修復後にMacをNASへ再接続する場合に重要です。競合する2つの状態は、既存の履歴が継承されて拡張されている状態と、古いバックアップの隣に新しいバックアップセットが作成されている状態です。保存済みの構成と破棄可能なデータから始め、各分岐を一度に1つずつ観察し、データ損失、権限、または可用性のリスクが拡大する場合は中止してください。

Time Machine履歴の継続性に関する判断の条件を定義する

変更を加える前に、ソフトウェアとファームウェアのバージョン、デバイスの識別情報、マウント先またはネットワークパス、空き容量、権限、観測された症状など、環境を記録します。ベースラインには、移行、共有名の変更、認証情報の変更、または sparsebundle の修復後にMacをNASへ再接続する状況を再現できるだけの詳細を残す必要があります。

最初の候補は、既存の履歴が継承されて拡張されている状態です。2つ目は、古いバックアップの隣に新しいバックアップセットが作成されている状態です。現在のtmutilの保存先チェックは、テストで使用する仕組みまたはコマンドの境界を定義するものであり、この特定のホームサーバーでの観察に取って代わるものではありません。

判別テストを実行する前に、合格条件と中止条件を書き出します。合格とは、無関係なサービスを変更せず、一方の分岐が予測する証拠だけが変化することです。不合格の場合は、推測に基づく修正を連鎖的に実行するのではなく、保存済みの状態へシステムを戻せる必要があります。

元の要件を緩めずに主張を検証する

次の判別テストを使用します。tmutilの保存先とスナップショット履歴を確認してから、転送サイズと保存先のバンドルを監視しながら、管理されたバックアップを1回開始します。結果を変更した変数に帰属できるよう、負荷、クライアント、パス、ファイルセット、タイミングを一定に保ちます。

Time Machineの保存先を使用して、分岐を実際に区別できる項目を選び、そのタイムスタンプ、終了ステータス、エラーテキスト、デバイスまたはスナップショットの識別情報、遅延、転送バイト数、権限、復旧状態を記録します。識別情報、永続性、またはアプリケーションの状態が検証対象の主張である場合、コマンドが正常終了しただけでは不十分です。

元の条件に再起動、再接続、再マウント、またはキャッシュを空にした状態が含まれる場合は、その操作の後にテストを1回繰り返します。最初の実行が破壊的である場合や、環境を復元できない場合は中止し、代わりに破棄可能なコピーで再現してください。

tmutil destinationinfo
tmutil listbackups
tmutil status

合格、不合格、例外の結果を解釈する

合格: 新しいローカルスナップショットが想定した保存先に接続され、実行時に変更されたデータだけが転送される。結論が普遍的な主張にならず、条件付きのまま保たれるよう、合格した正確なバージョン、識別情報、負荷を記録します。

不合格: 新しい sparsebundle が表示される、履歴が存在しない、または転送サイズが完全バックアップのベースラインに近づく。不合格であっても、ネットワーク、メモリ、権限、またはソースの整合性が両方の分岐に影響する可能性があるため、直ちに反対の分岐が証明されたことにはなりません。エスカレーションする前に、これらの共通依存要因を切り分けます。

例外または判定不能な結果: 両方の履歴がクォータを消費する前に実行を中止し、以前の保存先の識別情報を復元します。復元可能なコピーが存在するまで、ログを保持し、修復、削除、破棄、再パーティション、または再帰的な所有権変更のコマンドを実行しないでください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

元の負荷で判断を確認する

観測された分岐に対応する操作を適用し、その後、縮小した代替条件ではなく元の条件を再現します。新しいローカルスナップショットが想定した保存先に接続され、2回のサイクル、または関連する再起動、スリープ、割り込み、負荷遷移を通じて、実行時に変更されたデータだけが転送された場合にのみ、判断は有効です。

Time Machineのクォータを使用して、最も近い依存ワークフローを確認しますが、元のトリガーは変更しないでください。無関係なデータセット、共有、コンテナ、ユーザー、復旧ポイントは、以前のアクセス状態とタイミングを維持する必要があります。

中止の境界は明確です。新しい sparsebundle が表示される、履歴が存在しない、または転送サイズが完全バックアップのベースラインに近づく場合は、最後に検証済みの構成へ戻し、証拠を保持します。その分岐が再現可能な場合にのみ、より深いプラットフォームまたはハードウェアのテストへエスカレーションしてください。

目標の結果が得られたら、復元の検証と比較し、修正によって隣接するサービスへリスクが移っていないことを確認します。新しいバックアップ、識別情報、タイムアウト、または可用性の障害を伴う目標テストの成功は、依然として変更の失敗です。

よくある質問

Time Machine履歴の継続性について、残る疑問は通常、最初の実行が大きい場合は常に履歴が失われたことを意味するのか、2つの sparsebundle が似た名前を持つことがあるのか、新しいバックアップが開始された後に古いバンドルを削除すべきか、というものです。以下では、これらのエッジケースを主要な判断とは分けて説明します。

合格条件は変わりません。新しいローカルスナップショットが想定した保存先に接続され、実行時に変更されたデータだけが転送されることです。後続の条件によってファイルシステム、識別情報、ネットワークパス、またはアプリケーションのバージョンが変わる場合は、その変更によって影響を受ける判別テストだけを繰り返します。

新しい sparsebundle が表示される、履歴が存在しない、または転送サイズが完全バックアップのベースラインに近づく場合は、実験を広げないでください。その時点で、両方の履歴がクォータを消費する前に実行を中止し、以前の保存先の識別情報を復元します。プラットフォーム、ストレージ、またはハードウェアの担当者へエスカレーションする前に、証拠を保持してください。

最初の実行が大きい場合は、常に履歴が失われたことを意味しますか？

いいえ。OSのアップグレード、除外設定、ファイルシステムの変更、または長期間の空白によって、大きな増分バックアップが作成されることがあります。保存先の識別情報とスナップショットの系譜を確認してください。

2つの sparsebundle が似た名前を持つことはありますか？

はい。ファイル名だけでなく、マシンの識別情報と保存先のメタデータを使用してください。

新しいバックアップが開始された後に、古いバンドルを削除すべきですか？

継続性が証明されるか、新しい完全履歴が復元テストに合格するまでは削除しないでください。

Time Machine履歴の継続性に対する実際の答えは、依然として条件付きです。新しいローカルスナップショットが想定した保存先に接続され、実行時に変更されたデータだけが転送されることが必要です。新しい sparsebundle が表示される、履歴が存在しない、または転送サイズが完全バックアップのベースラインに近づく場合は、両方の履歴がクォータを消費する前に実行を中止し、以前の保存先の識別情報を復元してください。元の負荷に耐えられない部分的な成功は、互換性とはみなせません。