スキップしてメイン コンテンツに移動

NAS(QnapTS) データ復旧の試み

以前NASがクラッシュしたと書いた。
https://atsreport.blogspot.jp/2017/06/aspire-l5100-nas-qnap.html


RAID5からデータを吸い出すのは結構手間で、一応4本のHDDを一つのPCに繋いでデータを抜き出す作業が面倒だった。
たまたま、使っていたPCがSATAポートの空きが6つもあったので、これに4本を繋いでLinux(OpenSUSE)で見てみると自動的にRAID5のドライブとして6TBのHDを認識した。

今までは2TBを4本つなぎ、RAID5のNASを運用しており、物置に物を放り込むが如く、なんでもNASに入れていたので、5TB以上のデータが保存されていた。重複したデータやゴミデータもたくさんあった。

この大量のデータを一旦移し替えるのに、交換用で準備してあったHDDや、ディスクエラーが出て交換したHDDに移動した。
この最中にディスクエラーの出ていたHDDは1本クラッシュしてしまった。(※)

データを無事に別の場所に保存できたので、RAIDの構成について考える。

そもそもの経緯は以下のような感じである。
  1. 4本中 1本のHDDにエラーが出たため、ディスク交換
  2. 交換後自動でリビルド
  3. その後、ファームウェアの更新
  4. 再起動後、データの一部が見えなくなる
QNAP はHDDの一部をOS用に使用しているが、これがうまく読めなかったようで、
デイスクをPC( OpenSUSE )に4本繋いだときはちゃんと中身が見れた。

以上のことから、障害耐性を高めるため、RAID5をやめることにした。
2TB 4本のHDDを繋いでいる為、RAIDの候補は次の3つに絞った。
  • RAID6 (4TB)
  • RAID10 (4TB)
  • RAID1 (2TB) + RAID1 (2TB)
[RAID6]
この3つの中で最も障害耐性が高い。
どの2本HDDがクラッシュしてもデータは取り出せる。
3本クラッシュするとデータは失う。

[RAID10]
障害耐性はRAID1を2つ作る場合と同じか、ちょっと低い。
2本のHDDがクラッシュしても運が良ければデータは守られるが、
運が悪いとすべてのデータを失う。
3本クラッシュするとデータは失う。

[RAID1 + RAID1]
障害耐性はRAID10と同じぐらい。
2本のHDDがクラッシュした場合、運が悪ければ半分のデータを失う。
3本クラッシュしても半分のデータは取り出せる。


上記の障害耐性はHDDについての話しであり、NAS自身については考慮していない。
今使用している QNAP TS の機器は5年以上使っているので、
機器自身が使えなくなった時の復旧についても考える必要がある。
UPSを繋いでないため、停電や雷等での故障も考えられる。

この為、QNAPが故障してもデータ復旧の容易さも考慮し、RAID1 を 2組作ることにする。
自分自身でRAID6の2本のHDDからデータを抜き出すより、
RAID1のHDD1本 からデータを取り出すほうが簡単だから。

ということで、4本のディスクが乗せられるのに、2本づつでRAID1を組む。
RAID6やRAID10に比べるとデメリットとして、2TB×2 と容量が別れてしまうがしょうがない。
今回の復旧のためにかなりの時間を割いたことを考えると、安易に複雑なRAIDを導入する気になれない。


 どうせ大したデータもないので2TB程データを削って、新しいNASへデータを移すことにしよう。




 (※)
この途中でクラッシュしたHDDからデータを取り出すのに難儀した。
ext3 のHDDだったので、extundelete コマンドで取り出したが、
800GB程取り出すのに10時間程かかった。


ラベル:

コメント

コメントを投稿

このブログの人気の投稿

Ubuntu で RAIDディスクをマウントする

謎のHDDが見つかった。 データを確認するためWindowsにつなぐもマウントされず。 これは extとかffsの辺りかなと思い、Linux(Ubuntu)に繋ぐ。 しかし、自動マウントされない。 取り敢えずマウントする。 # mount /dev/sdb1 /mnt/disk すると'linux_raid_member'とエラー表示された。 ということで、まずファイルシステムを確認。 # parted -l このコマンドでファイルシステムが表示される。 また、Gparted でも表示される。 そこでRAIDディスクを扱うためにmdadmパッケージをインストール。 # apt install mdadm ネットでは mountコマンドの -t オプションで明示的にファイルシステムを指定するとマウントできると書いてあったのでそれを試すとマウントできた。 # mount -t ext3 /dev/sdb1 /mnt/disk 内容を確認すると不要なデータだったのでデータを削除する。 # shred -v /deb/sdb この処理はとても時間がかかるので普段使わないコンピュータで処理をした。
コメントを投稿
続きを読む

自動ログイン on Lubuntu

Lubuntu 19.04 の 自動ログインを設定してみた。 グラフィカルログインを自動で行うようにしたいが、 ユーザー設定 の中に自動ログインの設定がない。 そこでコマンドラインから設定してみた。 まず、ログインをするときに使用しているディスプレイマネージャを確認する。 $ cat /etc/X11/default-display-manager /usr/bin/sddm sddm を使っているので、sddm の自動ログインを設定する。 OSは systemd で動いていると設定ファイルがないようなので作成する。 # sddm --example-config > /etc/sddm.conf.d/sddm.conf この設定ファイルに Autologin について書いてあるのでここにユーザ名を入力。 $ head /etc/sddm.conf.d/sddm.conf [Autologin] # Whether sddm should automatically log back into sessions when they exit Relogin=false # Name of session file for autologin session (if empty try last logged in) Session= # Username for autologin session User= ここの User= にユーザ名を書き込み保存後、再起動すると自動でログインされる。
コメントを投稿
続きを読む

TVに繋いでいた録画用HDDが認識しなくなった

ポロポロとものが壊れていく。 年数もそれなりに経っているので仕方がないと思うが、 　Panasonic VIERA TH-L32X3 　メーカーページ http://panasonic.jp/viera/p-db/TH-L32X3.html 上記VIERAに繋いでいた録画用のHDDが急に認識しなくなった。 実はこれで二回目のトラブルである。 一回目は買って1年ほどでこの症状が出た。 この時はHDDが物理的な障害で故障したと思い、ダメ元で再接続再フォーマットした。 このHDDはそのあと5年以上正常に動作していた。 結局この時の障害は論理障害だったのだと思う。 今回も同様の症状だったので、復旧を試みることにした。 こちらのサイトに Panasonic製のセットトップボックスへ繋いでいたHDDの修復について書いてあった。 Panasonic CATV STBの外付けHDDのファイルシステム修復　おぼえ書き http://qiita.com/a_saitoh/items/93a9983b988b541d2cb1 これを参考にして、FreeBSD11.0( https://www.freebsd.org/ja/ ) に外付けHDDを繋いで、fsck_ffs -n を実行するも復旧せず。 仕方がないので、fsck_ffs -y や fsck_ufs -n 、 fsck_ufs -y などをかけてからTVにつなぐと認識した。 録画データは諦めていたので、いろんなコマンドをかけてしまったので、 どのコマンドが良かったかはっきりとしないが、 無事にデータが参照できるようになった。
2 件のコメント
続きを読む