treedown’s Report

システム管理者に巻き起こる様々な事象を読者の貴方へ報告するブログです。会社でも家庭でも"システム"に携わるすべての方の共感を目指しています。

※https化しました。その影響でしばらくリンク切れなどがあるかもしれませんが徐々に修正していきます。 リンク切れなどのお気づきの点がございましたらコメントなどでご指摘いただけますと助かります。

Raspberry Pi外付けHDDが見えなくなる

ある日、突然Raspberry PiにUSB接続していた外付けHDDが見えなくなるという症状に遭遇しましたのでご報告です。

突如HDD消失

ある日、ユーザからRaspberry Piのsambaで共有しているフォルダが見えなくなった、という話を受けて調査を実施することにしました。
最初は「(共有フォルダ内の)データが消えたんじゃ?」という話だったのですが、調べていくうちに消えたわけではなさそう。

調べる

調べると、OSからHDDのボリュームが見えなくなっているようでした。syslogには

systemd[1]: smbadd2.mount: Unit is bound to inactive unit dev-disk-by%UUID%.device. Stopping, too.

これが何行も続いて記録された後、

systemd[1]: smbadd2.mount: Unit is bound to inactive unit dev-disk-by%UUID%..device, but not stopping since we tried this too often recently.

その後、

kernel: [1...] EXT4-fs error (device sdc): ext4_find_entry:1463: inode #154140673: comm smbd: reading directory lblock 0

の後に

kernel: [1...] EXT4-fs warning (device sdc): htree_dirblock_to_tree:962: inode #154140673: lblock 0: comm smbd: error -5 reading directory block

これがずっと記録されるようになり、HDDのボリュームにはアクセス出来ないようになっていました。
うーん。見たことない。

別の環境で

その場では修復できなかったので、別のLinux環境(Linux Mint)に接続して調べることにしました。

HDDのUSB端子をPCに接続すると、エラーが、

f:id:treedown:20210222172755p:plain

「Error mounting /dev/sdd at /media/%username%/%UUID%: can't read superblock on /dev/sdd」と表示されています。うーん。
試しに「fdisk -l」コマンドで一覧を表示してみると、

Disk /dev/sdd: 2.7 TiB, 3000592976896 bytes, 5860533158 sectors

と、表示されるのでHDD自体の故障ではなさそう?
マウントをしていない(というかmountで失敗している)ので、dfコマンドで一覧を表示してみれば、そこにはsddが表示されません。

探してみると

mountしようとすると、can't read superblockと表示される。 - Qiita

にて紹介されていた内容と同一のように思えてきました。(ログはちょっと違うかもだけど)

問題が起きたHDDのデータは既にバックアップ済で、別のファイルサーバ(sambaサーバ)にデータリストア済だったため、最悪このHDDのデータは欠損してしまっても大丈夫。
ここは思い切ってやってみることにしました。

/dev/sddを修復してみる

さっそく試してみます。
紹介されていたコマンドはまず「mkfs ext4 -n /dev/sdd」(rootで実行)です。(※「/dev/sddの部分はOSで認識しているデバイスによって変わるので、適宜読み替える必要があります。)

f:id:treedown:20210222172845p:plain
--------------------------------------------------------------
$ sudo mkfs ext4 -n /dev/sdd
mke2fs 1.44.1 (24-Mar-2018)
/dev/sdd contains a ext4 file system
last mounted on /home/smb on Sun Sep 13 17:53:16 2020
Proceed anyway? (y,N) y
Creating filesystem with 732566644 4k blocks and 183148544 inodes
Filesystem UUID: 5dce0000-0000-0000-0000-000000000000
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544
--------------------------------------------------------------
途中で「Proceed anyway? (y,N) 」と聞かれるので(y)を入力して進めます。
実行すると最後には「Superblock backups stored on blocks: 」と表示され、superblockらしき数字が複数表示されました。
これが破損したsuperblock?これが問題でマウントできないんでしょうか。

続けて「fsck /dev/sdd -p」で修復

f:id:treedown:20210222172902p:plain
--------------------------------------------------------------
$ sudo fsck /dev/sdd -p
fsck from util-linux 2.31.1
/dev/sdd: recovering journal
JBD2: Invalid checksum recovering block 10 in log
Journal checksum error found in /dev/sdd
/dev/sdd was not cleanly unmounted, check forced.
/dev/sdd: 20342/183148544 files (1.1% non-contiguous), 36448303/732566644 blocks
--------------------------------------------------------------
この処理、しばらく時間が掛かるのですが、fsckでの修復が完了してから、再度USBを抜き差しして、HDDを接続し直すと、無事OSから外付けHDDが提供するボリュームにアクセスでき、保管されているデータを参照することができました。

最終的に、このfsckで修復して復旧できたと判断し、本番環境に修復したHDDを戻すようにします。(まだ戻していないけど)