削除データの復元工程を考えてみる
回顧主義の私にうってつけのテーマかもしれませんが、今更ですが削除データの復元について、顧客の要望に応えるにはどう考えるのがよいか検討してみたいと思います。TPS の考え方を理解する為の実験ですので、大きく間違っている可能性が高いです。
「削除されたデータを調べたい」という漠然とした要望が顧客から出た場合に、まず何を考えるべきでしょうか？
技術的には削除データには様々なものが存在し、細かくリストアップしてどれを必要とするかを考えることもできます。例えば、削除された電子メール、削除されたファイル、削除されたブラウザ履歴、削除された文字列、削除されたレジストリ、削除された何か？、調査する対象のシステムやデバイスによって得られる情報にバラツキがありますので、まずそれを整理すべきでしょうか？
それとも、最初に後工程が必要とするものを生産するべきなのでしょうか？
顧客の要望は「削除されたデータを調べたい」という事ですが、これをもう少し小さい単位に分割できないでしょうか。小さい単位に分割し、かつ最初に必要としているものから生産を開始する事ができないか？という事になります。
例えば、削除された電子メールをまずは確認したい、という優先順位がある場合、前工程としては次の流れを取る事になります。
- 電子メールソフトが何か、データが存在するかを確認する
- 電子メールソフトが判別できたら、復元可能データがあるかを確認する
- 復元可能なデータをリカバリし後工程に流す
この場合、1と2は人間がオペレーションを行い、機械に待たされるという時間はかなり少なく、付加価値が高い時間を生み出すことができる気がします。*1
工程の3はリカバリ処理に機械的に時間がかかる事も予想されます。機械が処理を行っている時間、人間は他の作業を行う事ができるはずです。
また、次に後工程が必要とする削除データが何か？を平行して確認できていれば、スムーズに次の作業に入れそうです。
では、削除されたファイルを復元し確認したい、というリクエストが事前に確認できている場合には、工程としては以下が考えられます。
- 削除されたファイルをリストアップする
- 削除されたファイルのうち上書きされてないものを選別する
- 削除されたファイルのうち上書きされてないものをリカバリし後工程に流す
この工程を考えた場合、2の段階でもう少し工夫した方がよい気がしてきました。
削除されたファイルには多数の種類があるはずです、例えば削除された実行形式ファイルは顧客が期待しているファイルでしょうか？、もし一般的なオフィス系のファイルだけが希望であれば、この選別段階でファイルタイプも指定する方が、その後に続く工程での作業時間も短くできるはずです。少し修正してみます。
- 削除されたファイルをリストアップする
- 削除されたファイルのうち上書きされてないものを選別する
- 上書きされてないファイルのうち、指定されたファイルタイプに限定する
- 削除されたファイルのうち上書きされてないものをリカバリし後工程に流す
ファイルタイプの限定方法としては、拡張子による絞り込みと、シグネチャの分析を行う方法が考えられます。削除ファイルの特徴からいくと、破損している可能性も高いことから、拡張子で絞る AND シグネチャが一致するもの、とした方が不良を減らすことができるのではないでしょうか？、顧客が破損したファイルを見たいのでなければですが。
- 削除されたファイルをリストアップする
- 削除されたファイルのうち上書きされてないものを選別する
- 上書きされてないファイルのうち、指定されたファイルタイプに限定する
- 限定したファイルのシグネチャを分析し指定タイプと一致するものに限定し破損ファイルを取り除く
- 削除されたファイルのうち上書きされてないものをリカバリし後工程に流す
この工程により、削除されたファイルのうち、上書きされてない AND 破損してない、と推測できるファイルが復元され、後工程でファイルが読めないといった事を軽減できます。
ただし、ファイル名等が重要な場合もありえますから、別途ファイルのリストを提供する必要があるか？などは確認しておく気配りは必要でしょう。
この工程をスムーズに流すには、後工程で必要としている情報をよく理解または確認しておく必要があります。例えば、工程２までは確認なく進めることもできますが、工程3を進めるには条件を確認できていないと待ち時間が発生する事になります。
削除ファイルの復元工程にRecover Foldersの様な処理を含めるべきでしょうか？
ファイルシステムを管理する情報が、痕跡としてディスク上に残っている場合、その管理情報の痕跡からファイルを復元する方法ですが、問題もあります。
- 過去のファイルシステム管理情報を使ってデータを復元する為、正しいファイル内容を復元していると限らない
もちろん正しくデータを復元できる場合もありますが、正しく復元できているか？を確認する手段が限られる点もあります。
過去にどの様なデータがあったのかを確認したい、という意図であれば役立つ情報ですが、取り扱いには注意が必要な部類のデータでしょう。
この作業工程は、時間がかかりますが、ステップとしては削除ファイルの復元と同じ流れで行う事ができるはずです。
カービングはどうするべきでしょうか？パターンに応じてデータを復元する事もできますが、これも闇雲に全てを試してみるアプローチと、探しているものがある程度明確になってから取り組む案が考えられます。
一般的にカービングは、未割当領域に対して、指定したパターンやキーワード文字列などを指定して、それに一致した部分を取り出すという事になります。たまたまパターンに一致しただけのデータや、読み取りが不可能なデータも多数掘り出されることになる作業で、かつかなりの時間を要します。
また、カービングを必要とするかどうかは、ケースの進捗により場合によっては作業しても無駄になる可能性もあります。カービングは時間がかかる処理ですから、これを実行するのはタイミングをよく見極める必要があります。
- カービングすべきデータは特定されているか？
- カービングしたデータをどの様な形式で後工程に流せばよいか？
例えば、電子メールまたは文書ファイルをカービングする事を想定した場合、データの形式によってはうまく取り出せない可能性もあります。RAWレベルでのKW検索をかける事も可能ですが、キーワード候補が必要になりますから、後工程でキーワードが決まって必要としているデータが何か？を分かってから取り出し処理をするべきなのかもしれません。
- カービングすべき対象データの種類を特定する
- カービングの対象範囲を決定する
- パターンまたはキーワードを定義し検索処理を実施する
- 発見したデータの取り出しを行う
- 後工程で処理できる形にデータを揃える、または加工する
さて、Recover Foldersやカービングは時間がかかる処理です、恐らく人間が待たされる処理になるはずですから、人間が待たされることがないように流れを組む必要があります。夜間に実行するなども一案ですが、ラインを平行して走らせるという検討すべきかもしれません。
次に考えるべき事としては、OSに依存してくる部分ですが、例えばシステムが自動的に保存しているバックアップデータからの復元という項目が考えられます。
Windows 7などの環境であれば、VSS領域からの復元なども行うべきだと思いますが、この処理はデータとして重複したものを出力する可能性が高い部分です。（VSSに限らず、バックアップが複数存在する場合には、それぞれのバックアップからデータの取り出しが可能であり、多くのデータが重複する事になります）
バックアップデータからの復元というテーマについては、更に分離して考えてみたほうがよさそうです。というより、ここまで考えた段階でまだ整理がついてない項目もあるので少し時間を置いて考えてみたいと思います。
さて、ここまで書いてみましたが、これらは単に今の工程を少しだけ小さい単位に分割してみただけです。実際には利用するツールによって操作が異なる部分などもあり、もっと工程を小さい単位に分離してみる事もできるとは思いますが、いずれにしても工程を小さく列挙してみただけにすぎません。
問題は、ここからな訳ですが、ここからが難しく感じるわけです。TPSのトレーニングないしはレクチャーを受けたくなります。
いずれにしても、いまは細部を見たので、とりあえず一歩引いて眺めて考えてみることにします。
*1:もちろん、やみくもに操作していると無駄が多いですから手順の標準化は必要です。とはいえ、電子メールにフォーカスできるのであまり判断に迷うケースは少ないのではないでしょうか。
