LinkStation LS-QL/1D という過去の名機を今も使っていますが数年使っているとHDDの寿命が来て、あちこち壊れます。
ヤバいのはHDDの中にはLinkStationのOS領域もあって、そこが経年劣化で壊れるパターンです。
これが起きるとEMモードにもならず、素人だと詰んでしまいます・・。
しかし、データがRAIDで残っているのであれば、Disk1に新品のHDDを入れて、状態の良いHDDをDisk2～Disk4に入れることで、データ領域をデグレードモードで復活させることが出来ます。
本記事では、Disk1をファームアップデータで新しく作り直してから、Disk1のOS領域をDisk2～Disk4にコピーさせ、Disk2～Disk4のデータ領域をDisk1にも反映させる・・という事を行っています。
現在の状況は、
Disk1: 新OS | 新データ領域
こうなっています。これを、以下のようにします。
Disk1: 新OS | 新データ領域
Disk2: 新OS | 旧RAID5領域
Disk3: 新OS | 旧RAID5領域
Disk4: 新OS | 旧RAID5領域
RAID5はDiskが3本あれば復旧できるので
Disk1: 新OS | 旧RAID5領域
Disk2: 新OS | 旧RAID5領域
Disk3: 新OS | 旧RAID5領域
Disk4: 新OS | 旧RAID5領域
最後は↑ここまで元に戻せるはずです。
本記事では各DiskのbootパーティションつまりOS部分に着目して、OSの完全復旧を行います。
LinkStationやTeraStationのOS領域がどうなっているか？については、以下の記事が私は参考になりました。
↓
TeraStationのしくみ - NAS-RESCUE
ファームアップデータによる復旧方法
LinkStation全体のOS領域の復旧を行う前に、Disk1に新品のHDDを入れて、そこに工場出荷状態に近いLinkStationのHDDイメージを作っておく必要があります。
それを行うのが「ファームアップデータ」というツールです。
バッファローの公式ホームページに掲載されています。
このファームアップデータを使ったDisk1の復旧方法を以下の記事に詳しく書いてありますので、まずはSTEP1としてお読み下さい。
LinkStation/TeraStationをtftpブートするには？【E06エラーからの復旧】
LinkStationによる自動Rebuild
前回の試行でLinkStationの物理的な故障も疑われたため、故障個所の特定のためにも、1つ1つ確認しながらLinkStationに搭載するDiskの本数を増やしていきます。
LinkStationにはRAIDの自動追加機能があるので、1本→2本→3本と搭載本数を増やしていけば、自動で直る可能性があります。
まず、ファーム復旧済のハードディスク×１本だけで立ち上げてみる。
⇒ 無事立ち上がった
Disk2の場所が壊れているのではと思い、同じハードディスクをDisk2に入れて立ち上げてみる。
⇒ 無事立ち上がった
データコピーして新しく導入したDisk2のハードディスクが嫌われているのではないかと思い、正規の位置に、Disk1とDisk3の２本を入れて立ち上げてみる。
⇒ 少し時間がかかったが「ディスクマウントエラー」のLEDパターンが出て、無事立ち上がった。
次にDisk1とDisk4の2本でも立ち上げてみる。
⇒ 無事立ち上がった
今の所はどのハードも壊れていないようですね。
そして、これまでに搭載した Disk3・Disk4 には状態に変化が見られるはずです。（LinkStationの自動Rebuild機能による）
RAID状態の確認
Disk1とDisk4が入った状態で、まだtelnetでログイン出来たので、状態をチェック。
# mdadm --detail /dev/md1
/dev/md1:
Version : 00.90.03
Creation Time : Thu Nov 1 00:01:39 2007
Raid Level : raid1
Array Size : 5004160 (4.77 GiB 5.12 GB)
Device Size : 5004160 (4.77 GiB 5.12 GB)
Raid Devices : 4
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Sat Jan 9 17:48:49 2016
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : 88682f1f:28b5e648:656dcf9a:e175b210
Events : 0.102262
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 0 0 1 removed
2 0 0 2 removed
3 8 18 3 active sync /dev/sdb2
# RAID1が構築されているようです。
面白いですね。ソフトRAIDってパーティション毎に異なるRAID方式を設定出来るんですね。
私の好きな以下のページにも書かれています。LinkStationのOS領域＝bootパーティションは、全てのハードディスクにRAID1でミラーリングされているそうです。
LinkStationのしくみ - LinkStation のデータ復旧サービス。24時間預かりで3.24万円から
Disk×3本の場合
続いて、正規の位置に、Disk1、Disk3、Disk4の3本を入れて立ち上げてみる。
⇒ 少し時間がかかったが「ディスクマウントエラー」のLEDパターンが出て、無事立ち上がった。
状態確認すると、3本入れたのにRAID1に2本しか組み込まれていませんでした。
そこで、以下のように追加します。
# mdadm --manage /dev/md0 --add /dev/sdc1
mdadm: re-added /dev/sdc1
#
# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Thu Nov 1 00:01:38 2007
Raid Level : raid1
Array Size : 1003904 (980.54 MiB 1028.00 MB)
Device Size : 1003904 (980.54 MiB 1028.00 MB)
Raid Devices : 4
Total Devices : 3
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Sat Jan 9 18:01:23 2016
State : clean, degraded, recovering
Active Devices : 2
Working Devices : 3
Failed Devices : 0
Spare Devices : 1
Rebuild Status : 84% complete
UUID : cf7a0362:4016643e:d481448c:f62e2cbd
Events : 0.1290
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
4 8 33 1 spare rebuilding /dev/sdc1
2 0 0 2 removed
3 8 17 3 active sync /dev/sdb1
# このやり方で、/dev/md0 も /dev/md1 も3本デグレードモードにします。
これで /boot と / (ルート) のパーティションが3本で同期された状態です。
/boot と /ルート が別々のRAIDになっているなんて、想像以上に複雑ですね。
Disk×4本の場合
で、最後に、正規の位置に4本全てを入れて立ち上げてみる。これで最後です。
⇒ ところが、なんと！ EMモードで立ち上がってしまった！ だめぢゃん！
4本だと立ち上がらないという、謎はまだ続きます・・・。
めげそうですが、EMモードになったらファームアップするしかありません。
4本入れたまま、ファームアップをかけます。
ファームアップはすんなり始まりました。
強制モードでは無いので、フォーマットするなどという脅しも無し（笑）。
何回か再起動を経て、無事立ち上がった。
しかし、システム領域が修復されてしまったために、telnetが出来なくなってしまいました。
LinkStationのRAID1を書き換えてみる
ハードディスクのアクセスランプを見る限り、システム領域は4本RAID1で同期されているようです。
（つまり / (ルート) のtelnetd起動の修正は4本とも消えているはずです）
それにしても、あっちがうまく行けばこっちがうまく行かず・・・結構大変です。
試しに今度は、Disk1とDisk2をパソコンにRAID1を組まずにxfsとして無理矢理マウントした後、telnetd の起動を書き込んで、またLinkStationに2本だけ戻して起動してみました。
⇒ この目論見は失敗です。
RAID1のチェックサムが働いたのか、無理矢理書き換えた事がバレて、再び「EMモード」になってしまいました。
RAIDのシステムに無理矢理は通用しないのか・・・トホホ。
ここで、ちょっと落ち着いて、まとめると、RAID1のハードディスクはRAID1としてマウントしてから、中身を書き換えないと、変更が有効にならないということです。
UbuntuでRAID1
仕方ないので、重い腰を上げて、4本のハードディスクを再びパソコンに全て繋いで立ち上げます。
DVDブートの軽いUbuntuなので、mdadmもsshも全て入れ直しです。
そして、ファームが入っている md0（=/boot） も、LinuxのOSが入っている md1 （=/ (root) ）も、4本全てrebuildしてから、中身を書き換えました。
主な手順は以下の通り。
# apt-get install mdadm
# mknod /dev/md0 b 9 0
# ls -l /dev/md0
brw-r--r-- 1 root root 9, 0 Jan 9 10:40 /dev/md0
# mknod /dev/md1 b 9 1
# mknod /dev/md2 b 9 2
# chmod 775 /dev/md*
# mdadm -A /dev/md0 /dev/sd[cd]1 --force --run
mdadm: /dev/md0 has been started with 2 drives (out of 4).
# mdadm -A /dev/md1 /dev/sd[cd]2 --force --run
mdadm: /dev/md1 has been started with 2 drives (out of 4).
# mkdir /mnt/md0
# mkdir /mnt/md1
# mount /dev/md0 /mnt/md0
# mount /dev/md1 /mnt/md1
# cd /mnt/md1/etc/init.d
# vi rcS/usr/sbin/telnetd & を最終行に追加します。
# cd /mnt/md1/etc/
# vi shadowroot のパスワード領域を以下のように潰しておきます。
root::16809:0:99999:7:::（ここでやっておかないと後でまた面倒なことになります）
# mdadm --manage /dev/md0 --add /dev/sda1
mdadm: re-added /dev/sda1
# mdadm --manage /dev/md0 --add /dev/sdb1
mdadm: added /dev/sdb1
# mdadm --manage /dev/md1 --add /dev/sda2
mdadm: added /dev/sda2
# mdadm --manage /dev/md1 --add /dev/sdb2
mdadm: added /dev/sdb2
#どんどんRAID1に追加していきます。
# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb2[4](S) sda2[5] sdd2[2] sdc2[3]
5004160 blocks [4/2] [__UU]
[=============>.......] recovery = 66.6% (3336704/5004160) finish=0.3min speed=84302K/sec
md0 : active raid1 sdb1[1] sda1[0] sdd1[2] sdc1[3]
1003904 blocks [4/4] [UUUU]
unused devices:
# 進行状況が表示されています。すぐ終わりそうですね。
次に、md0 には今までの残骸が残っていたので、fsck.ext3 を実行していらないファイルは消しました。
# umount /mnt/md0
# fsck.ext3 /dev/md0
e2fsck 1.42.9 (4-Feb-2014)
/dev/md0 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry 'u-boot.buffalo.fujimori' in / (2) has deleted/unused inode 11. Clear<y>? yes
Entry 'conf_save.tgz.fujimori' in / (2) has deleted/unused inode 16. Clear<y>? yes
Pass 3: Checking directory connectivity
/lost+found not found. Create<y>? yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(4419--4480) -(16384--16390)
Fix<y>? yes
Free blocks count wrong for group #0 (15661, counted=15730).
Fix<y>? yes
Free blocks count wrong (205706, counted=205775).
Fix<y>? yes
Inode bitmap differences: -16
Fix<y>? yes
Free inodes count wrong for group #0 (7852, counted=7854).
Fix<y>? yes
Free inodes count wrong (62956, counted=62958).
Fix<y>? yes
/dev/md0: ***** FILE SYSTEM WAS MODIFIED *****
/dev/md0: 18/62976 files (0.0% non-contiguous), 45201/250976 blocks
# sync
# mount /dev/md0 /mnt/md0
# ls -l /mnt/md0
total 155192
-rw-r--r-- 1 root root 26867 Jan 9 09:37 conf_save.tgz
-rw-r--r-- 1 root root 149001686 Jun 18 2009 hddrootfs.buffalo.updated.done
-rw-r--r-- 1 root root 7073595 Jun 18 2009 initrd.buffalo
-rw-r--r-- 1 root root 7432 Jan 9 09:37 log.tgz
drwx------ 2 root root 4096 Jan 9 11:03 lost+found
-rw-r--r-- 1 root root 245776 Jan 9 09:18 u-boot.buffalo
-rw-r--r-- 1 root root 245776 Oct 31 2007 u-boot.buffalo.org
-rw-r--r-- 1 root root 2120040 Jan 9 09:18 uImage.buffalo
# 綺麗になりました。
RAID5の状態確認
ついでに、md2 のRAID5のデータ領域が、/dev/sd[bcd]6 のデグレードモードで無事であることも確認しました。
（ちなみに/dev/sda6 はフォーマットがかかってしまっており、独立している状態です）
# mdadm -A /dev/md2 /dev/sd[bcd]6
mdadm: /dev/md2 has been started with 3 drives (out of 4).
# mdadm --detail /dev/md2
/dev/md2:
Version : 0.90
Creation Time : Sun Jun 21 17:07:49 2009
Raid Level : raid5
Array Size : 2906278656 (2771.64 GiB 2976.03 GB)
Used Dev Size : 968759552 (923.88 GiB 992.01 GB)
Raid Devices : 4
Total Devices : 3
Preferred Minor : 2
Persistence : Superblock is persistent
Update Time : Sat Jan 9 09:35:02 2016
State : clean, degraded
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : 82ca5ba8:77319326:bd54f990:2edf8a42
Events : 0.276
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 22 1 active sync /dev/sdb6
2 8 38 2 active sync /dev/sdc6
3 8 54 3 active sync /dev/sdd6
# mkdir /mnt/md2
# mount /dev/md2 /mnt/md2
# cd /mnt/md2
# ls
lpd shareフォルダが無事見えました。
これだけ完璧に構築しておけば、LinkStationに4本とも戻した時に、EMモードになることはありません。
RAID5の復活
パソコンをシャットダウンして、LinkStationに4本全て接続して、起動します。
無事、立ち上がりました！
もちろんディスクマウントエラーは出たままです。
状態を確認します。
・telnetからのログインは出来る
・RAID1は管理Webと同期が取れている
・RAID5は管理Webと同期が取れていない
では、最終形に向けてメンテナンスしましょう。
rootのパスワード設定
さすがにパスワード無しは危険すぎますので、rootのパスワードを設定しました。
本当は一般ユーザでログインして su または sudo で使いたいのですが、どうやっても無理でした。
新しいパッケージをインストールするのも、この独自OSでは無理でした。
/dev/sda6 のファイル共有・解除
Disk1（/dev/sda6）はRAID5のメンバにしなくてはならないので、管理Webの設定を開き、ファイル共有の対象から解除させておきます。
更にマウントも解除します。
# umount /mnt/disk1
/dev/sda6 をRAID5メンバに追加
Disk1（/dev/sda6）をRAID5のメンバに追加する手順は以下の通りです。
もう覚えましたよね。何度もやってるし。
# mdadm -A /dev/md2 /dev/sd[bcd]6
# mdadm --detail /dev/md2
# mdadm --manage /dev/md2 --add /dev/sda6
# mdadm --detail /dev/md2
# cat /proc/mdstat
# mount /dev/md2 /mnt/array2RAID5フォルダをsambaで共有
出来上がったRAID5のフォルダをsambaで共有します。
これには、元々入っていた設定を参考にしました。
# cd /etc/samba/
# vi smb.conf以下の行を追加しました。
[share]
comment = Share
path = /mnt/array2/share
browsable = yes
printable = no
writable = yes
guest ok = yes
force create mode = 666
force directory mode = 777
csc policy = manual
vfs objects = recycle, audit
recycle:repository = trashbox
recycle:keeptree = 1
recycle:versions = 1
recycle:directory_mode = 777
audit:facility = LOCAL6
audit:priority = INFO
###share###あとは smbd と nmbd を刺激すれば完成です。
# ps | grep smb
# kill -1 967
# ps | grep nmb
# kill -1 979これでパソコンから読めるようになります。
まずは復活！ おめでとう！
Windows10にアップグレードしたら、LinkStationのHDDが壊れて立ち上がらなくなり、パソコンからLinuxの機能を駆使して完全復旧させた私の体験の一部始終を読みたい方は、以下の記事から進んで下さい。
コメント