1. はじめに
2013年11月に交換(設置)したUSBハードディスク(USB-HDD)は、37型の液晶テレビ(東芝レグザREGZA)の録画用として、我が家の居間で動作していました。が、このところ、どうも録画に飛びが発生したり、予約した番組がきちんと録画されていなかったりと、怪しい動きをしていたのです。
このUSBハードディスクの機種に交換(設置)してから5年半が経過したため、そろそろ寿命かな？と考えていた矢先に、突然、「ハードディスクを認識しない」という現象が発生しました。
取説(取扱説明書)を見ながら、テレビ側の設定をいろいろ調べてみたのですが、どうもうまくいきません。
しかし、このまま放っておくわけにもいかず、しかたなく、新しいUSBハードディスク(USB-HDD)を買いに、近くの家電量販店まで足を伸ばしたのでありました。
☆ ☆ ☆
さて、取り外したUSBハードディスクは、ひとまず、そのままにしておいたのですが、以前、同じように故障した録画用のUSBハードディスクを、PCに接続して、その状態を確認したこと [1] を思い出し、今回も、「ダメ元」で、同じ手順で状態を確認したときに、どうなるかを実際に確認してみることとしました。
その結果、運良くというか、ハードディスクのファイルを修復し、USBハードディスクをテレビに接続して再び録画・再生をすることができました。
この記事では、テレビ録画用に接続した外付けUSBハードディスク(USB-HDD)の修復・復旧について試みた方法と手順を簡単なメモ書きですが、紹介します。
(ただし、必ずしもうまくいくとは限らないので、その点はご了解下さい。このような修復・復旧作業を実施される場合は、自己責任で実施されるようお願いします。)
2. 確認手順の概略
(1) Linuxパソコン(PC)を準備する
(2) USB-HDDをマウントし、マウントボイントを確認する
(3) USB-HDDをアンマウントし、ディスクチェックを行なう
(4) USB-HDDのディスクファイルの修復を行なう
(5) USB-HDDを再度マウントしてファイルのリストを確認する
(6) 再度アンマウントしてディスクチェックを行なう
これだけですが、(4)の作業でエラーになるか、ならないかがひとつの鍵になります。ちなみに、以前に書いた記事[1]の場合は、ここでNG(修復不能)と判断しました。
3. パソコン(PC)で外付けUSBハードディスク(USB-HDD)の状態を確認する
準備するものは、Linuxを起動できるパソコン(PC)と故障した(？)外付けUSBハードディスク(USB-HDD)とUSB接続ケーブルです。
液晶テレビ(東芝レグザREGZA)に接続されるUSBハードディスクのファイルフォーマットは
xfs形式になります。一般に使用されているWindowsパソコンでは、このxfsフォーマットのドライブやファイルを認識できません。したがって、Linuxを起動できるパソコン(PC)が必要なのです。
必ずしもPC本体にLinuxがインストールされていなくても、CD-ROMドライブなどから起動用CDなどでLinuxを起動できるのであれば問題ないとおもわれます。
(私自身のPCは、WindowsとLinuxのデュアルブートに設定してあるので、Linuxで起動しています。)
CDからLinuxを起動する方法は、ここでは触れませんが、[2]などを参考にして、起動用CDの作成、パソコン(PC)のCD-ROMドライブからの起動を行なって下さい。
以下、私の環境では、パソコン(PC)は東芝dynabook(PB552FEA127A51)、OSはLinuxでFedora29(64bit)、を使用しています。
まず、パソコンに外付けUSBハードディスク(USB-HDD)を接続します。
この状態で、外付けUSBハードディスクが認識されているかどうかを確認します。
デスクトップ上に、該当するハードディスクのアイコンが表示されれば、認識され、
マウントされている状態になっています。
そうなっていない場合は、アプリケーションのシステムツールで、ディスク使用量アナライザを起動し、該当のハードディスクが存在するかを確認します。
次に、どのデバイスファイルにマウントされているかという、マウントポイントを確認します。例えば、/dev/sdb1 などになります。
以下はコマンド操作になりますので、コマンドライン端末(ターミナル)ウィンドウを開いて、管理者権限でコマンドを打ち込みます。
次に、いったんアンマウント(マウントを解除)して、ハードディスクの状態チェックを行います。使用するコマンドは、
umount /dev/sdb1
xfs_repair -n /dev/sdb1 ( または xfs_check /dev/sdb1 )
です。
すると、次のような表示がでてきました。
[root@localhost user01]# umount /dev/sdb1
[root@localhost user01]# xfs_repair -n /dev/sdb1
Phase 1 - find and verify superblock...
- reporting progress in intervals of 15 minutes
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
bad magic # 0x6e93bf6a in inobt block 16/3
expected level 0 got 36345 in inobt block 16/3
dubious inode btree block header 16/3
bad starting inode # (7860674304 (0x10 0xd4885f00)) in inobt rec, skipping rec
badly aligned inobt rec (starting inode = 8172778468)
bad starting inode # (8172778468 (0x10 0xe722b3e4)) in inobt rec, skipping rec
badly aligned inobt rec (starting inode = 6410804566)
bad starting inode # (6410804566 (0x10 0x7e1d1d56)) in inobt rec, skipping rec
badly aligned inobt rec (starting inode = 7195546658)
--- (途中、省略) ---
bad starting inode # (4750678384 (0x10 0x1b299970)) in inobt rec, skipping rec
badly aligned inobt rec (starting inode = 4502697197)
ir_freecount/free mismatch, inode chunk 16/207729901, freecount 1704223958 nfree 33
badly aligned inobt rec (starting inode = 5277979757)
bad starting inode # (5277979757 (0x10 0x3a97946d)) in inobt rec, skipping rec
badly aligned inobt rec (starting inode = 6257491054)
--- (途中、省略) ---
bad starting inode # (4976999758 (0x10 0x28a6fd4e)) in inobt rec, skipping rec
badly aligned inobt rec (starting inode = 4315432406)
ir_freecount/free mismatch, inode chunk 16/20465110, freecount 107526891 nfree 34
badly aligned inobt rec (starting inode = 6034583137)
bad starting inode # (6034583137 (0x10 0x67b06e61)) in inobt rec, skipping rec
badly aligned inobt rec (starting inode = 5675287099)
--- (途中、省略) ---
bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec
badly aligned inobt rec (starting inode = 4294967296)
bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec
agi_count 0, counted 16320 in ag 16
agi_freecount 0, counted 2400232718 in ag 16
sb_icount 1408, counted 17728
sb_ifree 250, counted 19580102152
sb_fdblocks 52700857, counted 52709049
- 21:34:45: scanning filesystem freespace - 32 of 32 allocation groups done
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
found inodes not in the inode allocation tree
- 21:34:45: scanning agi unlinked lists - 32 of 32 allocation groups done
- process known inodes and perform inode discovery...
- agno = 30
- agno = 0
- agno = 15
--- (途中、省略) ---
- agno = 13
- agno = 14
- 21:34:53: process known inodes and inode discovery - 1408 of 1408 inodes done
- process newly discovered inodes...
- 21:34:53: process newly discovered inodes - 32 of 32 allocation groups done
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- 21:34:53: setting up duplicate extent list - 32 of 32 allocation groups done
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
--- (途中、省略) ---
- agno = 30
- agno = 31
- 21:34:53: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done
No modify flag set, skipping phase 5
Inode allocation btrees are too corrupted, skipping phases 6 and 7
No modify flag set, skipping filesystem flush and exiting.
[root@localhost user01]#
これで、一応、ハードディスクの状態確認ができたことになります。最後のほうに、「iノード割り当てBツリーが破損しているため、フェーズ6と7をスキップします。変更フラグを設定せず、ファイルシステムのフラッシュをスキップして終了します。」のメッセージで終わってしまいましたが、これは、ファイルの一部が破損していることを示しています。
4. 外付けUSBハードディスク(USB-HDD)のディスクファイルの修復を行なう
次に、修復できるかどうかをやってみました。使用するコマンドは、
xfs_repair -Lv /dev/sdb1
です。
ここで、以前経験したような fatal error が出現したら、物理的な故障なので、
どうしようもありません。
今回は、次のような表示がでてきました。
[root@localhost user01]#
xfs_repair -Lv /dev/sdb1
Phase 1 - find and verify superblock...
- reporting progress in intervals of 15 minutes
- block cache size set to 332184 entries
Phase 2 - using internal log
- zero log...
zero_log: head block 199805 tail block 199805
- scan filesystem freespace and inode maps...
bad magic # 0x6e93bf6a in inobt block 16/3
expected level 0 got 36345 in inobt block 16/3
dubious inode btree block header 16/3
bad starting inode # (7860674304 (0x10 0xd4885f00)) in inobt rec, skipping rec
badly aligned inobt rec (starting inode = 8172778468)
bad starting inode # (8172778468 (0x10 0xe722b3e4)) in inobt rec, skipping rec
badly aligned inobt rec (starting inode = 6410804566)
--- (途中、省略) ---
ir_freecount/free mismatch, inode chunk 16/73979246, freecount 889473186 nfree 31
badly aligned inobt rec (starting inode = 7924286411)
bad starting inode # (7924286411 (0x10 0xd85303cb)) in inobt rec, skipping rec
badly aligned inobt rec (starting inode = 6393507745)
--- (途中、省略) ---
bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec
agi_count 0, counted 16320 in ag 16
agi_freecount 0, counted 2400232718 in ag 16
sb_icount 1408, counted 17728
sb_ifree 250, counted 19580102152
sb_fdblocks 52700857, counted 52709049
- 21:37:17: scanning filesystem freespace - 32 of 32 allocation groups done
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
found inodes not in the inode allocation tree
- 21:37:17: scanning agi unlinked lists - 32 of 32 allocation groups done
- process known inodes and perform inode discovery...
- agno = 0
- agno = 15
--- (途中、省略) ---
- agno = 14
- 21:37:25: process known inodes and inode discovery - 1408 of 1408 inodes done
- process newly discovered inodes...
- 21:37:25: process newly discovered inodes - 32 of 32 allocation groups done
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- 21:37:25: setting up duplicate extent list - 32 of 32 allocation groups done
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
--- (途中、省略) ---
- agno = 26
- 21:37:25: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done
Phase 5 - rebuild AG headers and trees...
- agno = 0
- agno = 1
--- (途中、省略) ---
- agno = 31
- 21:37:25: rebuild AG headers and trees - 32 of 32 allocation groups done
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- agno = 0
--- (途中、省略) ---
- agno = 31
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
- 21:37:25: verify and correct link counts - 32 of 32 allocation groups done
XFS_REPAIR Summary Tue Apr 30 21:37:25 2019
Phase Start End Duration
Phase 1: 04/30 21:37:06 04/30 21:37:06
Phase 2: 04/30 21:37:06 04/30 21:37:17 11 seconds
Phase 3: 04/30 21:37:17 04/30 21:37:25 8 seconds
Phase 4: 04/30 21:37:25 04/30 21:37:25
Phase 5: 04/30 21:37:25 04/30 21:37:25
Phase 6: 04/30 21:37:25 04/30 21:37:25
Phase 7: 04/30 21:37:25 04/30 21:37:25
Total run time: 19 seconds
done
[root@localhost user01]#
今回は、Phase1、Phase2、・・・、Phase7 と進んでいき、終了した(「done」)との表示でした。
もしも、この操作の実行中に、
Phase 1 – find and verify superblock…
superblock read failed, offset 0, size 524288, ag 0, rval -1
.
fatal error — 入力/出力エラーです
のような表示が出た場合は、それはハードディスクの物理的な故障なので、どうしようもありません。
5. 外付けUSBハードディスク(USB-HDD)のファイルリストの確認と再度のディスクチェックを行なう
さて、これで修復されたとのことなので、ファイルの存在と状態を確認してみました。いったん、再度マウントを行ないます。
デスクトップ上に、該当するハードディスクのアイコンが表示されれば、マウントされている状態になっていますが、そうなっていない場合は、アプリケーションのシステムツールで、ディスク使用量アナライザを起動し、該当のハードディスクを確認します。(クリックすればマウントされます。)
今回の場合、
/dev/sdb1
のマウントポイントは、
/run/media/user01/e4f007b8-c779-4d7a-a2db-34c15c363213
でした。
そのディレクトリまで進み、ファイルの存在状態を確認しました。
[root@localhost user01]#
cd /run/media/user01
[root@localhost user01]#
ls
e4f007b8-c779-4d7a-a2db-34c15c363213
[root@localhost user01]#
cd e4f007b8-c779-4d7a-a2db-34c15c363213
コマンドは「ls -al」です。
[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]#
ls -al
合計 1742544948
drwxr-xr-x. 3 root root 53248 4月 30 12:30 .
drwxr-x---+ 3 root root 60 4月 30 21:46 ..
-rw-r--r--. 1 root root 82344 4月 30 12:30 .toshiba_dir_info_e89d874cd80a
-rw-r--r--. 1 root root 4760 4月 30 11:59 .toshiba_serieslist_e89d874cd80a
-rw-r--r--. 1 root root 268 4月 30 12:30 .toshiba_size_info_e89d874cd80a
drwxr-xr-x. 7 root root 109 11月 6 2014 .toshibazze89d874cd80a
--wsr-sr-t. 1 root root 7052292288 11月 14 2013 M000020131114195750e89d874cd80a.dtv
-rw-r--r--. 1 root root 1760 4月 27 15:20 M000020131114195750e89d874cd80a.dtv.meta
-rw-r--r--. 1 root root 80778 11月 14 2013 M000020131114195750e89d874cd80a.dtv.rat
--wsr-sr-t. 1 root root 5232187584 11月 27 2013 M000020131127195950e89d874cd80a.dtv
-rw-r--r--. 1 root root 1760 2月 24 14:52 M000020131127195950e89d874cd80a.dtv.meta
-rw-r--r--. 1 root root 65826 11月 27 2013 M000020131127195950e89d874cd80a.dtv.rat
--- (途中、省略) ---
--wsr-sr-t. 1 root root 2524987584 4月 30 12:00 M000020190430115950e89d874cd80a.dtv
-rw-r--r--. 1 root root 1760 4月 30 12:00 M000020190430115950e89d874cd80a.dtv.meta
-rw-r--r--. 1 root root 41046 4月 30 12:30 M000020190430115950e89d874cd80a.dtv.rat
[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]#
[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]#
cd .toshibazze89d874cd80a
[root@localhost .toshibazze89d874cd80a]#
ls -al
合計 108
drwxr-xr-x. 7 root root 109 11月 6 2014 .
drwxr-xr-x. 3 root root 53248 4月 30 12:30 ..
drwxr-xr-x. 2 root root 8192 4月 29 16:00 aeef0000000
drwxr-xr-x. 2 root root 8192 4月 30 12:30 aeef0000001
drwxr-xr-x. 2 root root 4096 4月 27 15:22 aeef0000002
drwxr-xr-x. 2 root root 4096 4月 30 12:30 alkf
-rw-r--r--. 1 root root 12 11月 4 2013 bid.bin
-rw-r--r--. 1 root root 80 11月 4 2013 did.bin
drwxr-xr-x. 2 root root 97 4月 22 10:59 log
[root@localhost .toshibazze89d874cd80a]#
[root@localhost .toshibazze89d874cd80a]#
cd log
[root@localhost log]#
ls -al
合計 188
drwxr-xr-x. 2 root root 97 4月 22 10:59 .
drwxr-xr-x. 7 root root 109 11月 6 2014 ..
-rw-r--r--. 1 root root 51200 3月 17 22:59 00000064.dat
-rw-r--r--. 1 root root 51200 4月 6 10:33 00000065.dat
-rw-r--r--. 1 root root 51200 4月 22 10:59 00000066.dat
-rw-r--r--. 1 root root 27008 4月 30 12:30 00000067.dat
-rw-r--r--. 1 root root 11 4月 22 10:59 info.dat
[root@localhost log]#
[root@localhost log]#
cd ..
[root@localhost .toshibazze89d874cd80a]#
cd alkf
[root@localhost alkf]#
ls -al
合計 60
drwxr-xr-x. 2 root root 4096 4月 30 12:30 .
drwxr-xr-x. 7 root root 109 11月 6 2014 ..
-rw-r-----. 1 root root 4144 4月 29 16:00 alc0000000.bin
-rw-r-----. 1 root root 4144 4月 29 16:00 alc0000000.buc
-rw-r-----. 1 root root 4144 4月 30 12:30 alc0000001.bin
-rw-r-----. 1 root root 4144 4月 30 12:30 alc0000001.buc
-rw-r-----. 1 root root 4144 4月 27 15:22 alc0000002.bin
-rw-r-----. 1 root root 4144 4月 27 15:22 alc0000002.buc
-rw-r--r--. 1 root root 32 11月 4 2013 ald.bin
-rw-r-----. 1 root root 32 11月 4 2013 alk.bin
[root@localhost alkf]#
[root@localhost alkf]#
cd ..
[root@localhost .toshibazze89d874cd80a]#
ls -al
合計 108
drwxr-xr-x. 7 root root 109 11月 6 2014 .
drwxr-xr-x. 3 root root 53248 4月 30 12:30 ..
drwxr-xr-x. 2 root root 8192 4月 29 16:00 aeef0000000
drwxr-xr-x. 2 root root 8192 4月 30 12:30 aeef0000001
drwxr-xr-x. 2 root root 4096 4月 27 15:22 aeef0000002
drwxr-xr-x. 2 root root 4096 4月 30 12:30 alkf
-rw-r--r--. 1 root root 12 11月 4 2013 bid.bin
-rw-r--r--. 1 root root 80 11月 4 2013 did.bin
drwxr-xr-x. 2 root root 97 4月 22 10:59 log
[root@localhost .toshibazze89d874cd80a]#
cd aeef0000000
[root@localhost aeef0000000]#
ls -al
合計 520
drwxr-xr-x. 2 root root 8192 4月 29 16:00 .
drwxr-xr-x. 7 root root 109 11月 6 2014 ..
-rw-r--r--. 1 root root 80 8月 28 2018 aee00000000.bin
-rw-r--r--. 1 root root 80 3月 7 2017 aee00000001.bin
-rw-r--r--. 1 root root 80 6月 25 2014 aee00000002.bin
--- (途中、省略) ---
-rw-r--r--. 1 root root 80 2月 15 2017 aee0000007e.bin
-rw-r--r--. 1 root root 80 3月 1 2017 aee0000007f.bin
[root@localhost aeef0000000]#
[root@localhost aeef0000000]#
cd ../aeef0000001
[root@localhost aeef0000001]#
ls -al
合計 500
drwxr-xr-x. 2 root root 8192 4月 30 12:30 .
drwxr-xr-x. 7 root root 109 11月 6 2014 ..
-rw-r--r--. 1 root root 80 12月 5 20:15 aee00000080.bin
-rw-r--r--. 1 root root 80 8月 5 2015 aee00000081.bin
--- (途中、省略) ---
-rw-r--r--. 1 root root 80 12月 3 2017 aee000000ff.bin
[root@localhost aeef0000001]#
[root@localhost aeef0000001]#
cd ../aeef0000002
[root@localhost aeef0000002]#
ls -al
合計 140
drwxr-xr-x. 2 root root 4096 4月 27 15:22 .
drwxr-xr-x. 7 root root 109 11月 6 2014 ..
-rw-r--r--. 1 root root 80 2月 27 20:15 aee00000101.bin
-rw-r--r--. 1 root root 80 3月 3 23:25 aee00000103.bin
--- (途中、省略) ---
-rw-r--r--. 1 root root 80 5月 14 2018 aee00000137.bin
[root@localhost aeef0000002]#
以上のように、修復されたファイルの状態を確認することができました。
最後に、もう一度、アンマウント(マウントを解除)して、ハードディスクの状態チェックを実施しました。使用するコマンドは、
umount /dev/sdb1
xfs_repair -n /dev/sdb1
です。
[root@localhost ~]#
umount /dev/sdb1
[root@localhost ~]#
xfs_repair -n /dev/sdb1
Phase 1 - find and verify superblock...
- reporting progress in intervals of 15 minutes
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
sb_fdblocks 52700857, counted 52709049
- 22:13:57: scanning filesystem freespace - 32 of 32 allocation groups done
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- 22:13:57: scanning agi unlinked lists - 32 of 32 allocation groups done
- process known inodes and perform inode discovery...
- agno = 0
- agno = 15
--- (途中、省略) ---
- agno = 14
- 22:14:05: process known inodes and inode discovery - 1408 of 1408 inodes done
- process newly discovered inodes...
- 22:14:05: process newly discovered inodes - 32 of 32 allocation groups done
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- 22:14:05: setting up duplicate extent list - 32 of 32 allocation groups done
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 2
--- (途中、省略) ---
- agno = 31
- agno = 1
- 22:14:05: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
- 22:14:05: verify and correct link counts - 32 of 32 allocation groups done
No modify flag set, skipping filesystem flush and exiting.
[root@localhost ~]#
特に、問題はなさそうです。
この状態の外付けUSBハードディスク(USB-HDD)を液晶テレビ(東芝レグザREGZA)のUSB録画端子に接続して状態を確認したところ、再び録画・再生をすることができました。
6. まとめ
以上、テレビ録画用に接続した外付けUSBハードディスク(USB-HDD)の修復・復旧について
試みた方法と手順を簡単なメモ書きですが、紹介しました。
(ただし、必ずしもうまくいくとは限らないので、その点はご了解下さい。このような修復・復旧作業を実施される場合は、自己責任で実施されるようお願いします。)
------------------------------------------------------------------
References
[1]
液晶テレビに接続したUSBハードディスクの故障と対策 (2013/11/10)
[2]
「HDD認識しない」パソコンでレグザUSBハードディスクを復旧・修復 – レグザREGZA研究 (2014/09/28)
------------------------------------------------------------------
(2019-5-2)
