【xfs_repair】RAID5を使ったファイルシステムの修復【Ubuntu】

2021年2月12日

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の機能を駆使して完全復旧させた私の体験の一部始終を読みたい方は、以下の記事から進んで下さい。

故障したLinkStationから自力でデータ復旧した方法