あっ！と思ったらだいたい手遅れ。でも希望を抱いてWeb検索しよう
背景
主にVMwareでROを動かしつつ動画編集する目的でMacのスペックアップ、負荷分散やデバイス故障の被害を抑えるためVMware用、録画編集用の外付けSSDを用意していました。さらには録画素材用HDDもあり、さすがにこれらを全てTimeMachineの対象にするのは大変なので除外していましたが、最近追加の外付けHDDを増設したことで作業環境を見直す契機が訪れました。
そして、注意して作業しなきゃと思いつつも、うっかり確認せずにやってしまって失敗するのが割と無視できない頻度で発生するわたしは、今回の環境見直しでそれを引き当ててしまいました。復旧に1日かかったので戒めのために記録しておきます。
何をやった？
目的は下記2つです。
- TimeMachine領域拡大
- SSD性能向上
TimeMachine領域拡大
まずは外付けHDDを専用のTimeMachine領域にして、バックアップ対象を拡大します。構成変更は下表の通り。（表のTM列はTimeMachineバックアップ対象かどうか）
| 変更前 | TM | 変更後 | TM |
|---|---|---|---|
| 本体SSD | ○ | 本体SSD | ○ |
| VMwareSSD | ○ | VMwareSSD | ○ |
| 録画編集SSD | ○ | 録画編集SSD | ○ |
| 録画素材HDD | × | 録画素材HDD | ○ |
| - | - | TimeMachine | - |
変更前の構成では、録画素材置き場のHDDに容量共用のTimeMachine用Volumeを作成していましたが、録画素材の容量増加でTimeMachineバックアップが1世代（直近1時間だけ）しか確保できず意味をなさなかったため専用の領域を増設しました。
SSD性能向上
さらに性能向上のため外付けSSDの2台をソフトウェアRAID0（ストライプセット）に構築し直しました。録画編集はワーク用に録画編集SSDを用意しているため特に帯域面で不足はありませんが、VMwareのスナップショット管理で古い断面を削除する時などはSSDのSLCキャッシュを簡単に超えるread/writeが発生するためRAID0構成することで帯域を拡大することにしました。
| 変更前 | 変更後 |
|---|---|
| VMwareSSD | StripeSSD/VMs |
| 録画編集SSD | StripeSSD/Movies |
SSDはそれぞれ4TBで、容量的にはVMwareが1TB程度、録画編集も概ね1TB程度しか使わないので問題なし。VMwareも大量のIOが発生することは少ないため、デメリットなしで運用できそうです。ストライプセットを組むことで故障率が倍になりますが、TimeMachineで1時間ごとにバックアップ取得するため問題ないでしょう。
それで失敗とは？
はい。運用で問題なさそうと判断したので実際に移行作業を行なったところで事故がありました。
VMwareの移行は、念のためインスタンスをシャットダウンしてから本体SSDへ移動。ストライプセットを構築した後に戻してから移行パスワードを入力して完了です。こちらはVMwareのencryption passwordをkeychain accessアプリで確認して入力する手順なので特に問題なし。
問題は動画編集環境でした。
移行手順は下記の通り。VMwareと一緒に本体SSDへ移動させて、ストライプセット構築後に戻すだけでした。
ここで、手順1の時にコピー失敗した旨のエラーが出たのですが、TimeMachineバックアップの履歴にはバックアップ済みだったのでそちらから戻せばいいかと思い、録画編集SSDからではなくTimeMachineから本体SSDにコピーし、成功しました。その代替手段自体は問題ありませんが、この時本体SSDにコピーしたライブラリを開いて動作確認しなかったことが異常検知を遅らせました。
問題に気づいたのは上記手順3の後です。ストライプセットを組んだことで向上した性能を確認するため、ライブラリを開いた時でした。
ライブラリを開いた瞬間アプリが異常終了しました。緊急事態です。
手順1でコピーする際に、一部のファイルを読み取れないというエラーが発生していたのが問題のようです。TimeMachineバックアップのファイルも同じ問題を抱えていたようで、いつの時点か不明ですが何らかのファイルが破損していたようです。TimeMachineバックアップは、内部の不整合など無関係にファイル単位で差分バックアップするだけなので、破損がいつ発生したかを追跡することはできません。そしてストライプセットを構築するために元の録画編集SSDは消去してしまったため、なぜエラーなくライブラリを開くことができていたかもわかりません。もしかしたらTrashに移動させたファイルがdynamic linkになっていて、ライブラリファイルはTrashが空になるまでは残骸を参照できていたのかもしれません。
いずれにせよ、ライブラリを修復しないことには、これまで作成してきた動画のマスターが失われてしまうため、いろんな手段を試みました。
- ライブラリ内のOriginal Mediaのリンク修正
- TimeMachineバックアップを1時間毎にさかのぼって戻し確認
- ライブラリ内のリソースを少しずつ削除
ライブラリ内のOriginal Mediaのリンク修正
Final Cut Proのライブラリは、内部に録画素材へのリンクを保持しています。（下図Original Media配下）
このリンクは、ファイルシステムのsymbolic linkで実現されているため、ストライプセットを構築したことでパスが変化しています。一部は録画素材HDDのパスでしたが、いくつかは旧録画編集SSDのパスになっていました。中には、ストライプセットのパスになっているものもあり、symbolic link自身を指すことでループ状態になっているものもありました。これらを正しいリソースのパスに修正しました。
しかしこれは原因ではありませんでした。
Final Cut Pro起動時には、メディアの参照パスが存在しない場合には警告が表示されます。これはRelink Filesでパスの自動修正が可能なので、リソースパスが破損している程度でアプリ異常終了にはならないでしょう。問題はもっと複雑なようです。
TimeMachineバックアップを1時間毎にさかのぼって戻し確認
これは結果的に成果なし。時間だけを消費しました。
ライブラリ内のリソースを少しずつ削除
試行1でOriginal Mediaのリンクを試しましたが、ライブラリを構成するリソースは他にもあるため、少しずつ削除して問題箇所を特定しようと試みました。キャッシュファイルやサムネイルなどは生成が可能なため大胆にフォルダ毎削除したり、プロジェクト内のイベントを1つ削除してみたり。
こちらも成果なく、そろそろ手を尽くした感が出てきました。
そしてどうなった？
CopilotにFinal Cut Proのライブラリファイルを修復する方法を聞いてみると、いくつかのサードパーティ製ツールを紹介されましたが、手段の一つとしてFinal Cut Proが自動バックアップしているものを利用するという手順がありました。
~/Movies/Final Cut Backupsの最新を開く。
これで解決しました。
どうやらFinal Cut Pro起動毎にバックアップが取られるようでした。Original Mediaへのリンクは無効になっていますが、それらをRelink Filesで修復することでライブラリを復元できました。
教訓
TimeMachineバックアップは、ファイルコピーに成功したものしか保存していないので、今回のように本体SSDにライブラリコピーした際にエラーになった原因を保存していないです。まぁコピーに失敗していれば、失敗した対象はバックアップできないですよね。
その結果、正常にコピーできるファイルだけをTimeMachineバックアップから取り出したら、コピーが成功するのは当然ですが、そのファイルで動作確認するという手順を怠ったことが問題でした。その時点で気づいていれば、ストライプセットを構築する前の状態でいくつか模索できたでしょうし、冷静さを保ったままFinal Cut Backupsの存在に気づくこともできたことでしょう。
環境に手を加える際には、落ち着いて、やろうー。
