データを失うことなくLVM / EXT4をZFSに変換

2 x 3TBドライブを搭載したホームメディアサーバーがあります。現在mdraid（1）、LVMおよびEXT4を使用して設定されています。セットアップはncurses Ubuntuサーバインストーラを使って行われました。

ゴール

セットアップをZFS（RAIDZ）を使用するように変換し、3台目の3TBドライブを追加します。オンザフライでの圧縮と重複排除を有効にしたいです。変換はUbuntuとすべてのパッケージの再インストールを必要とするべきではありません。データの損失があってはいけません（もちろんディスクがクラッシュしない限り）。

どうやってこれをやるの？

ボーナスの質問ですが、これはbtrfsを使用したほうがよいのですが、1つのディスクでアレイを初期化し、データをコピーしてから2つ目のディスクをztrfsではなくbtrfsで追加できます。

私の/ proc / mdstat：

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md4 : active raid1 sdb2[1] sda2[0]
      2930070069 blocks super 1.2 [2/2] [UU]

unused devices: <none>

私のPV - V

    Scanning for physical volume names
  PV         VG   Fmt  Attr PSize PFree DevSize PV UUID
  /dev/md4   Data lvm2 a-   2,73t    0    2,73t MlZlTJ-UWGx-lNes-FJap-eEJh-MNIP-XekvvS

私のlvs -a -o +デバイス

  LV     VG   Attr   LSize  Origin Snap%  Move Log Copy%  Convert Devices
  Data   Data -wi-ao  2,68t                                       /dev/md4(13850)
  Swap   Data -wi-ao  7,54g                                       /dev/md4(11920)
  Ubuntu Data -wi-ao 46,56g                                       /dev/md4(0)

ショート：

• ext4からZFSへのインプレース変換はないと思います。

• メディアサーバーのために私はお勧めします SnapRAID 代わりに

より長いです：

ZFSは非常にユニークで非常に特殊な内部構造を使用していますが、これはext4の構造にはあまり適していません。 （読む：おそらく誰かがext4の上に人工的なZFS構造を作成することができるでしょうが、この変換が速く、信頼性があり、使いやすいとは思いません）

SnapRAIDは、あなたが何かを変換する必要はありません。ドライブの障害や（サイレントな）破損が発生した場合にファイルをチェックして回復できるように、（ほぼ）既存のファイルシステムと併用するだけで、そこにあるファイルの冗長性を確保できます。

長所短所：

• SnapRAIDは、多くの小さなファイルに対して冗長性を作成する必要がある場合は非効率的です。 各ファイルがパリティに一定のオーバーヘッド（パディング）を作成するため。

• SnapRAID自体は圧縮機能を提供しません。
  メディアサーバーでは、通常メディアが圧縮されるので、通常は圧縮は必要ありません。 すでに圧縮されています（MP4、JPG、PDF）。
  たまたま圧縮が可能なファイルシステムを使っているのなら、それを使うことができます。 しかし、ZFSのように完全なプールではなく、デバイスレベルでのみです。

• SnapRAIDはブロックレベルでの重複排除を提供しません。
  メディアサーバーで snapraid dup 機能は通常十分です、 メディアファイルは通常、たくさんの重複ブロックを共有しません。 （例外： youtube-dl。同じ品質でビデオを2回ダウンロードすると、 それは数バイトだけ異なります。常にではない。しかし、かなり頻繁に。 YouTubeのビデオIDをファイル名に入れて、2つの類似ファイルを識別するだけです。）

• ZFS重複排除には多くのメモリが必要です。 1 TiBデータあたり1 GiBのRAMを計画してください。
  十分なRAMがない場合は、超高速SSDキャッシュデバイスを追加する必要があります。 ZFSは書き込まれた重複排除ブロックごとに1つのランダムセクタを検索する必要があるため、 "only"を使用 SSDで40 kIOP /秒の場合は、実効書き込み速度を約100 MB /秒に制限します。 （通常、ZFSはすべてのデバイスの並列帯域幅を利用できます。 そのため、コンシューマハードウェアで1 GB /秒以上の書き込み速度を簡単に達成できます。 ただし、重複排除を有効にして大量のRAMが搭載されていない場合はその限りではありません。）

• SnapRAIDがデータを回復するために必要とされるところで私は問題を抱えていなかったことに注意してください。
  だからSnapRAIDが本当にデータを回復することができることを誓うことはできません。 しかし、SnapRAIDが確実に役立つように、すでに十分な問題がありました。 データが正しいこと、そして私が印象を受けたこと、SnapRAIDは本当にうまくいっている。

• ZFSでは、前もって計画を立てる必要があります。あなたはのあらゆる側面を知り、計画する必要があります。 ZFSを始める前に、ZFSドライブのライフサイクル全体を事前に確認してください。
  あなたがこれを行うことができれば、ZFSより良い解決策はありません、私を信じて！
  しかし、もしあなたが将来計画外のことで起こることを忘れた場合、 あなたは運命にあります。それからZFSで最初からやり直す必要があります。
  新しい2番目の新しく独立したZFSプールを作成し、そこにすべてのデータを転送します。
  ZFSはそうすることであなたをサポートします。しかし、あなたはデータを複製することを回避することはできません。 一時的にZFSを導入するときに必要なものです。

• ZFSを管理するのは簡単です。あなたが定期的にする必要がある唯一のことは：
  zpool scrub
  それで全部です。それから zpool status あなたの悩みを解決する方法を教えてくれます。
  （今から10年以上前のZFS。Linuxの場合。簡単に言うと、ZFSは命の恩人です。）

• SnapRAIDのOTOH、あなたは計画を立てる必要はありません。ちょうどそれのために行きなさい。 そして、必要に応じて構造を変更してください。
  そのため、SnapRAIDから始めるためにデータをコピーする必要はありません。 パリティドライブを追加して設定してください。

• しかしSnapRAIDはあなたが問題を抱えている場合には管理がはるかに困難です。
  使い方を学ばなければなりません snapraid sync、 snapraid scrub、 snapraid check そして snapraid fix。 snapraid status ほとんどの場合は助けになりますが、戸惑うことが多いので、 明らかなものはないので、何かを修正する正しい方法は何か 1つの最良の方法（SnapRAIDはスイスアーミーナイフのようなものです あなた自身、それを正しく正しく扱う方法）。

• Linuxでは、ZFSには2つの異なる選択肢があります。

  • ZFSonLinux、これはカーネル拡張です。
    Ubuntu 20.04で表示される新しいカーネルはおそらく互換性がないでしょう。
  • 通常少し遅いZFS-FUSEは、カーネルから独立しています。
  • どちらにも長所と短所があり、これはこの回答の範囲を超えています。
  • ZFSが利用できない場合（おそらく何かを修復する必要があります）、 あなたのすべてのデータにアクセスできない。
  • 使用している冗長性に応じて、デバイスに障害がある場合は、 すべてのデータが完全にアクセス可能か、またはすべてのデータが完全に失われます。

• SnapRAIDはGPLv3であり、完全にユーザースペースへのアドオンです。

  • SnapRAIDが利用できない場合でも、すべてのデータはそのまま残り、アクセス可能になります。
  • デバイスに障害が発生した場合でも、他のデバイス上のすべてのデータはそのままでアクセス可能です。

一般に、メディアサーバーは古いデータを長期間保存するという特性を持ち、成長し続けています。これはまさに、SnapRAIDが設計されたものです。

• Snapraidは後で新しいドライブあるいは新しいパリティさえ追加することを可能にします。

• すべてのドライブに異なるファイルシステムを混在させることができます。 SnapRAIDは冗長性を追加するだけです。

• SnapRAIDはバックアップを意味しません。
  メディアアーカイブでは、バックアップをまったく必要としないことがよくあります。

• ZFS RAIDZもバックアップを意味しません。
  しかしながら zfs send と組み合わせて zfs snapshot いくつか提供しています 24時間365日のオンザフライバックアップおよび復元機能を使用するのは非常に簡単。

• ZFSはファイルシステムを対象としています。 ダウンタイムほとんどすべてを停止時間なしでオンザフライで修正できます。
  ダウンタイムは、ZFSの冗長性/自己修復がこれ以上ない場合にのみ発生します 損傷を修理することができる。それでも、ZFSは役に立ちます。 失われたデータすべてを一覧表示します。通常。

• OTOH SnapRAIDはデータを回復できますが、これはオフラインで行われます。
  だから回復するまで、データは利用できません。
  どのデータが失われたのかを調べることも役立ちます。しかしこれはもっと難しい、 ZFSよりも。

SnapRAIDを使用したベストプラクティスの推奨事項（ZFSはこの回答を超えています）：

• LVMを使い続けましょう。
  • 各ドライブをフルPVにします。パーティションテーブルはありません。
    ドライブを暗号化したい場合は、PVをLUKSコンテナの中に入れます。
  • そのような各PVをそれ自身のVGに入れてください。 このようにして、故障したドライブが他のVGに害を及ぼすことはありません。
    いくつかの小さいドライブを同じサイズにまとめることができます
  • それらすべてのVGに同じサイズのLVをたくさん作成します。
  • データドライブよりも大きいParityドライブの束を作成します。
  • スナップショットを作成するためにVGに十分なスペース（100GB）を残してください。 そしてファイルシステムのわずかな調整。
  • 各PVの最後には、空きスペースがあるはずです（上記の十分なスペースを参照）。
    これは、最後にスーパーブロックコピーを作成する最近のファイルシステム用です。 あなたがPVを完全に満たすならば、それらのFS（ZFS）はドライブ全体を検出するかもしれません またはLVの代わりにPV。
• それらのLVにデータドライブ用に選択したFSを作成します。
• LVのパリティドライブにZFSを使用します。ここでは圧縮/重複排除は必要ありません。
  ZFSは通常FSをその中に作成するので、これは完全ではないことに注意してください。 /。

SnapRAIDを設定および管理する方法は、この回答の範囲を超えています。

なぜパリティをZFSにするのか

まあ、データドライブが悪くなったとき（読めないセクター）、読めるファイルをコピーすることができます。読めないファイルはこの方法で簡単に見つかります。あなたはそれを回復することができます。

しかし、SnapRAIDパリティは1つの大きなファイルです。このファイルをコピーすると、 確かに、それは静かな腐敗を持っていません。 ZFSはこれを独立して保証します SnapRAID破損がある場合には、ZFSはあなたにその旨を伝えます。 パリティファイルを確認する必要があります。

すべてのドライブのすべてのデータを完全に読み込む必要があるため、欠陥セクタがいくつかある場合にファイル全体をチェックするのは時間がかかります。

なぜBTRFSではないのですか？

• ZFSはすでに何年もの間、完全に安定しており、静かで完璧です。
• OTOHは2019年であり、BTRFSには依然として深刻な問題が多発しています。
• 例えば、BTRFSはあなたがそれを完全に満たすならば予測不可能で不安定なものに反応します、 あなたがそれを完全に埋めることができるならば。対照的に、ZFSではそのような問題は知られていません。
• 気を付けていないと、時々完全に一致する可能性があります。 （SnapRAIDは、たくさんの小さなファイルをパリティに入れる必要がある場合は少し非効率的です。）