SSD、電源なしだとデータが消えるってマジ!?知られざるデータ劣化の真実
引用元：https://news.ycombinator.com/item?id=46038099
SSDのデータ保持期間は、書き込み/消去サイクルと温度に反比例するんだ。メーカーはDWPD/TBWの数字でごまかしてるけど、NANDフラッシュの性能は年々悪化してるよ。昔のSLCは10万サイクルで10年持ったのに、今のQLCは1000サイクル未満で数ヶ月しか持たないなんて、ひどい話だよね。
ドライブに「シャットダウン」コマンドがあればいいのにって思うよ。ECCデータを少し追加するだけで、1年しか持たない耐久性が100年に伸びるって言うんだからさ。そういう機能がないのが残念だね。
バックアップに冗長性を加えるプログラムはいろいろあるよ。例えばLinuxだとpar2cmdlineがある。僕はpaxアーカイブにして、圧縮、暗号化してからpar2createで冗長性を加えてるよ。大事なデータは2、3個のSSD、HDD、またはテープにコピーして、別々の場所に保管するのがベストだね。
残念ながら、一部のSSDコントローラーはデータが壊れてると、いくらパリティデータがあっても読み込もうとしないんだ。そうすると、ドライブ全体が使えなくなる可能性があるから困るよね。
ん？今話してるのはランダムブロックの故障じゃないの？ドライブ全体が壊れるのは、全く別の問題だよね。
そこが問題なんだよ。SSDコントローラーが、何らかの理由でブロックの読み込みを停止すると、もう手の施しようがないんだ。これがSSDによくある故障パターンで、一部のブロックが壊れるとドライブ全体が使えなくなるんだよ。僕の経験上も、他の人の話でもよくあることだから、思ってるより一般的だよ。
ちゃんと調べてないんだけどさ、なんでファイルシステムはこれ（冗長性）をやらないんだろう？ブートコードは仕方ないけど、他はどこかに繋げば簡単に直せるのにね。
誰もSLCにお金を払いたがらないからだよ。QLC NANDチップには「SLCモード」っていうのがあるんだけど、これを使えば書き込み速度も信頼性もすごく上がるんだ。でも、そうなると容量が4分の1になっちゃう。同じ値段で容量が減るなんて、誰も買わないよね？
特徴サイズが小さくなったんだから、耐久性が落ちるのは当然だよね。ロジックやDRAMメモリも一緒だよ。たぶん2035年頃には、2010年のハードウェアはまだ動いてるだろうけど、2020年のものは信頼性が低くなってるんじゃないかな。
4分の1の容量だけど、耐久性や保持力が100倍以上ならかなりお得だね。1TB QLC SSDが100ドル以下なのに、1TB SLC SSDが400ドル以下、または256GBが100ドル以下で買えないのはおかしい。メーカーが選ばせないのは、明らかに計画的陳腐化だよ。古いSLC USBドライブは512MBだけど20年近く経っても最初のファイルが無事だよ。数百回フル書き込みされてるのに、SLCにとってはまだ新品みたいなもんだ。非公式のファームウェアハックでSLCモードを有効にできるよ: https://news.ycombinator.com/item?id=40405578
はい、それで？ HDDのコントローラが壊れたり、ヘッドがクラッシュしたりするのもよくあることだよ。SSDがブリック状態になっても、RMAは簡単だけど、ブロックが破損するのは厄介だね。ブリック状態はRMAが簡単だから、メーカーも修理するインセンティブがあるんだ。だからバックアップは今も昔も重要ってことだね。
データ保持力は書き込み時の温度に比例するって読んだ記憶があるんだ。つまり、一番良いのはドライブが熱い時にデータを書き込んで、フリーザーで保存することらしい。誰かこれ、確認してくれると嬉しいな。
全く個人的な話で、ほとんど関係ないんだけど、1990年のNESはまだ元気だよ。持ってたPS3は2台とも壊れたね。1994年と2002年のCRTはまだ元気なのに、2012年と2022年のLCDテレビは理由もなく壊れたんだ。古いハードウェアって最高だね。
SSDコントローラが壊れる話をしてるんじゃないよ。ここで説明されてる仮想的な状況では、SSDコントローラは意図した通りに動いてるんだ。
理論的な最適化の話なのはわかるけど、SSDをフリーザーに入れるなよ。結露による水分の浸入が、室温でのNANDのビット腐敗よりずっと早くデータを破壊するからね。
ファイルシステムは、ECCデータを追加するために既存のECCデータに適切にアクセスできないから、その役割を果たすには丸ごと余分なコピーを保存する必要があるね。階層的なECCを使う方法もあるけど、理論的に最適からは程遠いし、ごく一部の論理ブロックが読めなくなった場合にしか頼れないだろうね。
コントローラがそう振る舞うべきじゃないって主張できるだろうけど、実際そうなんだ。バグでも、壊れたコントローラでもない。多くのエラーでドライブをブリック状態にするのは、ほとんどのユーザーが望むことじゃないよ。エンタープライズならそう望むかもだけど、それなら確実なデータ削除も望むはずだ。
コントローラがそう振る舞うべきじゃないって主張できるけど、それはバグじゃないし、壊れたコントローラでもないよ。完璧に機能しているコントローラが、故障したブロックに反応してるだけなんだ。
間違ったレイヤー（階層）の話だね。SSDはどのブロックに多く書き込まれたか、多くの読み取りエラーが出たかを知ってるし、SLCとMLCのように異なるストレージを持つこともあるんだ。ファイルシステムはストレージを平坦な線形配列として見るけど、SSDはその情報を使ってECCビットをより効率的に使えるよ。
参照元は？定義上、それは「機能的」という定義を満たしてないように見えるぜ。
CDストレージは面白い見解だぜ。使えるセクターサイズは用途によって変わるんだ。例えば、オーディオやMPEG1ビデオ（VideoCD）だと1セクターあたり2352データオクテット（2つのメディアレベルECC付き）。実際は1セクターあたり2048オクテットで、追加のEDC/ECCは「raw」読み取りで露出できるんだ。VideoPackのVCDイメージで大変な思いをして学んだぜ。ISO9660はファイルメタデータをビッグエンディアンとリトルエンディアン両方で保存するって豆知識もあるぜ。
オクテット？「バイト」のことじゃないのか？それとも、その言葉はもう問題ありなのか？
議論の文脈での「機能的」の定義は、メーカーが明示的に設計した通りに、業界標準の方法で動作することだぜ。予期せぬバグや誤動作じゃないし、抽象的な概念でもないんだ。
じゃあ、ドライブとして認識されず、有効なブロックさえ読み込めないのは「動作している」ってことか？
密閉容器と乾燥剤をたっぷり使えば助けになるかな？
俺の見解では、ECCメモリみたいに、これはまさに適切なレイヤーだと思うぜ。ストレージコントローラーがデータを処理してアナログ信号に変換して送信する時、エラーの可能性はたくさんあるんだ。実際、これは解決済みの問題だけど、誰かがミスをするまではそうじゃない。そうなると、メーカーは間違いを否定するし、人々はいつもの容疑者に捕まるしで、デバッグに大いに苦労することになるだろうぜ。CPUでECC処理を全て正しく行えば、ビット腐敗や送信エラーに対する全ての恩恵を無料で享受できるんだ。もし全てがうまくいけば、ECCに関するより良い命令サポートが得られるかもしれない。それは素晴らしいおまけになるだろうな。
そうなるようにできてるんだぜ。容量を増やすには、電荷がセル間で拡散しやすくなるような小さなセルを作る必要がある。ドライブを速くするには、蓄積電荷を小さくする必要があるが、これも耐久性を低下させるんだ。SLCとQLCの比較だとさらに悪くなるぜ。QLCは基本的に、同じ物理セル数により4倍のデータを保存する賢いハックなんだ。これはトレードオフだぜ。
ああ、でもそのトレードオフには隠れたコストがあるんだぜ、それは「複雑さ」だ！俺は100K WpBの64GBのSLCの方が、10K WpB未満の4TBのMLCよりもずっといいぜ。書き込みを均一化したりキャッシュしたりするためにビットをあちこち動かすスプレッド機能も失敗するだろうな。もちろん、最善の妥協案は、異なる目的で両方の種類を使うことだぜ。小さなメインOS用にはSLC、ユーザーデータベースやファイルのようなゆっくりと変化する大きなデータ用にはMLCって感じだ。問題は、SLCを作る工場や機械が全てなくなってしまったから、今はもう選べないことだぜ。
ああ、自己破壊するようにプログラムされていれば、施設が自己破壊するのもその仕様通りに「動作している」ってことと同じだぜ。
2012年と2022年のLCDテレビが理由もなく壊れたのは、たぶんコンデンサが悪いせいだね。https://en.wikipedia.org/wiki/Capacitor_plague は終わったかもしれないけど、電解コンデンサは今でも電子機器の寿命を決める主要部品だよ。
もっとコメントを表示（1）
SSDのファームウェアが、昔のHDDみたいに動いてるフリをするために、裏で色々やってるのって、マジで納得いかないな（IMO）。この責任はドライブ自体じゃなくて、ファイルシステムに委ねてほしいよ。
ファームウェアエンジニアの人いたら教えてほしいんだけど、SSDのデータリフレッシュって実際どうなってるの？電源オン時とかN時間ごと？特定のブロックにアクセスしないとダメ？途中で中断したらどうなる？例えば、外付けNVMeを月1回数分だけ使うとか。4TBドライブで1GBだけ使ってると、未使用領域も劣化する？ユーザーはどう管理すべきか全然わからない。
SSDファームウェアエンジニアだよ。エンタープライズ向けの話だから、コンシューマー向けは違うかもだけど。データリフレッシュはシステム電源オン時にバックグラウンドで動くよ。性能は落ちるけどね。未使用領域の劣化は心配ないはず。内部ファイルシステムデータはSLCみたいな頑丈な場所に保存されるから。ユーザーの管理方法としては、毎月fsckするとか？コールドストレージとしてはあまり良くないかも。
数年前の4TB USB SSDが引き出しに電源オフのまま数年間放置されてたとして、フルディスクのリフレッシュが完了するまで、どれくらい電源入れておけばいいの？（アイドル状態で）。うちの4TB USB SSDも数年放置したけど、データは大丈夫だったんだ。もちろん、新品で書き込みサイクルも少なくて、空調管理された場所に置いてたからかもだけどね。どれくらい繋げっぱなしにすれば“劣化時計”をリセットできるか知りたいな。
エラー訂正と劣化データの更新を強制するには、ドライブを全部読み込むのが一番確実だよ。
初心者なんだけど…フルリードってどうやればいいの？
一番基本的な方法は、どんなファイルシステムでもブロックデバイスでもマウントせずに動くsudo pv -X /dev/sdaか、sudo cat /dev/sda ＞/dev/nullだよ。
でも、データが少ないと非効率だね。
btrfsならsudo btrfs scrub start -B /、ZFSならsudo zpool scrub -a -wが使えるよ。
空き領域が多い従来のファイルシステムなら、sudo tar -cf - / | cat ＞/dev/nullがいいかも。catと/dev/nullへのリダイレクトが必要なのは、GNU tarが最適化して読み込まないから。
注意なんだけど、GNU coreutilsではそうじゃないと確認したけど、一部のシステムではcp（とcatも？）がmmap()するかも。出力がdevnullドライバーだと、書き込み関数が何もしないから読み込みが発生しないんだ。だから、パイプ（またはdd）を使うのがどんな場合でも良いアイデアかもしれないね（現行のBSDは確認してないけど）。
これが一番シンプルで確実な方法だよ。sudo dd if=/dev/sdX of=/dev/null bs=4M status=progress iflag=direct
macOSやLinuxでは、ddコマンドを使ってSSDのデータを/dev/yourssdから/dev/nullにコピーできるよ。逆はやっちゃダメだから注意してね！
強制的に読み込むのが良い方法かは分からないけど、やり方だけ教えたよ。https://www.man7.org/linux/man-pages/man1/dd.1.html
/dev/nullは読み込むと”空”だよ。ディスクにddしちゃいけないのは/dev/zeroの方だよ。
記事の「一般的に、データリフレッシュはシステム電源が入っているときにバックグラウンドで行われる」って部分だけど、SSDはどうやってリフレッシュのタイミングを知るの？SSDには内部時計がないから、電源オフの期間は分からないはず。読み込みがコントローラに信号強度を伝えるテレメトリーを生成して、リフレッシュが必要か教えるのかな？それとも、何かタイマーで無差別にリフレッシュするの？
大体そんな感じだけど、メーカーやドライブにかけた費用でかなり変わるよ。エンタープライズSSDの多くはほぼ常に電源が入っているけど、使ってないときは低電力状態なんだ。だから、電力予算内でタイマーでデータがリフレッシュされることもあるよ。
データ保全には費用のかかる層がいくつかある。ドライブがリカバリが必要なものを読み込もうとすると、そのブロックをリフレッシュが必要だとマークしてバックグラウンドで書き換えるんだ。
Samsungの解決策は、積極的なスキャンとバックグラウンドでの書き換えだったよ。詳しくはここを見てね: https://www.techspot.com/news/60501-samsung-addresses-slow-8…
記事の「毎月fsckをやるべき」ってあるけど、それってZFSやBTRFS、BCacheFSみたいなモダンなファイルシステムでの定期的な”スクラブ”操作と同じじゃない？
それと、「データリフレッシュはシステム電源が入っているときにバックグラウンドで行われる」って部分が混乱するな。バックグラウンドで行われるなら、手動のfsckは何のためにやるの？
じゃあfsckをやるべきなの？この記事を読んで一番疑問に思ったのは、ただデバイスの電源を入れるだけで十分なのか（どのくらいの時間？）、それとも各バイトを実際に読み込む必要があるのかってことだよ。
普通のユーザーが心配するのは、外部SSDにあまり頻繁じゃないスケジュールでバックアップを取っている場合だよね。そういう状況で、ただ差し込んで何かをコピーするだけでドライブの全データがリフレッシュされるのか、それとも何か明示的な「メンテナンス」が必要なのかが知りたいな。
データリフレッシュって大体どのくらい時間がかかるの？外部ポータブルSSDにデータを保存しているとして、ドライブをPCに接続してdd if=/dev/sdX of=/dev/null bs=1M status=progressを実行すれば、内部の不良ブロックをリフレッシュするのに役立つかな？
フルリードすればいいけど、外部ストレージには小型のHDDを使うのが一番安全なアドバイスだと思うよ。それ以外は全部、緩和要因に対処しているだけだからね。
ありがとう！HDDを使うのが正しいってのは同意だけど、僕のポータブルSSDの場合、全ブロックを読み込んだ後、どのくらいドライブを繋いでおけばいい？リフレッシュ処理って通常時間かかるの？それとも全ブロック読み込むのと同じくらいで終わるかな？
そもそもリフレッシュ処理って実際に行われるの？
なるほど、電源オンでもビットが状態を失わないよう全部ローテーションする必要があるってこと？
追記: 下の方で「SSDの電源オンだけじゃダメ。セルを再充電するためにたまに全ビットを読まないと」ってあったよ。じゃあファームウェアにビットを読んでリフレッシュするロジックがあるってこと？
まあね。「読み書き戻し」ロジックと、「不安定なブロックから安定したブロックへ移動」ロジック、他にもいろいろあるんだ。NAND flashはめちゃくちゃ信頼性が低いから、それをシステムから隠すのがコントローラーの役目だよ。
「ymmv」って何だろうってググっちゃった。他の人の時間節約のために教えとくね。それは「your mileage may vary」のことだよ。
flash memoryを読み込むとき、0か1じゃなくて、おおよそ浮動小数点値が返ってくるんだ。0.1とか0.8とかね。SSDコントローラーには、それを再構築したりerror correctしたり補償したりする大量のcodeやLDPCみたいなencoding schemeがある。現代のコントローラーはflashの状態をよく把握してて、弱点を補うためにデータを移動させるよ。filesystemよりもずっと多くのerror detectとcorrectをしてる。でも、いつデータが「poof!」って消えるかっていう根本的な疑問は残るよね。その時こそ、君のrestore systemが試される時さ。
flash chipとコントローラー間のcommunication protocolを誤解してなければ、コントローラーがアナログ値を知る方法はないよ。デジタル結果しか見られないはずだ。Debug featureとして、thresholdを調整して同じデータを何度も読み直し、ビットがflippingする寸前かを知ることはできるかもしれないけど、毎回読み込むのはnormal practiceじゃないね。
戻り値が0.5未満なら0、それ以外なら1。
通常、未使用の空き容量が多いのは良いことだよ。ネイティブのQLCモードじゃなくてMLCやSLCモードでドライブを動かせるからね（performance testingから見て、SLC/MLCのほうがQLCよりperformanceが良いことから明らかだよ）。SLC/MLCのデータremanenceはQLCよりずっと優れてると期待できるしね。
SSDがMLCやSLCモードで動くか、QLCモードで動くかは、SSDコントローラーがSLCキャッシュからTLC/QLC領域へデータを積極的に移動させるかによるんだよね。パフォ維持のためには、ほとんどのコントローラーがそうするはずだよ。そうしない理由はないし。
安いDRAMレスのコントローラーは、ドライブがほぼ満杯になるまでデータの折りたたみ（フォールディング）を待つことが多いみたい。しかも、必要なスペースを空ける分だけしかやらないんだって。ほとんどのベンチマーク結果もこの挙動と一致してるよ。
このブログ記事はJEDECのデータ保持標準[1]のリハッシュだと思うな。規格で面白いのは、クライアント向けとエンタープライズ向けで電源オフ時の保持期間が違うこと。エンタープライズは3ヶ月、クライアントは1年。でもエンタープライズは24時間稼働想定、クライアントは8時間想定なんだよね。結局、ユーザーがどこで妥協するかだね。
[1]https://files.futurememorystorage.com/proceedings/2011/20110…
もっとコメントを表示（2）
JEDECのデータ保持標準[1]は、具体的にはJEDEC JESD218のことだよ。（書き込み耐久性はJESD219ね。）
長いJEDECの概要文書[1]によると、理想的な「直接」テスト方法では、保持テストは耐久テストの後、つまりドライブが最大TBWを書き込まれた後に行われるって説明されてるよ。1000時間超える場合は、TBW以下で加速技術を使った推測アプローチも使えるんだ。これって、Retention値が最初に見たほど劇的じゃないし、俺が見た記事で伝えられてる内容よりも緩和されてるってことだよね。元の記事でも、これについてはコメントで指摘されてるけど、記事自体は外部リンクや引用がないんだ。
[1] https://www.jedec.org/sites/default/files/Alvin_Cox%20%5BCom…
1年間電源オフでデータ保持できるって言っても、それでもデータは失われる可能性があるわけだろ？結局、データ保持についてはまだ妥協が必要なんだよ。
俺たち、マジで「コールド」バックアップとしてNVMeを物理的な金庫に保管してて痛い目にあったよ。NVMeドライブをデジタルの石版みたいに扱ってたら、1年後に重要なスナップショットを復元しようとしたら、あちこちでチェックサムが失敗したんだ。今は、電荷トラップをリフレッシュするために、コールドストレージドライブを半年ごとに電源サイクルするポリシーにしてる。本当に「永久」ストレージがいかに一時的なものかって、ゾッとするね。テープは管理が面倒だけど、少なくとも棚に置いておいても電子が漏れることはないもんな。
この場合の「電源サイクル」ってどういう意味？データホードのフォーラムでこの話題はよく出るけど、どうすればデータがリフレッシュされるのか、誰も正確には知らなくてコンセンサスがなかったんだ。電源をちょっと入れるだけでいいとか、全データを書き換えなきゃダメとか、いろんな憶測があった。上のファームウェアエンジニアのコメントは、これまでで一番良い情報だよ。俺の推測もある程度裏付けられた感じ。彼はエンタープライズドライブ担当で、ランダムなタイマーでバックグラウンドでリフレッシュサイクルが始まるらしい。どれくらい時間がかかるかは（まだ）書いてないけど、バックグラウンドプロセスってことから、多分数時間以上かかるんだろうね。これはエンタープライズドライブの話で、コンシューマー向けにはこんな堅牢な、あるいはそもそもリフレッシュ機能がないなんてこともあり得るんじゃないかな。俺の意見としては、この機能の実装に関する数少ない情報から考えると、コールドバックアップのリフレッシュサイクルでは、結局、全データをもう一度上書きし直すべきだって結論になるね。電源を入れるだけじゃ不十分だし、1日電源を入れても何も変わらないかもしれない。君が言うように、これはフラッシュをコールドバックアップとして使う上での大きな欠点だね。
もうフラッシュを永久ストレージと考えるのはやめるべきだよ。電源が供給されてる間だけ機能する一時的なストレージなんだ。長期的に使えて大容量のアーカイブストレージがあればいいのにって思うね。バックアップとか長期保存データには、フラッシュの良い補完になるはずだよ。
そんなに願うなら、現代のLTOテープドライブはだいたい4000ドルくらいだよ。テープは1TBあたり5ドルってとこだね。
最近弁護士と話したんだけど、彼が言うには7年間のファイル保持義務を満たすために、もう何年も全部のファイルをSSDにスキャンして金庫に保管してるんだって。まさかそんな話が出るとは思わなかったよ。
データ保管のGoldilocksゾーンってどこなんだろ？やっぱりHDDなのかな？僕の20年前のIDE HDDは、いまだに普通に動いてるみたいだけど。
＞コールドストレージドライブを6ヶ月ごとにパワーサイクルするポリシーがある
なんでテープを使わないんだろうね？LTOアーカイブテープなら10～20年もつし、かなり安いと思うんだけど。
記事は「一般人には関係ない」って言ってるけど、それ絶対違うよ！地下の15年前のPCを処分する時に家族写真取り出そうとしたらどうなる？数年に一度しか電源を入れないデバイス（例えばアーケードマシン）とかもそう。僕のアーケードマシンは2、3年使ってないから、多分再インストールが必要かも。こんな大事なこと、箱に書いてないのは本当に大問題だよ。
電源が入ってるSSDで、ほとんど読み書きされないファイルってどうなるんだろう？SSDコントローラーが自動的に充電を更新してくれるのかな？それとも、定期的に「find / -type f -print0 | xargs -0 cat ＞ /dev/null」みたいなコマンドを実行して、すべてのファイルが読まれるようにしないとダメ？
いや、ファームウェアが全部メンテナンスするよ。良いファームウェアならアイドル時に徐々にスクラブするはず。でも、そのファームウェアが良いかどうか、実際に何をしてるかを知る方法はないんだよね。デバイスの消費電力を測って、ハウスキーピングしてるか検知する簡単な方法ってないのかな？
正直、ZFSが好きな理由の一つがこれだよ。毎週か毎月（スケジュールによるけど）ディスクスキャンが実行されてて、各ブロックの内容が検証されてるってわかるから、すごく安心できるんだ。
ZFSのスクラブ、ちゃんと実行されてるか確認してる？ZFSスクラブのデフォルトスケジュールがなかったせいで、Linus Media Groupはビットロットでアーカイブ動画をたくさん失ったらしいよ。
僕はzedにスクラブ完了のたびにメールを送るようにしてるんだ。毎週スクラブしてるから、毎週メールが届くよ。もしメールが来なかったら、何かおかしいってすぐわかるんだ！
「SSD、電源なしだとデータが消える」って記事でZFSをよく聞くんだけど、ホームユーザーがZFSを使うデメリットって何？OSはSSD、ファイルはHDDに保存してるんだけど、ZFSはアリ？
ZFSのデメリットね。1)対応OSが必要、2)ルートボリュームでの使用は難しいからOSのSSDのメリットが減るかも、3)ECC RAM推奨（必須じゃないけど）、4)最速じゃないってとこかな。僕はサーバーとかNASでしか使わないよ。ワークステーションだと手間がかかりすぎるからね。FreeBSDならアリだけど、ホームユーザーには現実的じゃないかも。
いつもZFSが推奨されるのに驚くわ。BTRFSだってチェックサムとかスクラブがあるのに、ZFSみたいに複雑だったりOS統合の問題もないのにね。
BTRFSが初期に不安定だったり、RedHatのコミット不足、RAIDがないせいで使わなかったんだよね。僕はSolarisとかFreeBSDでZFSに慣れてたし。ファイルの信頼は築くのが大変で、失うのは簡単だからね。FreeNASの普及もZFSが人気になった理由だと思うよ。ちなみに20年前のクラッシュ以来、XFSは信用してないな。
Debianを使ってるんだけど、ブート、/、/home/はパーティションを分けてるよ。ECC RAMじゃないし、速度より回復力重視なんだけど、それでもZFSを検討すべきかな？教えて！
ZFSはDebianでもサポートされてるよ（dkms経由）。データパーティションなら使えるはず。新しいのを試したいならいいけど、必須ってわけじゃないかな。今のFSで十分だと思うよ。DebianでZFSは動くけど、ライセンス問題で公式サポートじゃないんだ。試すならまずVMでやってみるのがおすすめだよ！
僕のLinuxデスクトップ、ラップトップ、FreeBSDサーバー全部でZFSを使ってるよ。2011年から使ってるから慣れてるけど、そんなに難しくないよ！UEFIを使えるならZFSBootMenuがおすすめ。FreeBSDのブートローダーみたいに、起動時にスナップショット管理とかロールバックができるんだ。ぜひ見てみて！
https://zfsbootmenu.org/
これって僕のPixelスマホが写真なくしたのと関係あるのかな？
https://news.ycombinator.com/item?id=46033131
数週間ごとにディスク全体をフルブロックリードすべきだよ。具体的には「dd if=/dev/disk of=/dev/null」ってコマンドを使うといいよ。
