バックアップは、復元されるまで仮説
バックアップを作成するとファイルができます。そのファイルがライブラリを再構成できるかどうかは別の問いであり、重要なのはその問いだけです。
復元テストは、思い込みを証拠に変えます。1時間でできる最も価値の高いことですが、手遅れになる日まで、ほとんど誰も行いません。
バックアップファイルが存在しても役に立たない、そのあり方
ファイルはフルサイズで存在していても失敗し得ます。書き込み中に途中で切れている、記録したのとは違うフレーズと対になっている、現在のリリースが読めない形式のアプリのバージョンで作られている、含まれていると思い込んでいた種類のコンテンツが欠けている——といった場合です。
これらのどれも、ファイルの一覧からは見えません。そのすべてが、実際に復元してみれば数分のうちに見えます。
有効な保管庫とは独立してテストする
最も一般的なテストの誤りは、動作中の保管庫がまだ利用できるまま復元することです。アプリが有効なデータにフォールバックし、バックアップには実際には含まれていなかったコンテンツを見せてしまうことがあるからです。
有効なテストは、元のライブラリが存在しない端末やプロファイルで、文書化された復元の流れを使います。それが現実的でない場合は、少なくとも、表示されたコンテンツがどのソース由来かを確認してください。
復元できたら何を開くか
- 新しいバックアップを作成し、その日付と、それを作ったアプリのバージョンを記録します。
- 有効な保管庫に頼らず、文書化された流れで復元します。
- 最も古い項目、最も新しい項目、最も大きな動画、そして珍しい形式のものを開きます。
- 何かが現れたことだけでなく、期待した項目数と照合します。
- サムネイルではなくフルサイズのコンテンツを開きます。サムネイルはキャッシュされたデータから表示され得るからです。
- 各回の成功したテストの日付を記した、短い復元ログを保ちます。
何も証明しないテスト
- バックアップファイルのサイズがゼロでないことだけを確認すること。
- 有効なデータベースがまだアプリから利用できる状態でテストすること。
- 実際のコンテンツではなく、サムネイルやファイルの一覧だけを開くこと。
Eli はまず、機微でないデータでテストします。「新しい暗号化バックアップを作成し、その日付とアプリのバージョンを記録する」。次に Eli は2つ目の確認手順に従います。「有効な保管庫に頼らず、文書化された復元の流れを使う」。この架空のシナリオは判断の流れを示すものであり、製品テストの報告ではありません。
- バックアップファイルのサイズがゼロでないことだけを確認すること
- 有効なデータベースがまだ利用できる状態でテストすること
- サムネイルだけを開くこと
どのくらいの頻度でテストすべきですか？
アプリや端末の大きな変更の後、そして保管庫が変わる頻度に見合った間隔でテストしてください。
機微なデータでテストしてもよいですか？
代表的なサンプルと、管理された保存先を使い、その後テスト用のコピーを取り除いてください。