takac.log

今日は何を撮りに行こうかな?

【悲報】4年間撮り溜めてきた画像を一瞬にしてすべて失った悲しみの記録

f:id:nekosogiradical:20160926205848j:plain

先々週の土曜日のことだった。

東京ゲームショウ2016と夜景撮影をして大満足で家に着き、「今日はたくさん撮ったなぁ~早くパソコンにバックアップしとこ」とMacを立ち上げる。

「そうだ、まだLightroomが5D4に対応していないから、とりあえず先週の多摩動物公園アートアクアリウムの画像と一緒のフォルダにコピーしておくか」と、フォルダを開こうとすると、、そのフォルダがなくなっていた…

Mac miniのディスク構成と使用用途

少し話はそれて現在のMac miniのディスク構成について。

以前Mac miniSSDを512GBの大容量に変えたタイミングで、Fusion Driveを解除して以下の構成とした。

  • システム…SSD 512GB
    うち、macOS 350GB、Windows10(BootCamp) 150GB
  • データ…HDD 1TB
    うち、macOSWindows 10の共有領域 100GB、カメラで撮った画像(RAWとJPEG) 900GB

gonyo.hatenablog.com

SSD化して爆速になったがWindows10はオフィスソフトかゲームくらいでしか使わず、月例アップデートの適用で立ち上げる方が多かったくらい。

画像データの入っているボリュームはいずこへ

話しは戻って、画像を保存しているHDD 900GBのボリュームがFinderのサイドバーから消えており、再起動しても復活せず。ディスクユーティリティから確認すると100GBのボリュームだけ認識している状態で、Windows10側からも確認するがファイルシステムはRAW(未フォーマット)となっている…

ディスクユーティリティからFirst Aidを実行しても【問題ありません】と表示されるので、ネット調べるとTestDiskなるソフトでMBRに正しい情報を書き込めば、再び認識して使えるようになるそうでついついバックアップも取らずに実行して再起動。


……
……… 起動しなかった。

無視 or 修復

嫌な予感しかしない中で起動時にCommand+RでOS X ユーティリティからディスクユーティリティを起動すると4つのパーティションのうち3つが赤字で修復が必要となっている。

無視を選んでボリューム単位に修復しようとしても、すべてが選択された状態で【無視 or 修復】のポップアップが上がる…「もう修復しかないじゃん…」と【すべてのデータが消去されます】的メッセージが表示されていた気もするが修復をクリック。


……
……… テッテレー!!

画像データは消失した!

macOSは消失した!

Windows10は消失した!

1.5TBの巨大なFusion Driveを手に入れた!

終わった…と、ここまでは想定できていた展開で「もしもの時はTime Machine(macOSのバックアップソフト)から戻せばいいや」と、この甘さが命取りとなる。

忌々しきFusion Drive

Time Machineから復旧する前にFusion Driveが再結成されたのをターミナルからコマンドで解除してディスクユーティリティを再び立ち上げるも再び【無視 or 修復】ダイアログが現れた。

また修復を選ぶとFusion Driveの再結成間違いなしなので、無視を選び一か八かフォーマットせずにOS X ユーティリティの【Time Machine バックアップからの復元】を選んでSSDへの復元を試みるも失敗。

「もしや新規インストールならディスクの初期化もやってくれるのでは…?」と新規インストールを選ぶとダウンロードが開始して小一時間で新規インストールが終了。

初期設定は後々Time Machineから復元するのでスキップ、いの一番にディスクユーティリティを確認するとFusion Driveは結成されずSSDがソロデビューしていてひと安心。

再びOS X ユーティリティのTime Machineから【Time Machine バックアップからの復元】を選択すると


……
……… いけた。プログレスバーが進んでいる。

ここからしばらく時間が掛かるので、朝起きたらインストールが終わっていることを祈り就寝。

画像データの入っているボリュームはいずこへ・改


……
……… 3時間程で目が覚めて朝4時。

Time Machineからの復元は終わっていて見慣れたログイン画面が…!

そして、ログイン確認!問題なし!、動作確認!問題なし!、Chromeはログアウトされてるけど再ログインで問題なし!、無くなっていたボリューム確認、も…あれ??1TBの空ボリュームがポツンと。


……
……… あれ?あれ?あれ?あれ?あれ?

「Time Machineの仕様ではシステムドライブ以外のボリュームやパーティションもバックアップ対象だから復元されるはずだよね??」とTime MachineのバックアップデータをFinderで直接開いてみると【Macintosh HD】しかなく【ボリューム】はいなかった…

f:id:nekosogiradical:20160926225649p:plain


……
……… えーーーーーーーーーーーーーーーーーーーーーっ!

しらべてみるとどうやら、システム(Macintosh HD)以外のボリュームやパーティションもTime Machineのバックアップ対象とできるが、一度設定画面の除外リストに当該のボリュームを登録し、それから削除をしてはじめてバックアップ対象となるらし。

f:id:nekosogiradical:20160926214147p:plain

Time Machine専用の外付けHDD 3TBのうち1.8TBもバックアップに使っていたから、てっきり取れているものだと思っていたのが実は取れていなかった…

被害状況を確認してみる

被害を一言で言うなら「カメラを始た2012~2016年の約5年分の画像データすべて」なのだが、データ形式クラウドにあるデータが少し複雑。

f:id:nekosogiradical:20160926215020p:plain

  • 2012~2014年分はJPEGで撮ってPicasaで管理してウェブ同期
  • 2015年はRAWで撮ってLightroomで管理・RAW現像して、Picasaでウェブ同期とAmazonプライム・フォトでRAWデータをバックアップ
  • 2016年はRAWで撮ってLightroomで管理・RAW現像して、GoogleフォトでアップロードとAmazonプライム・フォトでRAWデータをバックアップ

画像を管理していたボリュームがすべて消去され、期待していたTime Machineも実はバックアップされておらず、DVD-RやBD-Rへのバックアップは一切取っていなかったので頼みの綱はクラウドだけだ。

しかし、Picasaのウェブ同期は無制限サイズで長辺が2048pixにリサイズされた約280万画素の低画素データ(タブレットスマホでの閲覧用途だったので…)。2016年からはGoogleフォトを導入して約1600万画素(長辺が約4900pix)の高画素データがあり、2015~2016年は別途Amazonプライム・フォトにRAWデータがあるが…

データの復旧作業へ

「ひとまずRAWデータでも救うか…」とAmazonプライム・フォトの管理画面を開くとたった2年間で300GB超のデータが保存されていた。

f:id:nekosogiradical:20160926215825p:plain

一気に300GBはさすがに気が引けるので、試しに1ヶ月分をダウンロードすると平均8MB/秒(28GB/時)で 300GB÷28GB/時≒10.7時間 とそこそこ掛かりそうなので、Googleフォトから先に復旧することに。

Googleからの復旧で予想外の…

今日日300万画素のデータはDot by Dotでも枠が表示されるレベルで「なかなかキツいなぁ…」と思ったがないよりはマシ。

GoogleクラウドサービスはTakeOut(一括ダウンロード)機能があるので、Googleフォト(Picasaのウェブ同期含む)の全データのダウンロードリクエストを送信。

f:id:nekosogiradical:20160926220710p:plain

https://takeout.google.com/settings/takeout

データが多くダウンロードの準備ができるまでに時間が掛かるようなので、消失したショックを紛らわすべく外出することに…

そして、外出から戻ってきてメールを確認するとダウンロードの準備が整ったとのメールが届いており、1ファイル2GBで52個のZIP圧縮されたダウンロードリンク(約104GB)があった。

f:id:nekosogiradical:20160926220920p:plain

スマホで撮った画像が含まれていたとしても104GBはデカ過ぎないか?」と思いつつ一つずつダウンロードする。速度は計っていないけどほぼ回線の上限近く(180〜190Mbps)まで出ていた気が。

f:id:nekosogiradical:20160926224432j:plain

ファイルはナンバリングされているが中のデータに規則性はなさそうで、1つずつ展開してフォルダを合体してを繰り返し約120GBの画像データの塊ができた。

f:id:nekosogiradical:20160926221220p:plain

Googleフォトやウェブ同期でアルバム化していたものは【YYYY-MM-DD_イベント名】の形式でフォルダが作成され、Googleフォトやスマホからアップロードしたものは【YYYY-MM-DD】や【YYYY-MM-DD #2】でフォルダが作成されているが、やけに日付のフォルダが多い。

2013年のフォルダを適当に開くとDSC_xxxxx.JPG 2.8MBのファイルがあって、「2013年にウェブ同期したデータは長辺2048pixのせいぜい1MB強のはずなのにおかしいなぁ」と情報(プロパティ)を確認してみると、4912*3264pix…4912*3264≒1600万…!!

これはGoogleフォトからアップロードされているやつだ!

Googleフォトを導入したタイミングでこれまで撮っていたデータもアップロードしていたようで【YYYY-MM-DD_イベント名】と同一日付の【YYYY-MM-DD】フォルダには1600万画素のデータが含まれていた。Googleフォトにアップロードすると無劣化ではないが見分けがつかないレベルなので本当に助かった。

f:id:nekosogiradical:20160926222842p:plain

Amazonプライム・フォトからは見送り

Amazonプライム・フォトの300GB超のRAWデータはGoogleフォトの高画質データ(1600万画素)が残っていれば戻す必要はない気がした。

パソコンで閲覧する時はGoogleフォトかPicasaAdobe Bridgeだし、RAWデータは2年で300GBととてつもない増加量でどこかで区切らなければならなかったが、この機会にすべて見捨ててしまって必要があればファイルや日付単位でAmazonプライム・フォトからダウンロードしてRAW現像すればいいかなと。

最終的に失ったもの

過去のデータの大部分は多少サイズが小さくなってはいるが取り戻すことができた。

完全なデータ消失はCanon EOS 5D Mark IVが届いた週の土日に行った多摩動物公園アートアクアリウムのデータを東京ゲームショウ2016に行く前に消失したボリュームに一時保存してCF・SDカード共に初期化していたので、この2日分のデータはブログに載せるのに使った長辺が800pixのJPEGデータしかないが、JPEG撮って出しでブログのネタにはした後だったからよかったかな。

takaclog.hatenablog.com

また、8月下旬のロサンゼルス旅行も現像がほとんど終わっておらずGoogleフォトにもなかったが、幸いにも帰国してからはEOS 5D Mark IVしか触っていなかったのでいつもならパソコンに取り込んで次に使う時にはSDカードを初期化しているが、SONY α7とRX100M3は帰国してから一度も使っていなかったので丸々カード内にデータが残っていたのでなんとかLA旅行記が続いてる…助かった。

takaclog.hatenablog.com

今回の件から得るべき教訓

バックアップにはそこそこ気を付けていたつもりだったけど、改めて不十分であったことに気付かされた。そんなわけで今回の件から得るべき教訓は…

  1. Time Machineを過信しないこと(自分の凡ミスではあったけど)
  2. 別ボリュームをTime Machineの対象にする時は一度除外登録をすること
  3. 軽い気持ちでMBRをイジらないこと
  4. RAW現像は早めに終わらせてGoogleフォトにアップロードすること
  5. RAW現像したJPEGデータは記録メディア(BD-R)に保存しておくこと
  6. (一部は戻るかもしれないけど)失ったデータはカネで解決できない

最後に

『そもそもなぜボリュームが認識されなくなったか』は未だに不明ではあるが、唯一思い当たるとすれば前夜にWindows10のアップデートを適用した矢先のことではあった。ゆえに今もまだBootcampでWindows10を入れられずにいる…

 とりあえず今はTime Machineでしっかりボリュームのバックアップが取れてるから大丈夫だろう…

f:id:nekosogiradical:20160926230610p:plain

そして、Lightroomは心機一転新しいカタログを作ってスタート。

f:id:nekosogiradical:20160926230649p:plain

NASでも入れるかなぁ…

追記:カメラブログのtakac.logでデータ管理について記事を投稿してます

takaclog.hatenablog.com

takaclog.hatenablog.com

takaclog.hatenablog.com