中断された転送後にZFSレプリケーションを再開できることを確認する方法

はい。ただし、受信側で有効な再開トークンが保持され、そのトークンに必要なソーススナップショットがまだ存在している場合に限ります。

この判断が重要になるのは、ネットワーク障害や宛先障害によって raw または増分 zfs send が中断された場合です。競合する2つの状態は、有効な受信再開トークンがある状態と、トークンがない、またはソーススナップショットが破棄された状態です。保存済みの構成と破棄可能なデータから始め、各分岐を一度に1つずつ確認し、データ損失、権限、可用性のリスクが拡大する場合はテストを中止してください。

再開可能な Zfs レプリケーションの判断条件を定義する

何かを変更する前に、ソフトウェアとファームウェアのバージョン、デバイス識別情報、マウントまたはネットワークパス、空き容量、権限、観測された症状など、環境を記録します。ベースラインには、ネットワーク障害や宛先障害によって raw または増分 zfs send が中断された状況を再現できるだけの詳細を残してください。

最初の候補は、有効な受信再開トークンです。2つ目は、トークンがない、またはソーススナップショットが破棄された状態です。現在の再開可能な zfs sendは、テストで使用する仕組みまたはコマンドの境界を定義するものですが、この特定のホームサーバーでの観測に取って代わるものではありません。

判別テストを実行する前に、合格条件と中止条件を記述します。合格とは、いずれかの分岐が予測する証拠が変化し、それ以外のサービスは変更されないことです。不合格の場合は、推測に基づく修正を連鎖的に行うのではなく、保存済みの状態に戻します。

元の要件を下げずに主張をテストする

次の判別テストを使用します。破棄可能なレプリケーションを中断し、トークンを読み取り、再開した送信ストリームを生成して、最終的な宛先スナップショットを比較します。結果が変更した変数に起因するように、ワークロード、クライアント、パス、ファイルセット、タイミングを一定に保ちます。

ZFS の送受信を使用して、分岐を実際に区別できるフィールドを選択し、そのタイムスタンプ、終了ステータス、エラーテキスト、デバイスまたはスナップショットの識別情報、レイテンシ、転送バイト数、権限、復旧状態を取得します。識別情報、永続性、またはアプリケーション状態がテスト対象の主張である場合、コマンドが正常終了しただけでは不十分です。

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

token=$(zfs get -H -o value receive_resume_token pool/dst)
zfs send -t "$token" | ssh nas zfs receive pool/dst

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

合格: 再開ストリームが完了し、ソースと宛先のスナップショットが期待される GUID 系譜を共有します。合格した正確なバージョン、識別情報、ワークロードを記録し、結論が普遍的な主張ではなく条件付きのものになるようにします。

不合格: トークンが存在しない、宛先がロールバックされた、または必要なソーススナップショットが削除されています。ネットワーク、メモリ、権限、ソースの整合性が両方に影響する可能性があるため、不合格だけで反対の分岐が証明されるわけではありません。エスカレーションする前に、これらの共有依存要因を切り分けてください。

例外または曖昧な結果: 再起動にかかるコストを許容できると判断した後でのみ、部分的な受信を中止します。復元可能なコピーが存在するまで、ログを保持し、修復、削除、破棄、再パーティション、再帰的な所有権変更のコマンドを実行しないでください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

元のワークロードで判断を確認する

観測された分岐に対応するアクションを適用し、その後、縮小した代替条件ではなく元の条件を再実行します。再開ストリームが完了し、ソースと宛先のスナップショットが、2サイクルにわたって、または関連する再起動、スリープ、中断、負荷遷移の後も、期待される GUID 系譜を共有した場合にのみ、判断が有効になります。

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

中止境界は明確です。トークンが存在しない、宛先がロールバックされた、または必要なソーススナップショットが削除された場合は、最後に検証済みの構成に戻し、証拠を保持します。分岐が再現可能な場合に限り、より詳細なプラットフォームまたはハードウェアテストへエスカレーションしてください。

目標とする結果が得られたら、ローカルリポジトリの構成と比較し、修正によって隣接するサービスにリスクが移っていないことを確認します。新たなバックアップ、識別情報、タイムアウト、または可用性の障害が発生した場合、目標テストが成功していても変更は失敗です。

よくある質問

再開可能な ZFS レプリケーションについて、残る疑問は通常、すべての中断された受信でトークンが作成されるのか、中断後に古いソーススナップショットを削除できるのか、最終レプリカをどのように検証するのか、という点です。以下では、これらのエッジケースを主な判断から分けて説明します。

合格の境界は変わりません。再開ストリームが完了し、ソースと宛先のスナップショットが期待される GUID 系譜を共有することです。後続の条件によってファイルシステム、識別情報、ネットワークパス、またはアプリケーションバージョンが変わる場合は、その変更の影響を受ける判別テストだけを繰り返してください。

トークンが存在しない、宛先がロールバックされた、または必要なソーススナップショットが削除された場合は、実験を広げるのをやめてください。その時点では、再起動にかかるコストを許容できると判断した後でのみ部分的な受信を中止し、プラットフォーム、ストレージ、またはハードウェアの担当者へエスカレーションする前に証拠を保持します。

中断された受信では必ずトークンが作成されますか？

いいえ。受信で再開可能な動作を使用し、トークンが保持される状態で失敗する必要があります。

中断後に古いソーススナップショットを削除できますか？

再開したストリームがそれらに依存しなくなり、宛先が検証されるまでは削除できません。

最終レプリカはどのように検証しますか？

コマンドの終了ステータスだけでなく、スナップショットの GUID 系譜、プロパティ、期待されるファイル、復元サンプルを比較します。

再開可能な ZFS レプリケーションについて、実際の答えは条件付きのままです。再開ストリームが完了し、ソースと宛先のスナップショットが期待される GUID 系譜を共有することです。トークンが存在しない、宛先がロールバックされた、または必要なソーススナップショットが削除された場合は、再起動にかかるコストを許容できると判断した後でのみ部分的な受信を中止してください。元のワークロードに耐えられない部分的な成功は、互換性とは言えません。