ZFSフルスナップショットの送受信

ZFSフルスナップショットの送受信

私はサーバーAのZFSプールをサーバーB(バックアップサーバー)にバックアップし、毎日増分スナップzfs send/recvショットを使用してきました。

サーバーBはバックアップサーバーとして機能し、サーバーAとサーバーCに対してそれぞれ2つのプール(zfs41およびzfs49/tank)を予約します。

ハードウェアの問題により、サーバーAのZFSプールが消えました。できるだけ早く復元/修復したいと思います。

現在、私のサーバーBのスナップショットのリストは次のとおりです。

NAME                        USED  AVAIL     REFER  MOUNTPOINT
zfs41@2021Nov301205        14.9G      -     3.74T  -
zfs41@2021Dec011205        3.87G      -     3.74T  -
zfs41@2021Dec021205        3.77G      -     3.74T  -
zfs41@2021Dec031205           0B      -     3.74T  -
zfs49/tank@2021Nov301705   368G      -     3.52T  -
zfs49/tank@2021Dec011705  65.2G      -     3.52T  -
zfs49/tank@2021Dec021705  66.4G      -     3.52T  -
zfs49/tank@2021Dec031705     0B      -     3.52T  -

zfs49/tank@2021Dec031705サーバーBの最新バージョンはどこにありますか?

プール全体(スナップショットを含む)をサーバーAに戻したいのですが、実行する正確なコマンドがわかりません。

質問:サーバーBからzfs send zfs49/tank@2021Dec031705 | ssh <Server A host ip> zfs recv tankZFSプール全体とサーバーAのすべてのスナップショットを受信するのに十分ですか(それで増分バックアップを送受信できますか?)

ベストアンサー1

まず、サーバーAに空のプールを作成する必要があります。 zfs recv新しいプールを作成できません。したがって、サーバーAでは次のようになります。

zpool create -R /mnt zfs49 [ mirror diskID1 diskID2 ]

...または必要な他のVDEV構造。サーバーAのVDEV構造は、失われたプールの以前の構造と一致する必要はありません。データを入れるのに十分な大きさです。したがって、前回の選択で経験を積んだ場合は、今回はプールを作成するときより良い選択をしてください。しかし、そうです。 4kベースドライブを使用している場合も待つ必要がありますashift=12

また、以下の説明では、プール名とファイルシステム名が同一であることを理解しているので、zfs49サーバBのプールファイルシステムをサーバAのプールファイルシステムに復元する。tankzfs49tank

各ファイルシステムを明示的に転送するのではなく、recursive snapshotすべてのファイルシステムとそのスナップショットを含むプール全体を転送する方法を説明する方が有利です。

上記のサーバーAに空のプールを作成した後、次のステップはサーバーBに最新の再帰スナップショットを作成することです。このスナップショットは主にワンタイムリカバリ操作のためであるため、命名スキームと一致する必要はありませんYYYYMonDDHHMM。実際、このリカバリジョブスナップショットは寿命が短くなる可能性が高いため、他のジョブスナップショットと区別するのが役立ちます。

xferこのワンタイム転送の特定の目的のために、サーバーBで再帰スナップショットを作成し、名前をとして指定することをお勧めします。したがって、サーバーBでは次のようになります。

zfs snap -r zfs49@xfer

これで、Server Aに名前付きのネイティブ(空)プールがあるため、zfs49この再帰スナップショットをサーバーBからサーバーA(サーバーBから始まる)に転送できます。

zfs send -R zfs49@xfer | ssh <Server A ip> zfs recv -Fuv zfs49

私は次の理由で多くの-Fuvオプションを使用する傾向がありますzfs recv

  • -u新しく修復されたファイルシステムをサーバーAから(一時的に)アンマウントされたままにすることを確認しました。ZFSあるシステムから別のシステムにプールを転送し、既存のマウントポイントを破壊(上書き)すると、問題が発生しやすくなります。ステップ-R /mntのオプションもzfs createこれを防ぐため、「サスペンダーとベルト」の場合かもしれませんが、バックアップを移動して復元するときには注意しすぎるのは難しいです。
  • -v完了した各スナップショットが順番にリストされますので、作業がどのように進行しているかをフィードバックしてください。

zfs進行状況インジケータの場合、トランスポートがAndrew Woodの強力なパイプラインビューアを利用するのに最適な機会であることがわかりますpv(1)

(サーバーBから:)

zfs send -R zfs49@xfer |
  pv -Wbraft |   
  ssh <Server A ip> zfs recv -Fuv zfs49/tank

調整pvオプションあなたの好みとニーズに合わせて。

転送が完了したら、サーバーAのプールを確認し、特にマウントポイントに注意してください。構文/mntによっては、マウントポイントが接頭辞zpool create ...で付いていることを覚えておいてください。必要に応じて(サーバーAで)次のことができます。

zpool export zfs49
zpool import -N zfs49
zfs list

これによりプールがインポートされ、デフォルトのマウントポイントが表示されますが、コマンドは実際には何もインストールしないように指示zpool import -Nします。zpoolこれは、プールの取り付けポイントが実際にどこにあるかを並べて比較するのに役立ちます。プールのマウントポイントがサーバーAの既存のマウントポイントを上書きしないようにしてください。そうしないと、潜在的に重要なファイルシステムにアクセスできなくなる可能性があります。この使用は、新しく作成されたファイルシステムが誤った場所にマウントされるリスクを最小限に抑えるための試みとして、上記のzpool import -N使用と一致します。zpool recv -u

最後に、サーバーAのプールの外観が満足のいくものであれば、xfer両方のシステムからスナップショットを削除できます。サーバーAから:

zfs destroy -rv zfs49@xfer
ssh <Server B> zfs destroy -rv zfs49@xfer

良い解決策がない1つの注意点は、プール自体の属性をバックアップして復元することは簡単ではないことです。つまり、zpool代わりに読み書きオプションを渡す必要がありますzfs。これには、およびbootfsその他すべての有用な情報が含まれます。zpool get all zfs49ほとんどのデフォルト値は合理的であり、過去にデフォルト値を変更した場合は、そのデフォルト値を認識し、必要に応じてサーバーAの新しいプールで属性を手動で変更できることを願っています。それ以外の場合は、プールのプロパティをバックアップして復元する方法についてのトピックがまだ質問されていない場合は、独自の質問を受ける資格がある可能性があります。

おすすめ記事