壊れた ZFS レプリケーションチェーンは、いつ再シードすべきですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

When Should You Reseed a Broken ZFS Replication Chain? - Zima Store Online

有効な共通ベースを証明できない場合、またはチェーンの修復に宛先の未検証ロールバックが必要になる場合は、再シードしてください。まず最後に読み取り可能なレプリカを保全します。

ホームNASでは、次の増分送信を強制して実行させる近道に手を出しがちです。しかし、それでは親スナップショットの欠落、宛先の分岐、あるいは受信先がもはや想定しているデータセットではないことが隠れてしまいます。まず、どちらも変更せずに両側のインベントリを作成し、共有ベースがまだ存在するかを証明してください。安全に増分を継続できる証拠がない場合は、段階的なフルシードを使用します。

両側が同じベースをまだ共有していることを証明する

ソースデータセット、宛先データセット、スナップショット、ブックマーク、受信再開状態を読み取り専用でインベントリ化することから始めます。都合のよいスナップショット名だけでなく、候補となるベースが意図したデータセットに属していること、同じレプリケーション履歴を表していることを確認します。クリーンアップ前に一覧を保存しておけば、次の操作を選んだ理由を説明できます。

増分ZFSレプリケーションでは、受信側にすでにベースが存在している必要があります。そのため、実用的なスナップショットレプリケーションの手順では、同一のラベルが連続性を証明すると決めつけず、共有履歴を意図的に維持します。

検証済みのベースが両側に存在する場合は、非破壊の増分テストに進みます。名前は存在していても識別情報またはデータセットパスが異なる場合は、チェーンは未検証として扱います。共通ベースが残っていない場合は、これ以上スナップショットを削除したり、宛先を強制的に過去へ戻したりしないでください。判断はすでに段階的な再シードへ傾いています。

レプリカを変更せずに増分計画をテストする

検証済みのベースと最新のターゲットを使って送信案を作成しますが、まだライブの宛先へパイプしないでください。ドライラン、詳細な見積もり、またはレプリケーションツールのプレビューモードを使用します。受信によってデータが変更される前に、ソースパス、宛先パス、ベーススナップショット、ターゲットスナップショット、再帰フラグ、想定ストリームサイズを確認します。

共通ベーススナップショットがないとスケジューラーが報告するのは、単に再試行を求めているのではなく、安全でない推測を拒否しているということです。何度再試行しても、削除された共有履歴が再作成されることはありません。

正確なベースとターゲットからのストリームが差分相当のサイズであれば、チェーンを修復できる可能性があります。データセット全体に近いサイズのストリーム、予期しないデータセット、または強制的なロールバック要件がある場合は、プレビューは失敗です。そこで停止し、現在のレプリカを保全してください。コマンドが実行できるまでフラグを変更し続けることは、検証ではありません。

履歴と宛先の状態が一致する場合にのみ修復を選ぶ

共通ベースが検証済みで、宛先が独立した作業コピーになっておらず、プレビューが想定どおりの差分を示す場合にのみ、増分経路を修復します。修復期間中は宛先を読み取り専用に保ちます。ツールが対応している場合は、まず新しい子データセットまたはステージング先へ送信し、比較してから昇格させます。

有効なベースが存在しない場合、宛先が分岐している場合、必要なロールバックによってまだ必要なスナップショットが失われる場合、またはチェーンの検証にかかる時間が、管理された新規フル転送のコストを上回る場合は、再シードしてください。増分スナップショットの祖先関係に関する議論からも、中間の名前より、利用可能な共通ポイントを保持することのほうが重要だと分かります。

別の検証済みコピーが存在しない限り、空き容量を確保するために古い宛先を消去しないでください。より安全な再シードでは、別のデータセットまたはプールへ書き込み、新しいコピーを検証してから、壊れたチェーンを廃止します。両方を保持する容量がない場合は、最後に読み取り可能なレプリカを実験台にするのではなく、一時的な容量を確保するまで停止してください。

Featured

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

ZimaCube2

2回のレプリケーションサイクルにわたって新しいチェーンを検証する

フル受信が1回成功しただけでは、ストリームが到着したことしか証明できません。ソース上で小さなテストファイルを作成するかプロパティを変更し、次回のスケジュール済みスナップショットを取得して、新しい共通ベースを使った2回目の増分サイクルを実行します。両方の実行後に、データセットのプロパティ、スナップショット一覧、ファイルのサンプル、レプリケーションログを比較します。

元の障害に再開動作が関係していた場合は、以前の再開トークンの失敗経路を祖先関係の欠落とは分けて扱い、同じ症状によって誤った修復に戻らないようにします。

新しいシードが読み取り可能で、2回目の増分転送が差分相当のサイズで成功し、再起動またはスケジュール実行後に想定したスナップショットとファイルが現れれば、復旧は成功です。これらの確認が完了するまで、以前のレプリカを保持してください。識別情報が再び変わる場合、宛先を読み取り専用に保てない場合、またはツールが予期しないベースを繰り返し選択する場合は、エスカレーションしてください。