NASはバックアップではない!

今日はQNAPから、「NASはバックアップではなく、NAS自体もバックアップが必要である」という非常に興味深く、かつ教訓的なレッスンを受けました。これはあなたにも起こり得ることです。

最近、ボリュームのRAIDスクラビングを完了しました。これまで一度もやったことがありませんでした。ある問題が発生したため、ダンプログをチケットに提出しました。技術者から返答があり、修正できないZFSファイルシステムエラーが多数あるので、NASを初期化して一からやり直す必要があると言われました!

これは不良ドライブが原因ではありません(SSDドライブとメインのRAID HDD両方で発生しています)。技術者によると、良いドライブでも書き込み時にデータが破損することがあり、それはどうしようもないとのことでした。彼は「NAS外にすべてのデータをバックアップして、NASを初期化してやり直してください!」と言いました。信じられませんでした。

ということで、もう一度警告します—NAS自体はバックアップではありません。PCをNASにバックアップしているかもしれませんが、NASも別の場所にバックアップしてください!問題の原因は必ずしも不良ディスクとは限りません。

これからこの作業をするのが本当に楽しみです!少なくとも、h5.3はまだ完成しておらず、High Availability(ハイアベイラビリティ)用途でしか必要ないので、h5.2に戻るつもりです…

だからこそ、Quts(Quts)とその裏で行われているさまざまなことに警戒していました。最近Quts(Quts)への移行を検討していましたが、今のところQts(Qts)のままでいようと思います。

正しい1:NASだけではバックアップの確実な方法にはなりません。RAIDもバックアップではありません。だからこそ321ルールが重要です。NASやRAIDを持つことに関する最大の誤解はこれかもしれません。これらは復旧時間を最小限に抑えることはできますが、単体では火災やハードウェア故障からあなたを守ることはできません。

QNAPでもSynoでも、その他何であっても関係ありません

RAIDはバックアップではなかったし、これからもバックアップにはなりません

もしNASがバックアップ(データのコピー)であれば、そのNASこそがバックアップであり、元のファイルから再構築することができます

2024年後半に新品のTS-464C2を購入しましたが、1か月以内にストレージプール全体が破損しました。QuTS Heroに切り替えたところ、すべてのドライブでチェックサムエラーが発生し、NAS本体の問題だと気付きました。memtestでその考えが証明されました。

さらに悪いことに、ベンダーから新品の交換品を受け取りましたが、それもメモリの問題がありました…。

クラウドに毎日バックアップを取っていたので数時間分のデータしか失いませんでしたが、復旧には数日かかりました。

QuTS Heroを利用している方には、定期的にSSHセッションを開いて次のコマンドを実行することをお勧めします。

zpool status -v

実際の出力例は以下の通りです。

[Jono@NA9D-NAS ~]$ zpool status -v
  pool: zpool1
 state: ONLINE
status: 1つ以上のデバイスでエラーが発生し、データの破損が生じています。アプリケーションに影響がある可能性があります。
action: 可能であれば該当ファイルを復元してください。それができない場合は、バックアップからプール全体を復元してください。
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrubで0が修復され、0日00:15:53で2つのエラーが2025年10月19日(日) 00:15:58に発生
 prune: 最後に409エントリを剪定、これまでに2392エントリが剪定されています
        総剪定回数 #5、平均剪定速度 = 2986468 (エントリ/秒)
expand: 要求なし
 renew: 要求なし
config:

	NAME                                    STATE     READ WRITE CKSUM
	zpool1                                  ONLINE       0     0     2
	  mirror-0                              ONLINE       0     0     4
	    qzfs/enc_0/disk_0x1_24074767F6C0_3  ONLINE       0     0     4
	    qzfs/enc_0/disk_0x2_24534D52401A_3  ONLINE       0     0     4

errors: 次のファイルで恒久的なエラーが検出されました:

        zpool1/$SHADOW:<0x1> (181:1:0:5046392)
        zpool1/$SHADOW:<0x1> (181:1:0:5046393)

  pool: zpool2
 state: ONLINE
status: 1つ以上のデバイスでエラーが発生し、データの破損が生じています。アプリケーションに影響がある可能性があります。
action: 可能であれば該当ファイルを復元してください。それができない場合は、バックアップからプール全体を復元してください。
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrubで0が修復され、5日04:25:26で16のエラーが2025年10月24日(金) 04:25:37に発生
 prune: 最後に2637224エントリを剪定、これまでに15879437エントリが剪定されています
        総剪定回数 #5、平均剪定速度 = 3490183 (エントリ/秒)
expand: 要求なし
 renew: 要求なし
config:

	NAME                                        STATE     READ WRITE CKSUM
	zpool2                                      ONLINE       0     0   364
	  raidz1-0                                  ONLINE       0     0   728
	    qzfs/enc_0/disk_0x3_5000CCA27EC5F5A5_3  ONLINE       0     0     0
	    qzfs/enc_0/disk_0x4_5000CCA267CD00FE_3  ONLINE       0     0     0
	    qzfs/enc_0/disk_0x5_5000CCA273F0B2D9_3  ONLINE       0     0     0
	    qzfs/enc_0/disk_0x6_5000CCA27EC5A850_3  ONLINE       0     0     0

errors: 次のファイルで恒久的なエラーが検出されました:

        zpool2/$SHADOW:<0x1> (181:1:0:29628189)
        zpool2/$SHADOW:<0x1> (181:1:0:764458)
        zpool2/$SHADOW:<0x1> (181:1:0:12855854)
        zpool2/$SHADOW:<0x1> (181:1:0:784706)
        zpool2/$SHADOW:<0x1> (181:1:0:57489228)
        zpool2/$SHADOW:<0x1> (181:1:0:57232981)
        zpool2/$SHADOW:<0x1> (181:1:0:57499738)
        zpool2/$SHADOW:<0x1> (181:1:0:5362782)
        zpool2/$SHADOW:<0x1> (181:1:0:1036430)
        zpool2/$SHADOW:<0x1> (181:1:0:5493137)
        zpool2/$SHADOW:<0x1> (181:1:0:5355174)
        zpool2/$SHADOW:<0x1> (181:1:0:57241256)
        zpool2/$SHADOW:<0x1> (181:1:0:30161860)
        zpool2/$SHADOW:<0x1> (181:1:0:5499856)
        zpool2/$SHADOW:<0x1> (181:1:0:754404)
        zpool2/$SHADOW:<0x1> (181:1:0:13872636)


以前にもそのようなエラーが発生したことがありますが、かなり前のことなので、どうやって解決したかは覚えていません。RAIDを削除して再作成したのかもしれません。UPS(無停電電源装置)が短い瞬間的な停電(クイックブラウンアウト)で問題を起こしていたときに、こうしたエラーが発生していた気がします。UPSをより良いモデルに交換してからは、もうそのようなことは起きていませんし、私のディスクの中には8年も稼働しているものもあります。新しいものでも2~3年程度です。

もし電力が瞬間的に落ちてUPSがNAS(ネットワーク接続ストレージ)に電力を供給するまでに少し時間がかかる場合、それがエラーの原因になっている可能性があります。

私はこれについて何年もお客様に教育してきました。なぜなら、以前Netgear NASのRAIDアレイがクラッシュしてデータを失ったことがあり、その後Synology NASでも同じことが起きましたが、幸いにもQNAP NASデバイスではまだ発生していません。しかし、何事も過小評価すべきではなく、3-2-1バックアップルールは重要です。そのため、メインNASのすべてのデータをセカンダリNASにバックアップしています。

ちなみに、あなたのコードを試してみましたが、問題なさそうです。
zpool1とzpool2の結果 → エラー: 既知のデータエラーなし

@marcoi - 電力の変動などは全くありませんでした。何が原因かは分かりません。他のHero NASは問題ありません。QNAPの技術者が言っていたように、どうしてこうなったのかは不明です。書き込み中に何かが壊れてしまったのかもしれません。

OK。これからこの“バッドボーイ”を工場出荷時リセットするので、めちゃくちゃ緊張しています!

:grimacing:

QNAPのチケットに関する過去のメールを確認しました。ちなみにこれは2021年に発生し、2022年の時期にファームウェアで問題が修正されたようです。

以下、チケットからの内容です

調査の結果、RDチームによると、見られたエラーは修復不可能なプールの恒久的なエラーを示しているため、唯一の解決策は新しいプールを作成することだそうです。
すでに他の場所にデータがある場合は、その元のデータセットから新しいプールにデータをコピーしてください。もしない場合は、このプールからデータをコピーして移動させ、破損しているファイルはシステムがスキップするはずです。

新しいプールを作成した後は、今後この問題を防ぐために、月に一度のプールスクラビング(Pool Scrubbing)をスケジュールすることをチームが推奨しています(事後に修復しようとするのではなく)。

簡単なアップデートですが、チームはハードウェアの問題だとは考えていませんが、原因は完全には特定できていません。
ファイルシステムの「SHADOW」レイヤーで何らかの未知の破損が発生しているようですが、まだその原因を調査中です。

プール破損問題の修正を含む新しいh5.0.0ファームウェアが3/31にリリース予定のようです。
まだもう少し情報を得ようとしていますが、少なくとも現時点では修正が間もなく期待できそうです。

返信が遅くなり申し訳ありません。チームと情報を確認していました。
近日中に新しいh5.0.0ファームウェアアップデートがリリースされる予定で、このファームウェアによって今後プールが破損しなくなるはずです。

もし既存のデータが破損している場合、それを修復する方法はないようですが、将来的にh5.0.1バージョンがリリースされ、既存プールのエラーをクリアして正常に動作させることができるようになる予定です。

今後のリリースにご注意ください。ご質問があればお知らせください。

2022年以降、このエラーは発生していません。

よくわかりません。このNASは昨年末に購入して、Heroは4月か5月頃にインストールしました。

h5.3にアップデートしたときに何かがおかしくなったのではないかと考えています。

HAは必要ないので、今はh5.2に戻しています。

それは可能です。ただし、「バックアップ」という用語の理解によります。データのコピーが1つだけ、あるいはデータを保存するデバイスが1つだけでバックアップとして十分だと考えるなら、マーフィーの法則(Murphy’s Law)がそれが誤りだと教えてくれるでしょう。321原則は最低限の基準です。