おおよその説明
だから私は現在複雑なZFS設定を持っており、それを再構築し、いくつかの既存のハードウェアを再利用したいと思います。
このようなタスクを実行するための推奨される方法は、すべてのデータをバックアップし、古いプールを削除し、新しいプールを作成し、データを復元することです。問題は次のとおりです。どのようにこれを行う最良の方法
設定と詳細
現在の設定は3×1TBおよび3×4TBドライブで構成されており、次のように設定されています。 2つの4TBドライブは、それぞれ1つの1TBと1つの3TBパーティションにフォーマットされています。
media_pool5×1TBディスク/パーティションで構成されたraidz1プール（-> 4TB使用可能、3.26TB使用）。three_t_pool3TBパーティション2つで構成されたミラーですか？ （-> 3TB使用可能、1.93TB使用）non_redundant4TBドライブが1つしか含まれていません（1.07TBを使用）。
これらの各プールには、プール全体で暗号化されたデータセットが1つしかありません。
media_pool/media_encrypted、、、three_t_pool/backupsそしてnon_redundant/nr_encrypted。
将来の設定では、次のように1TBドライブを取り外し、12TBドライブを追加します。
media_and_backups3つの4TBドライブと12TBドライブの4TBパーティションで構成されるraidz1プール（（4-1）×4TB = 12TB使用可能）non_redundant_foo8TBが残っている大容量ドライブです。
そして暗号化されたデータセット
media_and_backups/media_encrypted。media_and_backups/backupsnon_redundant_foo/nr_encrypted
（メディアとバックアップデータセットを分離する必要はありませんが、これは状況が複雑になる可能性があります）
移行プロセスは次のようになります（7台のドライブがすべて同じコンピュータに接続されています）。
- 希望の4TBおよび8TBパーティションで12TBドライブフォーマット
- 既存のプール/データセットデータを8TBパーティションにバックアップ
- 3つの古いプールを削除し、プールとその
media_and_backupsデータセット（media_and_backups/media_encrypted、media_and_backups/backups）を作成し、バックアップから復元します。 nr_encrypted[データをに移動しmedia_and_backups、8TBパーティションのファイルシステムを削除し、そこに新しいプールを作成し、nr_encryptedそこにデータセットを復元するオプションもあります。]
しかし、上で述べたように、よくわからない部分がバックアップと復元の進行状況です。
- 私が考えることができる簡単な方法の1つは、rsyncを使用し、各データセットのフォルダを作成し、すべてのデータを同期し、目的のプールとデータセットを作成し、そのデータセットを再度rsyncすることです。
- 1つの明らかな欠点は、バックアップ時にデータが復号化され、復元時に再暗号化されることです。
- ただ感じ間違ったたとえば、転送中のデータ破損をどのように識別しますか？
zfs sendzfs receive行くべき道のようです。しかし…実際にはどうすればいいですか？- 私は答えを読んだZFSフルスナップショットの送受信しかし、私の設定と他の設定の間にはいくつかの主な違いがあります。
- 新しいサーバーに直接新しいプールを作成します。まず、バックアップを保存してから同じサーバーに復元したいと思います。
- 同じプールに保存したい3つの異なるプールの3つのデータセットがあります。
- 利用可能なストレージに関する質問もあります。 8TB（= 7.28TiB）は、3.26 + 1.93 + 1.07 = 6.26TiBの使用済みデータを保持するのに十分ですが、もちろん8TBプールは4 + 3 + 4TBに相当するデータセットをホストできません。
- 私は答えを読んだZFSフルスナップショットの送受信しかし、私の設定と他の設定の間にはいくつかの主な違いがあります。
- したがって、現在のデータセットを8TBプールの1つの大きなファイルに個別に保存する必要があると思います
zfs send（または何らかの方法でチャンクに分割）。完了したら、古いプールを破壊してzfs recvファイルをプールにコピーして新しいプールを作成する必要があります。
これが最善の方法ですか、それとも良い/推奨方法がありますか？またはzfs send/使用のベストプラクティスzfs receive。これを行うときに知っておくべきことはありますか？
答え1
だから、エラー修正が受信されたときに発生することがわかったので、中間ファイルを作成するのは良い考えではありません。
また、私のデータセットにボリュームサイズが設定されていないことを発見しました（を使用して確認zfs get volsize）。したがって、プールサイズではなく合計使用量サイズにのみ注意してください。
私もそこに行きました。 zfs プール全体を別の zfs プールに一方向にミラーリングする方法私が知っている限り-d（discard）オプションを使用して、zfs receiveファイルシステムパスが新しいプールに一致するようにすることができます。
また、データセットが暗号化されているため、対応する--rawフラグをオンにする必要がありますzfs send。データセットを復号化して再暗号化するのを防ぎたいからです。
最後に、異なるプール内の複数のデータセットがすべて同じターゲットプールに送信されるため、プールスナップショットではなくデータセットスナップショットのみを送信するように注意する必要があります。それ以外の場合は、プール内で競合するスナップショットのエラーが発生します。
全体として、私の転送コマンドは次のようになります。
zfs send -R --raw origin_pool/dataset@transfer_some_timestamp | pv -Wbraft | zfs receive -Fduv destination_pool
zfs send-Rすべてのプロパティ、スナップショットを保存するためのコピーストリームパッケージを作成します。--raw暗号化されたデータセットの場合、転送されたデータはディスクに存在するデータとまったく同じです。再暗号化防止
pv -Wbraftモニターの状態zfs receive- -F`ターゲットプール拡張
-dorigin_poolファイルシステム名の一部を捨ててdestination_pool使用してください。-uインストールしないでください-vストリームに関する詳細情報と受信操作を実行するのに必要な時間を印刷します。pv（振り返ってみると、おそらく-vオプションはすべて必要ありませんでした。しかし、まあ）
上記は一般的なポイントですが、完全性のために次の手順を実行しました。
tmux前提条件：実行中のプロセスを停止せずに簡単に切断できるように、オープンセッションを設定します。- 12Tドライブを4Tおよび8Tにフォーマットします。 4Tパーティションのサイズは他の4Tドライブとまったく同じです（既存のパーティションテーブルの1つを表示するには、以下を
fdisk -l /dev/sdX使用してください）。 non_redundant_two8Tパーティションへのプールの作成- 最初のソースプールで再帰的スナップショットを作成する
zfs snap -r drei_t_pool@transfer_$(date '+%Y%m%d%H%M%S') non_redundantプールに行く：（zfs send -R --raw drei_t_pool@transfer_20231210194637| pv -Wbraft | zfs receive -Fduv non_redundant_two理想的ではありません。下記参照）- Next ソースプールのスナップショットの作成
zfs snap -r media_pool@transfer_$(date '+%Y%m%d%H%M%S') - 転送しようとしましたが、エラーが発生してスナップショット（
zfs list -t snapshot）を確認したところ、プールには非常に小さなスナップショットがあり、データセットには大きなスナップショットがあることがわかりました。プールスナップショットを削除します。zfs destroy non_redundant_two@transfer_20231210194637 - また、「保有者」データセットを作成し、完全なフルスナップショットをここに送信することを検討してみました。
zfs create non_redundant_two/media_holderzfs send -R --raw media_pool@transfer_20231210232518 | pv -Wbraft | zfs receive -Fduv non_redundant_two/media _holder- この方法も効果があるようですが、より良いアイデアがあったので、試みをキャンセルして中断しました。
- データセットのみを送信する：
zfs send -R --raw media_pool/media_encrypted@transfer_20231210232518 | pv -Wbraft | zfs receive -Fduv non_redundant_two - 最後のプール/データセットに対して同じことを行い
zfs snap -r non_redundant@transfer_$(date '+%Y%m%d%H%M%S')、zfs send -R --raw non_redundant/nr_encrypted@transfer_20231211121954 | pv -Wbraft | zfs receive -Fduv non_redundant_two - バックアップされたデータセットを開き、ファイルを読み取ることができるかどうかをテストします（すべてのプールに対してこれを行います）。
zfs load-key non_redundant_two/backups- 調べる...
- キーを取り外して削除します
zfs unmount -a。zfs unload-key non_redundant/nr_encrypted
- プールを削除する前に、プールの属性をバックアップしてください。
pool get all drei_t_pool > zfs.get.drei_t_pool - 元のスナップショット、データセット、プールを削除します。 （再帰フラグを使用してこれを実行できることを知っていますが、実行中の作業を確実に確認したいと思います。）（すべてのソースプールについて）
zfs destroy drei_t_pool@transfer_20231210194637、zfs destroy drei_t_pool/backups@transfer_20231210194637zfs destroy drei_t_pool/backupszpool destroy drei_t_pool
- 移行する新しいプールの作成
media_and_backups - そこにデータセットを送信します（データが変更されていないため、スナップショットを再作成する必要はありません）。
zfs send -R --raw non_redundant_two/backups@transfer_20231210194637 | pv -Wbraft | zfs receive -Fduv media_and_backupszfs send -R --raw non_redundant_two/media_encrypted@transfer_20231210232518 | pv -Wbraft | zfs receive -Fduv media_and_backups
- 復号化とインストールが期待どおりに機能していることを確認し、データセットを削除します。
non_redundant_two - 転送スナップショットを破棄
もう一つの疑問：NFSが機能しなかったので、zfs get sharenfs pool_name/dataset_name私が設定したデフォルト設定がどこに表示されるのかを確認しましたが、SOURCEタブが表示されましたremote。そのため、プロパティをリセットした後にタブが表示され、SOURCENFSlocalが再び機能しました。