zfsクリーンアップがバックアップストアの破損を検出しない - なぜですか?

zfsクリーンアップがバックアップストアの破損を検出しない - なぜですか?

いくつかの背景:

2つのRAID0アレイ(各DRBDクラスタの前のノード)に構築されたLVM論理ボリューム上に構築された単一のマスターDRBDデバイスに、VMイメージ、ホームディレクトリ、メール、およびメディアコレクションを保存します。 RAID0はアクセス時間を改善することです。 DBRD クラスターの 2 つのノードは冗長性を提供します。私は毎週自宅と電子メールをバックアップし、VMオペレーティングシステムとメディアコレクションを毎週オフサイトにバックアップします。時々ダウンタイムが発生しますが、回復は常に単純であり、データの損失はありません。調停を提供するために、第3のノードの複雑さは必要ない。この設定は長い間うまくいきました。

しかし、私が扱っていない領域の1つがビットロットであることを知っています。 10年間見ていない映画を見続けることができるかどうかはどうすればわかりますか?破損したデータをバックアップしていないかどうかはどうすればわかりますか?

したがって、すべてのファイルのチェックサムを保存し、それを最後の実行と比較して違いを報告するスクリプトがあります。明らかに同じことをするには、オペレーティングシステムが提供するいくつかのツールを使用する方が良いでしょう。最初に登場するのはBtrfsとZFSです。私のGoogle検索によると、Btrfsはこの分野では未熟ですが、ZFSは未成熟です。また、私はZFSに慣れているので、ZFSが私が好む解決策です。

以下は私が答えたい主な質問です。 ZFSはバックアップストレージの破損を検出できますか?

周囲に余分な物理マシンがないため、独自の「ディスク」に割り当てられていないスペースを持つ仮想マシンを使用して物理ディスクをエミュレートする論理ボリュームを作成し、それをZFSに供給してzvolを作成する予定です。 、任意のデータが論理ボリュームに書き込まれ、確認されます。

  1. zvolコンテンツのチェックサムが何らかの理由で失敗したか(ZFSがzvolをオフラインにする可能性がある)、チェックサムが変更されました。
  2. ZFSは破損したバックアップストアにフラグを立てます。おそらく整理する場合にのみ可能です。

このテストがうまくいかないことを考えると(詳細は以下を参照)、私の実験や期待にすでに欠陥があるのでしょうか?

とにかく、私がしたことは次のとおりです。

ボリュームグループに十分なスペースがあるため、ZFSのバックアップストアとして使用するLVを作成できます。

penne# vgs
  VG  #PV #LV #SN Attr   VSize   VFree 
  vg0   1   3   0 wz--n- <40.46g <6.46g
penne# lvcreate --name=lvtest --size=1g vg0
  Logical volume "lvtest" created.
penne# 

LV を新しい ZFS プールに割り当て、ここで zvol を作成します。

penne# zpool create zpooltest /dev/vg0/lvtest 
penne# zfs create -V 800M zpooltest/zvoltest
penne#

言い換えれば、バックアップストレージの「ZFSの背後」の途中で1MBの破損を記録したはずです。裏店はどれくらい大きいですか?

penne# dd if=/dev/vg0/lvtest of=/dev/null bs=1M 
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.24444 s, 331 MB/s
penne# 

したがって、その間には約500000000バイトがあります。

zvolのチェックサムは私が興味を持っている部分です。 raidzを使用している場合、ZFSは破損を処理する可能性があるため、破損がチェックサムに影響を与えないようにしたいが、単一のディスクバックアップストアを使用するときは、ディスクエラーを報告するためにチェックサムを変更してクリーンアップしたいと思います。だからまずzvolのチェックサムを見てみましょう。

penne# dd if=/dev/zvol/zpooltest/zvoltest bs=1M 2>/dev/null | md5sum
ebbcd350dfe34f526c0d80b3bf2d07dd  -
penne# 

これで、バックアップストアの中間1MBが破損しています。

penne# dd if=/dev/urandom of=/dev/vg0/lvtest seek=500000000 bs=1 count=1000000 conv=notrunc
1000000+0 records in
1000000+0 records out
1000000 bytes (1.0 MB, 977 KiB) copied, 1.27545 s, 784 kB/s
penne# 

そしてzvolのチェックサムをもう一度確認してください。

penne# dd if=/dev/zvol/zpooltest/zvoltest bs=1M 2>/dev/null | md5sum
ebbcd350dfe34f526c0d80b3bf2d07dd  -
penne# 

なぜ変わらなかったのですか?

zvolの内容が変更されていないようであることを考慮すると、スクラブが何もしないことは驚くべきことではありません。

penne# zpool scrub zpooltest
penne# zpool status
  pool: zpooltest
 state: ONLINE
  scan: scrub repaired 0B in 00:00:00 with 0 errors on Fri Mar 17 14:08:29 2023
config:

    NAME        STATE     READ WRITE CKSUM
    zpooltest   ONLINE       0     0     0
      lvtest    ONLINE       0     0     0

errors: No known data errors
penne# 

チャンクがどこにでもキャッシュされていることに気づいたので、再起動してすべてをフラッシュし、zvolのチェックサムを再確認しました。

penne# reboot
...
penne# dd if=/dev/zvol/zpooltest/zvoltest bs=1M 2>/dev/null | md5sum
ebbcd350dfe34f526c0d80b3bf2d07dd  -
penne# 

まだ同じです!なぜ?

繰り返しますが、zvolの内容が変更されていないように見える場合、他のスクラブが何もしないことは驚くべきことではありません。

penne# zpool scrub zpooltest
penne# zpool status
  pool: zpooltest
 state: ONLINE
  scan: scrub repaired 0B in 00:00:00 with 0 errors on Fri Mar 17 14:09:27 2023
config:

    NAME        STATE     READ WRITE CKSUM
    zpooltest   ONLINE       0     0     0
      lvtest    ONLINE       0     0     0

errors: No known data errors
penne# 

私は見たこれ破損が公開されたが検出されない理由は、破損がバックアップ ストアの先頭に非常に近いためです。ところで、私の場合は、バッキングストアの途中でスラブバンを使っています。

最後に、私が質問するのはこんな感じです。どうしたの?

オペレーティングシステムはDebian 11で、ZFSはOpenZFS 2.0.3です。

ありがとうございます!

アレクシス

ベストアンサー1

おすすめ記事