実家のおもいでばこが壊れた。

おもいでばこを起動すると、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ベースでおもいでばこな機能を実装してケースもついてたりしたらとてもうれしいんだけどなあ。