NAS共有の名前変更や再構築を行う前に、Time Machineバックアップの識別情報を保持する方法
共有先のバックアップ識別情報を、共有を名前変更、再構築、または移行する前に保持しておけば、Time Machine が既存のNAS履歴を引き継がなくなる可能性を低くできます。
ネットワーク上のTime Machine保存先は、sparsebundleを含む単なるフォルダではありません。Macは、通知されたネットワークボリューム、SMB機能、共有パス、認証情報、サービス側のボリューム識別子にも依存する場合があります。NASを変更する前に、これらの識別情報を記録し、既存のsparsebundleを保護してください。その後、各層を一度に1つずつ再構築または名前変更し、新しいバックアップの開始を許可する前に、Macが意図した保存先を認識していることを確認します。
メンテナンス前に現在のネットワーク保存先を記録する
NASのホスト名、SMBアドレス、共有名、アカウント、選択中のTime Machine保存先、sparsebundle名、現在のバックアップ容量を保存します。また、Bonjour広告や手動でマウントしたSMBパスなど、共有がどのように検出されるかも記録してください。
Appleは、ネットワーク上のTime Machineディスクは、バックアップファイルを含む任意のフォルダではなく、ネットワーク保存先として選択されると説明しています。
共有定義を変更する前に、NASのスナップショットまたはsparsebundleの独立したコピーを作成します。再構築したサービスが別の保存先識別情報を生成した場合や、Macが新しい履歴を開始した場合に、これをロールバックポイントとして利用できます。
NASが対応している場合はTime MachineボリュームUUIDを保持する
NASがTime MachineボリュームUUIDまたは同様の永続識別子を公開している場合は、SMB共有を削除または再作成する前に記録してください。表示上の共有名が同じでも、同じ識別情報が再生成されるとは限りません。
TrueNASのドキュメントでは、Time Machine UUIDがボリュームを識別すると説明されており、null値で共有を作成または更新すると、新しいUUIDが生成される場合があります。
以前の識別子を復元するのは、再構築した共有が本当に同じバックアップ保存先を表し、以前のサーバーインスタンスが稼働していない場合に限ってください。2つの稼働中の保存先で同じUUIDを重複して使用すると、それ自体が混乱の原因になります。
再構築した共有でTime MachineのSMB機能を有効にしておく
同じファイルシステムパスに通常のSMB共有を再作成するだけでは不十分です。再構築した共有がTime Machine対応と、Macが必要とするApple SMB拡張機能を引き続き通知していることを確認してください。
Sambaのvfs_fruitモジュールでは、Time Machineサポートが通知されるのは、共有のFULLSYNC機能と、対応環境でのmDNS登録を通じてであると説明されています。
Macを再接続する前に、古いSambaまたはNASの共有設定と新しい設定を比較します。機能が変わっていた場合は、sparsebundleを削除または名前変更するのではなく、まずサーバー側の公開設定を修正してください。
ボリューム識別子を無考慮に再利用しない
ネットワークボリューム識別子を保持する意味があるのは、それが同じ論理バックアップ保存先を指している場合だけです。古い共有を2台目の稼働中のNASにクローンする場合、両方のサーバーがまったく同じTime Machineボリュームであるかのように振る舞ってはいけません。
Netatalkは、ボリュームUUIDが堅牢な曖昧性排除を提供すると警告しており、無考慮に編集したり別のサーバーへコピーしたりすべきではありません。
移行中は、一度に1つの保存先だけを正式な保存先として運用します。以前のサービスを停止し、sparsebundleのコピーが完了してから、保持した識別情報で置き換え先をオンラインにしてください。
切り替え中もBonjourと共有選択を保持する
Time Machine用として明示的に指定されている共有フォルダと、そのフォルダがBonjourで通知されているかどうかを記録します。NASを再構築した後、Macで再選択する前に同じフォルダが公開されていることを確認してください。
Synologyの現行ガイダンスでは、この検出方法を使用する場合、管理者はTime Machineフォルダを設定し、Bonjour Time Machineブロードキャストを有効にする必要があります。
NASのホスト名を変更する必要がある場合は、まず新しいSMBパスで意図した共有にアクセスでき、保護したsparsebundleが引き続き含まれていることを確認します。空の置き換え先共有を、Macが最初に認識する保存先にしないでください。
自動バックアップを再開する前に既存の履歴をテストする
自動バックアップを一時停止した状態で、再構築した保存先に再接続し、古いsparsebundleが表示されることを確認します。以前の履歴から既知のファイルを1つ参照または復元してください。最初の管理下でのバックアップ中に、2つ目のsparsebundleが作成されないか共有を監視します。
ASUSTORは、対応するNASシステムでTime MachineバックアップにSMBを使用することを推奨しており、サーバー側のTime Machine固有のSMB公開設定が保存先の一部であることを強調しています。
Time Machineが既存の履歴に追記し、2つ目のバンドルが作成されなければ、メンテナンスは完了です。識別情報を保持できず、Macがすでに新しいバックアップを開始している場合は、関連するZimaSpaceの記事新しいTime Machine sparsebundleが復旧手順となります。
よくある質問
SMB共有名を同じにしておけば十分ですか？
いいえ。表示名は識別情報の1つにすぎません。NASによっては、Time Machine機能、サービスの通知、認証情報、ボリューム識別情報が異なる状態で共有が再作成されることがあります。
再構築したNASに合わせて既存のsparsebundleの名前を変更すべきですか？
予防策として名前を変更するべきではありません。まずバンドルを保護し、保存先の識別情報を安定させてください。イメージの名前を変更しても、Time Machineが使用する関連付けが自動的に更新されるわけではありません。
古いTime Machineサーバーがまだ稼働している間に、再構築した共有をテストできますか？
注意が必要です。同じ論理識別情報を示す2つの稼働中の保存先があると、検出が混乱し、どちらのsparsebundleが更新されているのか分からなくなる可能性があります。正式なサーバーを1台に限定した、管理下での切り替えを推奨します。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
