実家のおもいでばこが壊れた。
おもいでばこを起動すると、AndroidのCLIっぽい画面が出てきて、ブートループに入ってしまう。
すでに数年経過しているおもいでばこなので、どこかがもうダメになっているんだと思う。
保証も効かないし、修理しようとしても新品買うのと同じような金額を請求されるのがわかっているので、修理はあきらめる。
ただ、その前にデータサルベージはしておきたい。
おもいでばこのデータサルベージについてはあまり情報がないので、せっかくだから分解→HDDをPC接続→データサルベージの一連をここに記録してみる。
1. おもいでばこ分解
ねじが止まっていないのでピックなどでこじ開けるしかないが、背面パネル(電源とかHDMIとかある面)の内部にねじがあるので、そのねじは外しておく必要がある。筐体は完全に破壊していいのであれば気にしないでOK。
裏面パネルは両面テープでがっちり接着されているので、再生不可覚悟ではがしてねじを外す。
その後、ピックや不要なカードなどを使って分解する。がっちり爪ではまっているので爪破壊は覚悟(もとより復旧させるつもりはないが)。
分解すれば、あとはHDDが見えてくるのでねじを外してHDDを分離。9mm厚の2.5インチ SATA HDDです。
2. HDDマウント(PowerShellでの作業)
パーティションは4つで、最後のパーティションが本命のデータパーティション。
FAT32,NTFSじゃないのでWindowsでは開けない(ext4)。
ただ、今はWSLという強い味方がいる。これがいればわざわざLinux PC等を準備する必要もない。
Powershellを管理者で起動し、
DeviceIDを確認
該当Deviceのパーティションをwslでマウント
を行う。
PS C:\Users\admin> GET-CimInstance -query "SELECT * from Win32_DiskDrive"
DeviceID Caption Partitions Size Model
-------- ------- ---------- ---- -----
\\.\PHYSICALDRIVE0 ******************* 3 256052000000 SSSTC
\\.\PHYSICALDRIVE1 ******************* 1 1024200000000 ADATA
\\.\PHYSICALDRIVE2 ST2000LM 003 HN-M201RAD SCSI Disk Device 4 2000390000000 ST2000LM 003 HN-M201RAD SCSI Disk Device
今回接続したものの場合、「\.\PHYSICALDRIVE2」が該当のDeviceID。
これのPartition 4をマウントする。
PS C:\Users\admin> wsl --mount \\.\PHYSICALDRIVE2 --partition 4
ディスクは '/mnt/wsl/PHYSICALDRIVE2p4' として正常にマウントされました。
注: /etc/wsl.conf で automount.root 設定を変更した場合、場所は異なります。
3. HDD状態確認(WSLでの作業)
次からはWSLで作業。
見ればわかる通り、第4パーティションはext4だけど、WSLがあればWindowsPCだけで中身を触れる。ナイス。
admin@wsl:~$ sudo fdisk -l
ディスク /dev/sdd: 1.82 TiB, 2000390000000 バイト, 3907029168 セクタ
Disk model: 003 HN-M201RAD
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x723exxxx
デバイス 起動 開始位置 最後から セクタ サイズ Id タイプ
/dev/sdd1 64 8388607 8388544 4G c W95 FAT32 (LBA)
/dev/sdd2 8388608 16777215 8388608 4G c W95 FAT32 (LBA)
/dev/sdd3 16777216 33554431 16777216 8G c W95 FAT32 (LBA)
/dev/sdd4 33554432 3907029167 3873474736 1.8T 83 Linux
admin@wsl:~$ sudo mount | grep PHYSICALDRIVE
/dev/sdd1 on /mnt/wsl/PHYSICALDRIVE2p1 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sdd2 on /mnt/wsl/PHYSICALDRIVE2p2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sdd3 on /mnt/wsl/PHYSICALDRIVE2p3 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sdd4 on /mnt/wsl/PHYSICALDRIVE2p4 type ext4 (rw,relatime)
こんな感じでマウントされる。
admin@wsl:~$ cd /mnt/wsl/PHYSICALDRIVE2p4
admin@wsl:/mnt/wsl/PHYSICALDRIVE2p4$ ls -la
合計 236
drwxrwxrwx 9 admin admin 4096 11月 23 11:33 .
drwxrwxrwt 7 root root 160 12月 29 17:50 ..
-rw-rw-rw- 1 root root 0 5月 28 2016 .check
drwxrwxrwx 2 10021 10021 4096 11月 29 07:01 databases
drwxrwxrwx 4098 10021 10021 69632 4月 11 2016 displayimage
drwxrwxrwx 4 10021 10021 4096 4月 4 2022 initrd
drwx------ 2 root root 16384 1月 7 2016 lost+found
drwxrwxrwx 4098 10021 10021 69632 4月 11 2016 originalfile
drwxrwxrwx 2 10021 10021 4096 9月 18 17:21 temp
drwxrwxrwx 4098 10021 10021 69632 4月 11 2016 thumbnail
originalfile配下に画像ファイルは保存されている（と思う。displayimageディレクトリとの違いがよくわからない）。
admin@wsl:/mnt/wsl/PHYSICALDRIVE2p4/originalfile$ ls -la | head
合計 16456
drwxrwxrwx 4098 10021 10021 69632 4月 11 2016 .
drwxrwxrwx 9 admin admin 4096 11月 23 11:33 ..
drwxrwxrwx 2 10021 10021 4096 5月 9 2021 000
drwxrwxrwx 2 10021 10021 4096 5月 9 2021 001
drwxrwxrwx 2 10021 10021 4096 8月 6 17:20 002
drwxrwxrwx 2 10021 10021 4096 10月 25 2020 003
drwxrwxrwx 2 10021 10021 4096 11月 21 2021 004
drwxrwxrwx 2 10021 10021 4096 5月 9 2021 005
drwxrwxrwx 2 10021 10021 4096 6月 12 2022 006
3桁の英数字でディレクトリが作られ、そのディレクトリに32桁の英数字+.拡張子という形でファイルが保存されている。
admin@wsl:/mnt/wsl/PHYSICALDRIVE2p4/originalfile/c26$ ls -la
合計 174340
drwxrwxrwx 2 10021 10021 4096 12月 21 2020 .
drwxrwxrwx 4098 10021 10021 69632 4月 11 2016 ..
-rw-rw-rw- 1 10021 10021 3321504 9月 20 2015 c260c57c299a76ca62b804cexxxx1172.jpg
-rw-rw-rw- 1 10021 10021 2882444 5月 16 2011 c26233574afe039f343bcc16xxxx1efa.jpg
-rw-rw-rw- 1 10021 10021 4949177 12月 22 2013 c26290b06abe3c82364e05b6xxxx6278.jpg
32桁の英数字といえば、これが疑わしいが。
admin@wsl:/mnt/wsl/PHYSICALDRIVE2p4/originalfile/c26$ md5sum c260c57c299a76ca62b804cexxxx1172.jpg
c260c57c299a76ca62b804cexxxx1172 c260c57c299a76ca62b804cexxxx1172.jpg
ビンゴ。おもいでばこでは取り込んだファイルのファイル名は書き換えて、md5ハッシュに名前を変えている。
ちなみに、元ファイルは
admin@nas:/HDDDEVICE01/photos/2015-09-20$ md5sum DSC_0999.JPG
c260c57c299a76ca62b804cexxxx1172 DSC_0999.JPG
となりハッシュが一致する。Exif含めて元ファイルには手を付けていない模様。
ここまでわかれば、ファイルをサルベージするのは簡単。
ここから適当なデバイスにrsyncでもしてやればOK。
今回はHDDの障害ではなかったのでデータサルベージできたが、もしHDD障害だったらもっと大変だったと思う。
おまけ - ファイルデータベースについて
./databasesには複数の.dbファイルがある。このファイルはSQlite3ファイル。普通に開いて中身が確認できる。
admin@wsl:/mnt/wsl/PHYSICALDRIVE2p4/databases$ sqlite3 ./omoject_main.db
SQLite version 3.37.2 2022-01-06 13:25:41
Enter ".help" for usage hints.
sqlite> .tables
CLOUD_ACCOUNT T_CALENDAR_COVER T_REPLACED_PHOTO android_metadata
CLOUD_UPLOAD T_COVER_PHOTO T_TAG
CLOUD_UPLOAD_LOG T_DB_INFO T_TAG_DATE
MUSICS T_PHOTO T_TAG_PHOTO
sqlite> PRAGMA table_info('T_PHOTO');
0|_photo_id|INTEGER|0||1
1|photo_file_path|TEXT|1||0
2|photo_snapped_date|TEXT|1||0
3|photo_erased|INTEGER|1||0
4|photo_file_name|TEXT|1||0
5|photo_hash|TEXT|1||0
6|photo_imported_date|TEXT|1||0
7|photo_mine|TEXT|1||0
8|photo_rate|INTEGER|1|'0'|0
9|photo_comment|TEXT|1|''|0
10|photo_latitude|INTEGER|0||0
11|photo_longitude|INTEGER|0||0
12|photo_facial_recognized|INTEGER|1|'0'|0
13|photo_lastModified_date|TEXT|1||0
14|photo_filesize|INTEGER|1||0
15|photo_thumbnail_type|INTEGER|1|'0'|0
16|photo_has_displayimage|INTEGER|1|'0'|0
17|photo_maker|TEXT|1|''|0
18|photo_model|TEXT|1|''|0
19|photo_focal_length|TEXT|1|''|0
20|photo_flash|TEXT|1|''|0
21|photo_import_count|INTEGER|1|'0'|0
22|photo_degree|INTEGER|1|'0'|0
sqlite> select * from T_PHOTO where photo_hash like 'c260c5%';
6885|c26/c260c57c299a76ca62b804cexxxx1172.jpg|2015-09-20 11:19:13|0|dsc_0999.jpg|c260c57c299a76ca62b804cexxxx1172|2016-04-05 02:41:53|image/jpeg|0||||0|2015-09-20 11:19:14|3321504|4|2|NIKON CORPORATION|NIKON D3100|270/10|24|2|0
こんな形でphoto_file_nameカラムに元ファイル名も保存されているしExif情報も保存されている。
とりあえず、このSQLiteファイルも取っておけば元のファイル名も復元できる。
しかし、もしmd5hashがダブる画像ファイルがあった場合どうなるんだろうか。謎。
おまけ - originalfile,displayimage,thumbnailについて
それそれのディレクトリには同じ名前のファイルが存在するが、ファイルサイズや(あたりまえだけど)MD5が異なる。
admin@wsl:/mnt/wsl/PHYSICALDRIVE2p4$ ls -la originalfile/000/0000224acc92fe28c9b649b5xxxxe35e.jpg
-rw-rw-rw- 1 10021 10021 3388454 9月 21 2014 originalfile/000/0000224acc92fe28c9b649b5xxxxe35e.jpg
admin@wsl:/mnt/wsl/PHYSICALDRIVE2p4$ ls -la displayimage/000/0000224acc92fe28c9b649b5xxxxe35e.jpg
-rw-rw-rw- 1 10021 10021 761140 4月 11 2016 displayimage/000/0000224acc92fe28c9b649b5xxxxe35e.jpg
admin@wsl:/mnt/wsl/PHYSICALDRIVE2p4$ ls -la thumbnail/000/0000224acc92fe28c9b649b5xxxxe35e.jpg
-rw-rw-rw- 1 10021 10021 11325 4月 11 2016 thumbnail/000/0000224acc92fe28c9b649b5xxxxe35e.jpg
admin@wsl:/mnt/wsl/PHYSICALDRIVE2p4$ md5sum originalfile/000/0000224acc92fe28c9b649b5xxxxe35e.jpg
0000224acc92fe28c9b649b5xxxxe35e originalfile/000/0000224acc92fe28c9b649b5xxxxe35e.jpg
admin@wsl:/mnt/wsl/PHYSICALDRIVE2p4$ md5sum displayimage/000/0000224acc92fe28c9b649b5xxxxe35e.jpg
cc5c7cf87b452deb335e859ddf331a0e displayimage/000/0000224acc92fe28c9b649b5xxxxe35e.jpg
admin@wsl:/mnt/wsl/PHYSICALDRIVE2p4$ md5sum thumbnail/000/0000224acc92fe28c9b649b5xxxxe35e.jpg
3bcd5dcfb1487edb45f5a11941e7f573 thumbnail/000/0000224acc92fe28c9b649b5xxxxe35e.jpg
元ファイルはoriginalfileで保管してあるけど、ファイルサイズが大きすぎるとロードが長くなるなど扱いづらいからか、取り込み時におもいでばこが適切なファイルサイズに変換しているのがdisplayimageなのかな。
処理高速化のためいろいろやってるんだな。
おまけ - 内部データについて
おもいでばこの中身はプライバシーの塊。
家族の顔が入っているのはもちろん、Exifには位置情報が入っているし撮影した写真の背景に重要情報入ってる可能性あるし、SQLiteのデータベースの中にはAmazonアカウントIDが乗っていたりする。
おもいでばこを破棄するときには初期化では全く安心できないので、ゼロフィル2回やるかHDDを物理的に破壊することをお勧めする。
おもいでばこの後継について
実家の親に触らせる都合上、パソコンでは都合が悪い。
SDカードからデータを吸い上げられて、HDMIでテレビにつなげられて、リモコンだけで操作が完結して、操作方法が簡単。
この条件があればおもいでばこにこだわる必要はないんだが、結局おもいでばこを再度買うことになりそう。
前回、前々回はHDDが死んで、今回は（多分）本体基盤が死んで、となっていて個人的に信頼性は極めて低いんだが、それでも利便性には代えられない。
Raspberry Piベースでおもいでばこな機能を実装してケースもついてたりしたらとてもうれしいんだけどなあ。