送信先の再起動後に ZFS 送信再開トークンが機能しなくなるのはなぜですか？
宛先の再起動だけで、通常は ZFS の再開トークンが無効になることはありません。ただし、保存された受信状態、データセット、または必要なソース履歴が変更された場合は別です。
このトークンは、特定の中断された受信処理を説明する不透明な情報であり、後続の任意のレプリケーション試行に再利用できるブックマークではありません。再開可能な受信によって部分状態を保持した、宛先のファイルシステムまたはボリュームに属します。再起動後、タスクが別のデータセットを読み取っている、プールのインポート方法が変わっている、部分状態が消去されている、宛先が変更されている、必要なソーススナップショットが失われている、または互換性のないストリームが生成されている可能性があります。完全転送を再開する前に、両端でトークンを確認してください。
再起動後も部分的な受信状態が保持されていることを確認する
宛先で、中断された受信に使用した正確なファイルシステムまたはボリュームから receive_resume_token プロパティを読み取ります。プール名、データセットのパス、トークンの値、部分状態が使用している容量を記録してください。
FreeBSD ハンドブックでは、再開可能な受信によって部分状態が保持されること、また転送が完了するか状態が明示的に破棄されるまで、受信側のデータセットに不透明なトークンが保持されることが説明されています。
再起動後にプロパティが空の場合、再開可能オプションを付けずに受信した、部分状態が完了または中止された、別のデータセットを照会している、または自動クリーンアップによって削除された可能性があります。以前の転送からコピーしたトークンを再利用しないでください。
トークンが正確な宛先データセットに属していることを確認する
宛先プールが想定した名前でインポートされているか、レプリケーションが同じデータセットパスを対象にしているかを確認します。代替ルート、プール名の変更、親パスの変更、パスの構成要素を追加または削除するタスクオプションに注意してください。
Ubuntu の ZFS プロパティリファレンスでは、receive_resume_token はデータセットのプロパティであることが定義されています。つまり、トークンは、その保存状態を保持しているファイルシステムまたはボリュームから読み取る必要があります。
backup/pool/data から取得したトークンを、現在 backup/data を対象としている受信の再開に安全に使用できるとは限りません。部分的な受信を変更または破棄する前に、タスクのパスを修正してください。
宛先が変更またはロールバックされていないか確認する
中断後に実行されたコマンド、スケジュールタスク、レプリケーションソフトウェア、スナップショット保持設定、管理者の操作を調べます。ロールバック、クローンの昇格、データセット名の変更、受信の中止、同じターゲットへの新しい受信がないか確認してください。
Klara Systems は、レプリケーションツールが ZFS の send と receive に伴う宛先状態を管理することを説明しています。そのため、オーケストレーションタスクが保存状態をクリーンアップまたは置き換えることで、元の復旧経路を無効にする場合があります。
調査中は、レプリケーション先に通常のファイルを書き込まないでください。トークンがまだ存在していても、宛先の変更によってストリームがブロックされたり、ロールバックが必要になって新しい宛先データが破棄されたりする可能性があります。
ソースにスナップショットまたはブックマークのチェーンがまだ存在することを確認する
中断された転送に含まれるソースデータセットとスナップショットまたはブックマークを特定します。転送停止後の現在の保持状況や、スナップショットの名前変更・削除と照合してください。
FreeBSD の zfs-send マニュアルでは、zfs send -t が受信再開トークンからストリームを生成することが規定されています。これは、新しいストリームが任意の現在のスナップショットではなく、中断された受信処理に結び付くことを意味します。
保持ポリシーによって必要なソース履歴が削除されている場合、存在しなくなったデータをトークンから再構築することはできません。別のソースコピーが必要か、新しい完全送信が必要かを判断するまで、宛先に残っている部分状態を保持してください。
両方のシステムでプール機能とストリームオプションを確認する
ZFS のバージョン、有効なプール機能、暗号化状態、raw、compressed、embedded、large-block など元のストリームオプションを記録します。ソフトウェアまたはプールのアップグレード後に比較してください。
Oracle の再開可能レプリケーションに関するドキュメントでは、中断された転送の再開を、調整された send と receive の処理として説明しています。そのため、再起動後も互換性と元の転送コンテキストが重要です。
再起動だけで機能フラグが変わることはありませんが、停止中にアップグレードを実施した場合は変わる可能性があります。トークン自体が破損していると判断する前に、詳細な出力を有効にして再開コマンドを手動で実行してください。
宛先の起動後にレプリケーションサービスと SSH を確認する
宛先プールがインポートされていること、必要な暗号化データセットがロック解除されていること、SSH が稼働していること、レプリケーションユーザーが ZFS コマンドを実行できること、ストレージの準備完了後にのみタスクが開始されることを確認します。
TrueNAS のリモートレプリケーションに関するガイダンスでは、再起動後に宛先側の SSH とデータセットの前提条件が利用可能である必要があります。そうでない場合、自動化処理は保存されたトークンを試す前に失敗する可能性があります。
再開ストリームを開始する前に、認証と読み取り専用のプロパティ照会をテストしてください。ネットワークまたは権限の失敗が、上位タスクのログではトークンの失敗に見えることがあります。
部分的な受信を一度だけ再開するか、意図的に中止する
現在のトークンを使用して再開された送信ストリームを1つ生成し、同じ宛先で再開可能な受信に渡します。完全なエラー出力を保存し、並列でレプリケーションタスクを起動しないでください。
ZimaSpace のNAS データ移行ガイドでは、関連する安全原則として、宛先の検証が完了するまでソースとロールバック経路を保持することを示しています。
トークンが使用できず、部分状態を保持する価値もなくなった場合は、新しい完全転送または差分転送を生成できることを確認したうえで、サポートされている受信中止コマンドを使用して中止してください。中止すると保存された部分状態が解放され、元に戻すことはできません。
よくある質問
宛先を再起動すると、ZFS の再開トークンは必ず無効になりますか？
いいえ。保存された部分的な受信状態は、異常終了を含む中断に耐えられるよう設計されています。再起動後の失敗は通常、タスクが別のデータセットを読み取っている、部分状態が消去された、必要なソース履歴が変更された、または起動時の依存サービスが不足していることを示します。
ソースだけから新しい再開トークンを生成できますか？
いいえ。不透明なトークンは、宛先データセットに保存された部分的な受信状態から生成されます。ソースはそのトークンを使って継続ストリームを生成しますが、削除された宛先状態を単独で再作成することはできません。
部分的な受信はいつ中止すべきですか？
再開経路が使用できないこと、新しい転送をソースから生成できること、宛先の部分状態が復旧に不要であることを確認できた場合に限り、中止してください。削除する前に、ログと利用可能なスナップショットを保存してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
