ZFSのおかげでデータ損失はわずか10分分に

 (mastodon.social)
3 ポイント 投稿者 GN⁺ 2023-08-24 | 1件のコメント | WhatsAppで共有
  • 2年使ったSSDが突然故障したが、ZFSの増分レプリケーションで新しいドライブにシステムを復元でき、実際の損失は約10分分にとどまった
  • ファイルシステム全体を10分ごとにスナップショットとして取得し、NASへ送る構成で、自動化にはzreplを使用
  • スナップショットは稼働中システムの特定時点の状態を保存し、変更分だけを転送するため、家庭内ネットワークでもバックグラウンドでレプリケーションが可能だった
  • 復元では625GiBのZFS receiveを一晩かけて実行し、暗号化のwrapper keyまで復元する必要があり、自動復旧とはほど遠かった
  • ZFSは初期導入と保守の負担が大きいが、実際のドライブ故障時に作業状態まで復元できる災害復旧効果を示した

SSD故障後に残った損失は10分

  • ノートPCを開いてメールを送ろうとした瞬間、画面が黒いまま固まっており、再起動後に2年使ったSSDが故障していることが確認された
  • 新しいドライブにシステムを復元した後、再び使えるようになり、全体のデータ損失は約10分分にとどまった
  • 復旧したノートPCは中断した地点から起動し、ブラウザのタブも前夜の未完了作業を復元した
  • 12年前のChromebook広告のように、新しいデバイスで以前の状態を引き継ぐという構想が、今回の故障状況で実際に機能した

バックアップというよりレプリケーションに近い構成

  • 単にドライブをバックアップするのではなく、ファイルシステム全体のレプリケーション方式を使った
  • 昨冬、創作作業用コンピュータの定期バックアップのためにホームネットワークストレージを構築し、複数の選択肢の中からZFSの増分レプリケーションを選んだ
  • ZFSは稼働中のシステムでも、特定時点のスナップショットを効率よく作成できる
  • その後、別のマシンへ送る際には全データを繰り返し転送せず、変更されたデータだけを転送する

zreplで10分ごとにNASへ転送

  • スナップショット作成とNASへの転送の自動化にはzreplを使った
  • 設定は、ファイルシステム全体を10分ごとにスナップショットとして取得し転送する方式
  • 増分スナップショットのおかげで、家庭内ネットワーク上でバックグラウンド実行してもレプリカを最新の状態に保てた
  • 最後の実行では転送に14秒かかり、約64MiBを送信した

復元過程で見えた手作業の負担

  • システム復元は学習を要するプロセスであり、かなりの部分を手作業に依存した
  • 625GiBのZFS receive処理は一晩実行する必要があった
  • スナップショットは元のコンピュータ側で暗号化された状態だったため、NASは内容を読めなかった
  • バックアップを実際に使うには、暗号化のwrapper keyも復元する必要があった
  • データを復号できると初めて確認できるまで、復元作業は非常に不安だった

導入コストとハードウェア交換

  • ZFSの初期設定にはファイルシステム全体の置き換えが必要で、開始コストが高かった
  • 保守には関連知識が多く必要で、手作業を含む運用手順も伴う
  • それでもSSDが初めて故障する前にレプリケーションを設定しておけたのは幸運で、今回の事例ではZFSの利点が明らかになった
  • 故障したドライブは、もともとFrameworkの注文に含まれていたWD_BLACK SN850だった
    • Frameworkフォーラムで、このドライブが突然故障したり起動不能になったりするという不安な事例を見たことがあった
  • 同じ日にAmazonでSK Hynix P41 SSDとSabrent NVMe enclosureを約3時間で受け取った

関連記事

1件のコメント

 
GN⁺ 2023-08-24
Hacker Newsのコメント

  • ZFSを使っているので、他のWDやSanDisk SSDユーザーよりは備えができていたと言える
    https://petapixel.com/2023/08/08/sandisk-portable-ssds-are-failing-so-frequently-we-can-no-longer-recommend-them/
    https://www.theverge.com/22291828/sandisk-extreme-pro-portable-my-passport-failure-continued
    https://news.ycombinator.com/item?id=37042587
    https://www.theverge.com/23837513/western-digital-sandisk-ssd-corrupted-deleted-questions
    https://news.ycombinator.com/item?id=37188736

  • Linuxの世界を完全に離れる直前に、btrfsという氷山を少しずつ掘り下げ始めたのだけど、かなり興味深かった
    バックアップの革新やディスク構成など、いろいろな機能に大きな可能性がありそうに見えた。btrfsはZFSではないが、機能的に重なる部分があり、「貧者のZFS」に近いところもある。またZFSはライセンス、パッケージング、カーネル内への取り込み状況がやや微妙なので、特定のOSではbtrfsのほうがずっと理にかなって動く
    Linux User Groupで、コンピュータを再起動するために電源コードを抜かなければならなかったと言ったら、その愚かな行為でひどく叱られ、ZFSを使うよう勧められたことがある。ただ、そのシステムがRaspberry Piだったことを考えると、どちらの行動が賢明だったかについては見方が変わるかもしれない

    • Piはファイルシステム破損が起きる可能性があるとは言われるが、イメージを入れるたびにtmpfsをあちこちにマウントし、ほとんど役に立たないログをオフにするスクリプトを走らせているので、自分では見たことがない
      SDカードを酷使しない限り、こうした機器は非常に安定して動き続ける。ZFSは本当に素晴らしく見えるが、いつかNASを買うとしても、ZFSを動かせる機器にお金を使いたいとは思わなさそうなので、結局RAIDとext4を使うことになりそう
      btrfsは数か月ごとに「BTRFSにデータを飛ばされた」という投稿を見て、それがbtrfsのせいなのか議論が続くのを見てきたので、ずっと避けていた。最近はそういう投稿をあまり見ない気がするので、また見直す時期なのかもしれない
    • 気になって聞きたいのだけど、Linuxの世界を完全に離れるきっかけは何だったの？「コミュニティ」が他の人たちにとってより良くなるには、その経験から何を学べるだろう？
    • btrfsで本当に気に入らない唯一の点は、断片化が起きやすいこと
      特にスパースなVMイメージでそうで、その用途にはzvolのほうがずっと向いていると思う

  • 数年前にはコンデンサ騒動があったが、今度はストレージ騒動を経験しているのかと思ってしまう
    あらゆるストレージがどんどん悪くなっているのは馬鹿げている。WDはSMRでHDDを台無しにしているし、メーカーはSSDやHDDの3年稼働がすでに長すぎると言っているが、これは冗談ではない。今年だけでもKingstonのSSDが1台死んだし、それは8年くらい経っていたので仕方ないとしても、ポータブルWD HDDも約2年で死んだ
    最近のインターネットはデータ損失と寿命の問題であふれている。20年前のHDDも永遠に使えるものではなかったが、少なくとも一緒に買ったコンピュータの実用寿命よりは確実に長持ちした記憶がある

    • 最近のハードディスクは20年前よりずっと運が良かった
      20年前は、磁性コーティングがプラッタから文字どおり剥がれ落ちることで悪名高いIBM Deathstarドライブの時代だった。1〜2年で死ぬひどいMaxtorドライブもあったし、SeagateがMaxtorを買収した後、しばらくSeagateのドライブも不安定になった。ディスクを8台ほど積んだサーバを運用していて、年に1台くらいのペースで交換し続けなければならなかった
      一方で今は、20台超のドライブを持つZFSサーバの管理を手伝っているが、ドライブ寿命はだいたい4〜5年くらい。また当時のコンピュータはずっと早く陳腐化した。今なら6年前のコンピュータでも十分使えるが、当時は3年前のコンピュータでもかなり体感差があった
    • 心配しなくていい。じきにチップも数年経つと誤動作し始めるはず
      スケーリングの限界にぶつかっていて、指数関数的な成長は鈍化している
    • 個人的には、昔も自分や周囲の人たちのHDDがときどき故障していた記憶がある
      今はSSDでそういうことはほとんどない。問題が多いことで知られる2000年代後半の古いIntel SSDでさえ、私が数年使ってから母に譲った同じ古いMacBookの中で、まだ問題なく動いている。実データがどうなっているのかは気になる
    • 過去10年で買ったWDドライブは、どれも期待どおりに動作した。SMR導入後に買ったNAS用も含まれるが、単なるRedではなくPlusかProであることを確認したからだ
      SSDも運が良かったが、デスクトップでは今でも/homeディレクトリとRAIDアレイを古い回転式ドライブに置くことが多いので、小さなSSDしか使っていない
      例外は2つあった。SMR以前のWD Redを2台、より大きなディスクに交換するため古いNASから取り外し、完全に正常な状態で静電防止袋に入れて引き出しに保管した。約2.5年後に予備ディスクが必要になって取り出して確認したところ、どちらも動作せず、1台は完全に死んでいて、もう1台はかろうじて認識されるだけで読めなかった。1台目は接続してもまったく現れず、コントローラPCBのピンを含めてすべての接点を掃除してみたが無駄で、結局捨てた。2台目は全体を再フォーマットしてようやく再利用できたが、testdiskを使っても以前のデータを復旧する方法はなかった。こんなことは経験したことも予想したこともなかったので、正直かなり不安だ
    • 約20年前にも**HGST “Deathstar”**があり、集団訴訟にまでなったほどひどいドライブだった
      ディスクはいつもランダムに死んでいたし、SunがZFSを作った理由の1つもそれだった

  • ごく短くまとめると、Mastodonのスレッドはhttps://zrepl.github.ioを指している
    「zreplはZFSレプリケーションのための統合されたワンストップソリューション」だ

    • zreplがGoで書かれていて、sanoid/syncoidがPerlスクリプトだという点以外に、zreplとsanoid/syncoidがどう違うのか知っている人はいる？
    • ストレージサーバで動くデーモンと通信する必要があるように見える
      たとえばS3をストレージとして直接使えたら良さそう

  • Zreplは、私がデジタルノマド生活を安心して送れる大きな理由だ
    毎晩だいたい1回実行されるスクリプトが、別ヘッダーを持つLUKS保護ZFSプールを開き、すべてのスナップショットをコピーする。そのNVMEエンクロージャは常に身から離さない「バッグ」の中にある
    この構成とNixOSのおかげで、同一の新しいノートPCを約10分でプロビジョニングできる。最近はオフサイト複製も追加したので、完全にひどい強盗に遭ったとしても、深刻なデータ損失の可能性はほぼ0に近い
    Zreplは本当に素晴らしいソフトウェアだ。始めるのは簡単だが、必要ならすべての調整ポイントを触れるほど精巧で強力。いくら褒めても足りない

    • 盗難、火災、洪水、その他の災害が一度起きれば終わりという大半の人より、ずっと安全そうだ
    • sanoid/syncoidを使ったことはある？ それらに比べてZreplは何を追加で提供してくれるの？
    • この構成がどう動いているのか記事にしてくれるとうれしい。かなり興味深く聞こえる

  • ファイルシステムを10分ごとにスナップショットしていたことが、SSDの故障に影響した可能性はあるだろうか？

    • ZFSは特殊で、コピーオンライトを使うためスナップショット作成のコストは低い
      直感的には、かなり頻繁にスナップショットを取っても追加の書き込み量はかなり少なそうに思える。それでも科学的な測定があるとよい
      以前管理していた一部のサーバーでは、ZFSで毎分、毎時、毎日スナップショットを取っていた。分単位のスナップショットは60分後に削除し、別のマシンのcronジョブで時間別・日別スナップショットをバックアップしていた。時間別スナップショットはおおむね72時間保持し、日別スナップショットは永久保存するようにしていた。分単位のスナップショットはSQLマイグレーション中の手作業ミスを戻すためのもので、うまく機能していた
      今もFreeBSDサーバーでZFSを使っているが、現在のプロジェクトはトラフィックが少なく、重要なデータ変更もまれなので、個人サーバーではだいたい週1回手動でスナップショットを取り、別のサーバーからバックアップを手動でトリガーしている。また今ではPostgreSQLデータベースとアプリケーションデータがあるファイルシステム部分だけをスナップショットしている。OSデータはもはやあまり気にしていない。深刻なハードウェア故障が起きたらOSを新規インストールし、重要な設定値は記録しておき、バックアップスクリプトが実行されるときに他の雑多なものではなくその値をコピーするようにしている
    • その可能性は低い
      スナップショットはそれほど多く書き込まず、SSDもZFSもどちらもコピーオンライト方式だ。つまりスナップショット後の書き込みコストはスナップショット前と同じになる
      ただし文脈が欠けている。SSDもZFSも、満杯またはほぼ満杯の状態を好まない。作業データが約650GBでドライブが1TBだったなら、スナップショットのせいでドライブ使用量が簡単に90%を超えていた可能性がある。それ自体だけでもZFSにとって苦しい状態になっていた可能性がある
    • 私の理解では、ZFSでスナップショットを取るというのは、メタデータオブジェクトと一部のデータ参照を書き込むことだ
      データ100GB、128Kブロックサイズ、64ビットポインタと仮定すると、スナップショット中に新しく書かれるデータはおおよそ5MB程度だと思う。これを1時間に6回、年間52,560回行うとして、ドライブを早期に摩耗させるほどかを考えると、年間約256GBになる。これはSSDの書き込み耐久性の1%未満である可能性が高い。だから10分単位のスナップショットが重要な原因なら驚くと思う
      間違っているかもしれないし、あまり信頼できない出典に助けを求めて見積もったものだ。訂正は歓迎する。それでも私の見積もりが実際より高く、にもかかわらず寿命に影響する可能性が低いなら、論点自体にあまり意味はないかもしれない
    • 可能性は低い。スナップショットは、おおまかには直近に記録されたブロックをマークし、以前のブロックが変更されないようにするものだ
      ZFSはコピーオンライトなので、ファイル変更では同じ書き込みが発生し、一部の既存データが削除されないだけだ
    • あるランダムなオレンジ色のウェブサイトのコメント[1]によると、最新のフラッシュチップの最小書き込みサイズは約100MBかもしれない
      すると10分ごとの5MB書き込みが、実際には1時間あたり600MB、8時間の勤務日で4.8TB、週40時間で24TBになり、1TBドライブでは実時間で3.43 DWPD、2年の実時間では2500TBWになる[2]
      SN850の公称書き込み耐久性は600TBWだが、保証の問題があるので当然かなり保守的に低く見積もった値である可能性が高い。偶然にも2500TBは、この市場の多くのSSDで一般的な耐久性の数値でもある。全体として見ると、完全にあり得ない話ではないように聞こえる
      まだ生きているなら、コントローラーがSMARTデータで何と言っているのか気になる。Linuxでは apt install smartmontools; smartctl -s on /dev/sda; smartctl -A /dev/sda を実行すれば表が出力されるはずだ[4]。WindowsではCrystalDiskInfo[3]をインストールすればよい
      1: https://news.ycombinator.com/item?id=29165202
      2: DWPD: drive writes per day, TBW: Total Bytes Written - in terabytes
      3: https://crystalmark.info/en/software/crystaldiskinfo/
      4: “Pre-fail”は故障直前に値が変わるべきという意味で、“Old_age”は寿命を表す値という意味であって、「これは悪く、まもなく故障する」や「このドライブは古い」という意味ではない。常にすべての項目にPre-failとOld_ageが表示される。ずっと昔に誰かが“somewhat_boolean”と“life_remain”に変えるべきだったと思う

  • 私は普段、Apple Time Machineの増分バックアップをSynologyの回転ディスクサーバーに取っている
    危険な作業をしたりマシンをアップグレードしたりするときは、外付けSSDに内蔵ドライブをミラーリングすることもある。この方法はうまく機能する。Time Machineの復元はかなり遅いことがあるが、重要なデータの大半はGitとホスティングされたリポジトリにあるので大きな問題ではなかった。単一ファイルを戻したいときに、ときどきTime Machineを使う
    悪名高い[0] SanDiskドライブも1台持っているが、重要な用途には使っていない。ゲームの保存領域が入っている程度だ。Macユーザーなのでゲームは大きな要素ではなく、それらが死んでも泣くことはないだろう
    [0] https://arstechnica.com/gadgets/2023/08/sandisk-extreme-ssds-are-worthless-multiple-lawsuits-against-wd-say/

    • 私もTime Machineを使っている。https://tclementdev.com/timemachineeditor/ のアプリを入れて、マシンがアイドル状態になるたびに手動でTMバックアップをトリガーするようにした
      Appleの自動バックアップや時間ベースのバックアップより、ずっとうまく動いているように思う
    • 私はTime Machineを諦めた。Synologyでatalkなどを使っても、1〜2か月以上まともに動いたことはほとんどなかった

  • 私のスナップショットは元のコンピューター上で暗号化されている。NAS には読めないという点が素晴らしい
    そのためバックアップを使うには、暗号化の wrapper key も復元する必要があった。正直、データを復号できるという最初の確認が取れるまではかなり怖かった
    カスタムのバックアップ方式は、実際に定期的にデータを復元できることを確認するまでは、動作していると考えるべきではない

    • カスタムではないバックアップでも同じ
    • 万一に備えて LUKS ヘッダー のコピーを別ディスクに保管しておくべきだと、ずっと思っていただけだった

  • ここで Linux の近い将来にあるのは bcachefs だ
    https://bcachefs.org/

    • bcachefs は BTRFS や ZFS より何が優れているの？
    • 近い将来と言うには、すでに 7 年も開発中で、まだアップストリームに取り込まれていない
      アップストリームへの反映作業は進行中ではある
    • なぜ期待すべきなのか、短い要約はある？ 何かすごい機能でもあるの？

  • 「データを復号できるという最初の確認が取れるまではかなり怖かった」というのは、手順が最適な状態よりもテスト不足で、文書化も不足していたという意味に聞こえる
    家庭用システムや個人デスクトップでは、それほど珍しいことではない。それでも本番サーバーでは、復元手順をその場で即興で解明したくはないはずだ

    • その通り。復元に必要な材料はすべてあると分かっていたし、6 か月前に一度テストもしていたが、最初は 間違ったキー をコピーしていた
      読み込みに失敗したときは一瞬暗澹たる気持ちになったが、すぐに自分のミスに気づいた。こういう失敗の瞬間には、すべてのプロセスの隙間がまぶしいほどはっきり見えるような明晰さが訪れる