Windows10からアクセスしているうちに、壊れてしまったLinkStation。
前回はRAID5のRebuildを行いました。
Rebuildは結構時間がかかります。小一時間くらいはかかりました。
で、これが終わると、ハードディスク×4本のRAID5の完成です。
# mdadm --examine /dev/sdb6
＜中略＞
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Checksum : 69dc78bf - correct
Events : 84
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 1 8 22 1 active sync /dev/sdb6
0 0 8 6 0 active sync /dev/sda6
1 1 8 22 1 active sync /dev/sdb6
2 2 8 38 2 active sync /dev/sdc6
3 3 8 54 3 active sync /dev/sdd6
#この通り。
しかし、これではまだ、ファイルは読めません。セクタ単位で失われた部分がありますので、ファイルシステムの修復が必要となります。
ファイルシステムの修復の事をrepairと言います。本記事では、そのrepairについて説明します。
LinkStationのrepair方法
LinkStationのデータ部分のファイルシステムは xfs という形式です。つまり、/dev/md2 が xfs で出来ているのです。
xfs を修復するコマンドは xfs_repair です。
xfs_repair にはシミュレーションモードがあり、xfs_repair -n /dev/md2 と打つと、どれくらいの修復が必要かを全て表示してくれます。
私は、試しに、最も損傷の多かった /dev/sdb6 を除いて、デグレードモードの状態で xfs_repair -n を行わせてみて、4本RAIDの時と比べてみました。
結果は数行の差。誤差範囲です。
・・ということは、ハードディスク×4本のRAID5にせずに、ハードディスク×3本のデグレードモードのままファイルシステム修復⇒データのサルベージという流れでも同じ量のサルベージが出来たということになります。
プログラムまで作って4本RAIDを作ったあの苦労も、実は、そんなに意味が無かったのです（汗）。
まあ、気を取り直して、修復を始めましょう。
xfs_repairの実行
折角なので、4本RAID5にしてから、xfs_repairを実行しました。
# xfs_repair /dev/md2
＜中略＞
disconnected inode 536880185, would move to lost+found
disconnected inode 536881928, would move to lost+found
disconnected inode 536881930, would move to lost+found
disconnected inode 536881931, would move to lost+found
disconnected inode 536881932, would move to lost+found
disconnected inode 536881933, would move to lost+found
disconnected inode 536881934, would move to lost+found
disconnected inode 536881935, would move to lost+found
disconnected inode 536881936, would move to lost+found
disconnected inode 536881937, would move to lost+found
disconnected inode 536881938, would move to lost+found
disconnected inode 536881939, would move to lost+found
disconnected inode 536881940, would move to lost+found
disconnected inode 536881941, would move to lost+found
Phase 7 - verify and correct link counts...
resetting inode 256 nlinks from 2 to 3
resetting inode 259 nlinks from 2 to 5
resetting inode 1610612992 nlinks from 30 to 29
resetting inode 3758096640 nlinks from 8 to 7
done
#この時、沢山表示されればされる程、データの破損が沢山あるということです。
xfs_repairは結構一瞬で終わります。1～2分。
Rebuildが時間がかかっていただけに、あっという間に終わる印象です。
arrayデバイスのマウント
repairが終わったようなので、マウントします。
# mount -t xfs /dev/md2 /mnt/array2
# cd /mnt/array2/
# ls
lost+found
#驚きました。
ファイルが全部 lost+found に移動してしまっています。これは酷い！（笑）
では、その lost+found に移動して中を見てみましょう。
# cd lost+found/
# ls
10020 279 298 317 336 357 3758096703 3758099754 377 397 416 424 440
＜中略＞
# ls -l
＜中略＞
-rwxrw-rw- 1 1000 users 218174728 Jan 17 2008 1580
-rwxrw-rw- 1 1000 users 208241078 Jan 16 2008 1581
drwxrwxrwx 29 root root 4096 Nov 14 14:45 1610612992
-rwxrw-rw- 1 99 99 209063082 Feb 14 2007 272
-rwxrw-rw- 1 99 99 132689408 Mar 19 2003 273
＜中略＞
# ls 1610612992
mp3 samazama trashbox music SEKAINOOWARI doc images
VAIO iPhone PV
#開いても開いても数字のファイルしか無かったらどうしよう？ と思いましたが、やっと数字以外の見慣れた文字列が出てきました。
失われていたファイル達です。
フォルダごと、結構深いところまで、移動していたようです。
しかし、何だか分からないファイルも沢山あるし、元に戻すのは大変そうです。
細かな問題を、次の記事以降で直していきます。
この続き ⇒ BootableのUbuntuで日本語が出ない（文字化けする）場合の対処法【locale】
Windows10にアップグレードしたら、LinkStationのHDDが壊れてEMモードにすらならずにハマってしまったけれど、Linuxの機能を駆使して完全復旧させた私の体験の一部始終を読みたい方は、以下の記事から進んで下さい。
コメント