自己責任でご参考にしてください。
また、発生したいかなる損害においても当方は責任を負いかねますm(_ _)m
■この記事にかかれていること
破損したSynologyのNAS DS418から取り出したハードディスクのデータを取り出す話です。
すでにSynologyのNASが使用できなくなり、CentOSなPCからデータを取り出す手順を解説しています。
NASがまだ起動する状況ならNASをつかって取り出せます。
NASが起動できないなら新ハードディスクを追加しDSMをインストールし直して取り出したほうがはるかに簡単です。Synologyのホームページから手順を確認できます。
NASが壊れて電源も入らないような故障の時は以下の記事が役に立つと思います。
今回使用しているPCのOSはCentOS7.5です。
Ubuntu等他のLinuxでも同等の手順で取り出しが可能だと思われます。
今人気のSynologyのNASですが、なかなか優秀です。国産のNASもいくつかありはしますが、海外系NASをいじるとその高機能、扱いやすさ、安定性、いずれをとっても国産NASにないものがあります。そんなSynologyのNASをついに入手したのですが、早々取り付けた新品HDDが破損。いや、破損クラスタが８個ほど出ただけなのですが、『故障が進行しています』とメッセージが出て交換することにしました。
別に保存したデータはまだテスト運用中だったこともあり必要なデータでもないのですが、この際、検証と手順の確認も含めて取り出したハードディスクからのデータのサルベージ作業を行ってみました。
4ドライブのNASです。メディアサーバーとしても利用できます。
とくに、気に入ったのがボリュームタイプのSHRが使えるところです。これは、RAIDの自動構成で、取り付けられたハードディスクの容量に合わせてRAIDを自動選択し最適なRAIDを使用し柔軟に容量アップができます。ドライブを適切に勝手に切り分けRAID1-RAID5を自動構成しつつ一つのボリュームとして扱えるので便利です。
ハードディスク1台から運用でき、ハードディスク2個でミラーリング、3個でRAID5に移行できます。容量が不足すれば随時ハードディスクを追加・容量アップできるので2ベイよりも4ベイのほうが融通がききそうです。
今回接続しているハードディスクは4Tバイト2個でRAID1を構成しています。
実は、DS420よりもDS418のほうがコア数が多くて性能が高いという。。。
Ubuntu等他のLinuxでも同等の手順で取り出しが可能だと思われます。
■Synology NASを買ってみたらいきなりハードディスクに故障メッセージが
今人気のSynologyのNASですが、なかなか優秀です。国産のNASもいくつかありはしますが、海外系NASをいじるとその高機能、扱いやすさ、安定性、いずれをとっても国産NASにないものがあります。そんなSynologyのNASをついに入手したのですが、早々取り付けた新品HDDが破損。いや、破損クラスタが８個ほど出ただけなのですが、『故障が進行しています』とメッセージが出て交換することにしました。
別に保存したデータはまだテスト運用中だったこともあり必要なデータでもないのですが、この際、検証と手順の確認も含めて取り出したハードディスクからのデータのサルベージ作業を行ってみました。
■Synology DS418 RAID NAS
4ドライブのNASです。メディアサーバーとしても利用できます。
とくに、気に入ったのがボリュームタイプのSHRが使えるところです。これは、RAIDの自動構成で、取り付けられたハードディスクの容量に合わせてRAIDを自動選択し最適なRAIDを使用し柔軟に容量アップができます。ドライブを適切に勝手に切り分けRAID1-RAID5を自動構成しつつ一つのボリュームとして扱えるので便利です。
ハードディスク1台から運用でき、ハードディスク2個でミラーリング、3個でRAID5に移行できます。容量が不足すれば随時ハードディスクを追加・容量アップできるので2ベイよりも4ベイのほうが融通がききそうです。
今回接続しているハードディスクは4Tバイト2個でRAID1を構成しています。
実は、DS420よりもDS418のほうがコア数が多くて性能が高いという。。。
■ストレージプールが劣化しています
ことの始まりは。。。ストレージマネージャのメッセージ。ストレージマネージャー
ボリューム１（劣化）
アドバイス 関連のストレージプールは劣化しています。[ストレージプール]タブに進み［ストレージプール1］を修復してください
（参考）キャプチャしてなかったので別の画像です
それとSynologyからのメールです。
お客様各位、
DS418 上のドライブ 1 はひどく損傷し故障しかけています。データを直ちにバックアップして、次にドライブを交換してください。
ドライブ情報：
製造元：TOSHIBA
モデル：DT02ABA400
容量：3.6 TB
シリアル番号：Y123456789H
ファームウェア：KQ000A
S.M.A.R.T. ステータス： 失敗
不良セクター数： 1
ディスク再接続数： 0
ディスク再識別数： 0
詳細情報は DS418 にログインしてください。
お客様各位、
DS418 上のドライブ 1 の不良セクターが増加しました。統計は、不良セクターのあるドライブが、不良セクターのないドライブに比べて破損する可能性が高いことを示しました。データの完全性を保証するためにデータのバックアップを直ちに実行することを推奨します。その後、[ストレージ
マネージャ] > [HDD/SSD] > [S.M.A.R.T.]
の順に進んで、拡張テストを実行し、テスト結果で推奨アクションを参照してください。
ドライブ情報：
製造元：TOSHIBA
モデル：DT02ABA400
容量：3.6 TB
シリアル番号：Y123456789H
ファームウェア：KQ000A
S.M.A.R.T. ステータス： ノーマル
不良セクター数： 8
ディスク再接続数： 0
ディスク再識別数： 0
詳細情報は DS418 にログインしてください。
送信元 DS418
SMARTの詳細スキャンも失敗するようなのでもうどうしようもありません。
SynologyのNASで使用されているOSはDSMというオリジナルOSですが、これはLinuxベースのOSです。LVM（Logical Volume Manager)を使用し物理ドライブを隠蔽した上で、
RAIDを構成することで、RAIDの構成の変更と柔軟な容量のボリュームを提供しています。なのでLinux系統のOSを使用することで、RAIDを再構成すれば比較的容易にデータの吸い出しが可能となるのです。
また、SynologyのNASで使用されているボリュームのファイルシステムはbtrfsです。耐障害性が高く障害時のデータの取り出しが容易といった特徴があります。ただ、このファイルシステムはRedHat Enterprise Linux7でサポート終了となっているため、この記事が新CentOSではそのまま使えなくなるかもしれません。。。
■Synology NASのOSとRAIDのファイルシステム
データのサルベージを行う前に事前知識が必要です。SynologyのNASで使用されているOSはDSMというオリジナルOSですが、これはLinuxベースのOSです。LVM（Logical Volume Manager)を使用し物理ドライブを隠蔽した上で、
RAIDを構成することで、RAIDの構成の変更と柔軟な容量のボリュームを提供しています。なのでLinux系統のOSを使用することで、RAIDを再構成すれば比較的容易にデータの吸い出しが可能となるのです。
また、SynologyのNASで使用されているボリュームのファイルシステムはbtrfsです。耐障害性が高く障害時のデータの取り出しが容易といった特徴があります。ただ、このファイルシステムはRedHat Enterprise Linux7でサポート終了となっているため、この記事が新CentOSではそのまま使えなくなるかもしれません。。。
■CentOSでSynology NASのハードディスクをサルベージする
ここからが本題です。実際にサルベージする手順とコマンドを説明します。
この記事で扱われるシステム構成
NAS Synology DS418 SHR(RAID1構成)
+ Drive1 4T TOSHIBA DT02ABA400 ←故障 ここからの取り出しを試みる
+ Drive2 4T HGST HDN724040ALE640
PC CentOS Linux release 7.5.1804 (Core)
2ドライブモデルのSynology NASもRAID1のミラーリングで動作していると思われるので同じ操作でデータのサルベージが可能だと思われます。
NASからTOSHIBA DT02ABA400を取り出し、CentOSのインストールされたPCに接続します。以下すべてRootログインしてからの操作です。 自分の環境に合わせて適宜読み替えてください。
ハードディスクTOSHIBA 4Tバイト関連のメッセージ
TOSHIBA DT02ABA400はsdb
[ 2.681029] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
この記事で扱われるシステム構成
NAS Synology DS418 SHR(RAID1構成)
+ Drive1 4T TOSHIBA DT02ABA400 ←故障 ここからの取り出しを試みる
+ Drive2 4T HGST HDN724040ALE640
PC CentOS Linux release 7.5.1804 (Core)
2ドライブモデルのSynology NASもRAID1のミラーリングで動作していると思われるので同じ操作でデータのサルベージが可能だと思われます。
NASからTOSHIBA DT02ABA400を取り出し、CentOSのインストールされたPCに接続します。以下すべてRootログインしてからの操作です。 自分の環境に合わせて適宜読み替えてください。
ドライブの確認
#dmesgハードディスクTOSHIBA 4Tバイト関連のメッセージ
TOSHIBA DT02ABA400はsdb
[ 2.681029] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 2.682649] ata6.00: ATA-10: TOSHIBA DT02ABA400, KQ000A, max UDMA/100
[ 2.682652] ata6.00: 7814037168 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
[ 2.682656] ata6.00: SB600 AHCI: limiting to 255 sectors per cmd
[ 2.683989] ata6.00: configured for UDMA/100
[ 2.842624] scsi 5:0:0:0: Direct-Access ATA TOSHIBA DT02ABA4 0A PQ: 0 ANSI: 5
[ 2.892896] sd 5:0:0:0: [sdb] 7814037168 512-byte logical blocks: (4.00 TB/3.63 TiB)
[ 2.892901] sd 5:0:0:0: [sdb] 4096-byte physical blocks
[ 2.892973] sd 5:0:0:0: [sdb] Write Protect is off
[ 2.892976] sd 5:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 2.894221] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2.902172] sda: sda1 sda2
[ 2.902744] sd 2:0:0:0: [sda] Attached SCSI disk
[ 2.958311] sdb: sdb1 sdb2 sdb5
[ 2.958893] sd 5:0:0:0: [sdb] Attached SCSI disk
認識されているドライブの確認
データをサルベージするパーティーションはsdb5
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
├─sda1 8:1 0 1G 0 part /boot
└─sda2 8:2 0 1.8T 0 part
├─centos-root 253:0 0 50G 0 lvm /
├─centos-swap 253:1 0 3.8G 0 lvm [SWAP]
└─centos-home 253:2 0 1.8T 0 lvm /home
sdb 8:16 0 3.7T 0 disk
├─sdb1 8:17 0 2.4G 0 part
├─sdb2 8:18 0 2G 0 part
└─sdb5 8:21 0 3.6T 0 part
1 つまたは複数のデバイスの md スーパブロックの内容を表示する
#mdadm -E /dev/sdb5
/dev/sdb5:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 2e890fa3:4c304fc5:3f648e73:80b4b820
Name : DiskStation:2
Creation Time : Sat Jul 11 20:56:29 2020
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 7804374912 (3721.42 GiB 3995.84 GB)
Array Size : 3902187456 (3721.42 GiB 3995.84 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1968 sectors, after=0 sectors
State : clean
Device UUID : 591f71ad:4e2d6d10:980b782b:a9ad48eb
Update Time : Fri Jul 17 19:30:12 2020
Checksum : f4eb4723 - correct
Events : 1245
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
すべてのRAID関連のサービスを停止する
これをしないと次のRAIDの構成に失敗するので必ず行います
# mdadm --stop --scan
RAIDの再構成を行いRAIDサービスを開始する
RAIDのボリュームは/dev/md0に割り当てる
# mdadm --assemble --verbose /dev/md0 /dev/sdb5 --run
mdadm: looking for devices for /dev/md0
mdadm: /dev/sdb5 is identified as a member of /dev/md0, slot 0.
mdadm: no uptodate device for slot 1 of /dev/md0
mdadm: added /dev/sdb5 to /dev/md0 as 0
mdadm: /dev/md0 has been started with 1 drive (out of 2).
再構成されたRAIDの動作状態を確認する
# cat /proc/mdstat
Personalities : [raid1
md0 : active raid1 sdb5[0]
3902187456 blocks super 1.2 [2/1] [U_]
再構成されたRAIDのボリュームの状態を表示する
# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sat Jul 11 20:56:29 2020
Raid Level : raid1
Array Size : 3902187456 (3721.42 GiB 3995.84 GB)
Used Dev Size : 3902187456 (3721.42 GiB 3995.84 GB)
Raid Devices : 2
Total Devices : 1
Persistence : Superblock is persistent
Update Time : Fri Jul 17 19:30:12 2020
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
Consistency Policy : resync
Name : DiskStation:2
UUID : 2e890fa3:4c304fc5:3f648e73:80b4b820
Events : 1245
Number Major Minor RaidDevice State
0 8 21 0 active sync /dev/sdb5
- 0 0 1 removed
存在するVolumeGroupを有効にする
# vgchange -ay
1 logical volume(s) in volume group "vg1000" now active
3 logical volume(s) in volume group "centos" now active
ボリュームをマウントする
# mount /dev/vg1000/lv /mnt/md0 -o ro
/mnt/md0は存在していなければ
md /mnt/md0 で作成しておく
マウント作業はここで完了
/mnt/md0からNASのハードディスク内に保存されていたファイルが見えるようになります。以降データバックアップも可能です。
■再構成したRAIDデータの確認と取り出し
RAIDのマウント位置に移動
# cd /mnt/md0
# ll
合計 316
drwxr-xr-x. 1 root root 24 7月 11 20:56 @S2S
drwx------. 1 root users 12 7月 11 21:30 @SynoDrive
drwxr-xr-x. 1 root root 122 7月 16 11:28 @SynoFinder-log
drwxr-xr-x. 1 root root 24 7月 11 21:28 @SynologyApplicationService
drwxr-xr-x. 1 root root 32 7月 11 21:29 @SynologyDriveShareSync
drwxr-xr-x. 1 root root 256 7月 12 20:27 @appstore
drwxr-xr-x. 1 1024 users 76 7月 11 20:56 @database
drwxrwxrwx. 1 root root 92 7月 12 20:32 @eaDir
-rw-------. 1 root root 191356 7月 17 15:05 @synocrond.core.gz
-rw-------. 1 root root 128626 7月 16 10:19 @synologrotated.core.gz
drwxr-xr-x. 1 root root 62 7月 11 21:33 @synologydrive
drwxrwxrwt. 1 root root 90 7月 17 18:16 @tmp
drwxr-xr-x. 1 root root 52 7月 12 03:02 homes
drwxr-xr-x. 1 root root 12 7月 11 21:33 music
drwxr-xr-x. 1 root root 12 7月 12 20:24 photo
drwxr-xr-x. 1 root root 28 7月 17 16:16 pictures
drwxr-xr-x. 1 root root 50 7月 17 18:38 public
drwxr-xr-x. 1 root root 12 7月 12 20:25 video
homesフォルダを覗いてみる
# cd homes
# ll
合計 0
drwxrwxrwx. 1 root root 42 7月 17 15:06 @eaDir
drwxr-xr-x. 1 1024 users 0 7月 11 21:26 admin
drwxr-xr-x. 1 1026 users 10 7月 11 21:28 owner
drwxr-xr-x. 1 1027 users 18 7月 12 03:34 david
:
■NAS用HDDのおすすめ
NASに使うハードディスクは何がいいのか。目的によりハードディスクを選定する必要があります。高速性を望むのか、安定性を望むのか、データの永続性を望むのか。
高速性重視
同一メーカー同一機種2台でストライピングを構成すると非常に高速になります。しかし、ストライピングはハードディスク一台が故障するとすべてのデータが消えてしまいます。しかも、故障確率はその2乗になります。3台のストライピングなら3乗。データの損失を防ぐためにミラーリングのような構成が必要になりますが非常に高価なものになります。高速性を重視したときにここで疑問が湧きます。そんなに高速性が必要ならネットワーク越しに使わなくてもいいのじゃないかと。少人数利用で、そんなにデータの移動を伴わなければ、ローカルのSSDに置けば遥かに高速になりますし、SSDの方が対故障性が良くなります。編集が終わった時点でNASに戻せば十分でしょう。たしかに、動画編集をチームで行うような使い方や高負荷なサーバー用途なら高速性能が問題になるのでしょうが、高速性が本当に必要なのかよく考えてみましょう。ハードディスクは必ず壊れます。より高性能より高安定なハードディスクを使用しましょう。
NAS用HDDといえば定番はこちらになるでしょう。ストレージメーカーはWesternDigitaが吸収合併してほぼ1社独占状態です。コスパ最高の容量がコレです。
安定性重視
高速性を重視すれば同一機種で揃えるのが一番ですが、高速性を犠牲にすれば同一機種にする必要はありません。同一機種同一ロットの場合、そのロットに問題があれば同じように壊れます。製造過程の問題、設計上の問題いずれもありえます。ある条件で壊れる不具合ならばその条件が発生したとき同時に壊れます。同時に壊れればミラーリングしていてもデータ損失は免れません。なので、他のロット・機種・ブランドをミックスすれば、その機種・ロット固有の問題を回避できます。新製品よりも発売から時間が経った『こなれた』製品が安心です。設計上の問題が製品に反映されるのに3ヶ月から半年かかるとして、それ以降のものがより安心です。ハードディスクは必ず壊れるものと考えれば、その壊れるタイミングさえずれていれば大丈夫なのでより安価なデスクトップ用のハードディスクを使用することも考えられます。いずれもRAID用よりも安くなっています。
データの永続性を重視
『データ消えては困る、ずっと残したい。』これ。。。社内や自宅で実現することは非常に難しいです。
なぜなら、壊れない機械はないからです。いずれは壊れる。いずれはデータが消える。データの永続性を考えればNASのバックアップを取るしかないのです。じゃあそのバックアップしたものは壊れないのか？じゃあ、バックアップのバックアップ？どう管理する？それも問題になります。NASの話をしていてNAS自体のバックアップが最終的に必要になるというのもなんとも悲しい話ではあります。
より安定した永続性が必要ならクラウドを使うしかないでしょう。多重にバックアップされたクラウドならその消失の心配が極限まで減少できます。費用対効果も良いでしょう。ただし、そのトレードオフとしてデータの流出漏洩の問題が浮上してきます。あと、クラウドで問題になるのはその会社の安定性でしょうか。クラウドに保存して安心していたら、その会社が消失してしまった。では笑い話にもなりません。
クラウドといえば次の3つが定番ではないでしょうか。
■最後に
さて、データのサルベージはうまくいきましたでしょうか。参考になりましたら幸いです。今まで、RAIDなNASは、破損・障害時のデータのサルベージが怖くて手を出せずにいましたが、なんとかなりそうな感触を得られました。今回この記事を書くに至ったのは、ネット上にあまたある情報のなかからこのような情報に至るのに意外と時間がかかったためです。私と同じようにネットで徘徊せざるを得なくなった方のためにも記事といたしました。専門の方々からすると間違った表現が多々あるとは思いますがご容赦ください。
ご参考：各ボリュームとマウント位置の構成
# df -T
ファイルシス タイプ 1K-ブロック 使用 使用可 使用% マウント位置
/dev/mapper/centos-root xfs 52403200 52339604 63596 100% /
devtmpfs devtmpfs 945344 0 945344 0% /dev
tmpfs tmpfs 958740 0 958740 0% /dev/shm
tmpfs tmpfs 958740 9012 949728 1% /run
tmpfs tmpfs 958740 0 958740 0% /sys/fs/cgroup
/dev/sda1 xfs 1038336 171268 867068 17% /boot
/dev/mapper/centos-home xfs 1895169916 33108 1895136808 1% /home
tmpfs tmpfs 191752 0 191752 0% /run/user/1000
/dev/mapper/vg1000-lv btrfs 3902185472 89191448 3810207096 3% /mnt/md0
tmpfs tmpfs 191752 0 191752 0% /run/user/0
