質問: 管理者用初期化URLを踏んでWebサービスのデータをふっとばした話 - Qiita 上記の記事を読んでいました。そこでは、 `rm` してしまったファイルたちを、いろいろやって復旧させた作業の内容が記されています。 ここでふと疑問に思ったのが、どうして ext4 だと `rm` してしまったファイルたちは、復旧可能なのでしょうか? また、記事中で復旧できなくなるのを防ぐために、ひとまずいろいろなプロセスを止めてディスクI/Oを防いでバックアップを取った、みたいな記述があったのですが、ここで逆に、どのタイミングになるとこれらファイルたちは復旧不可能になってしまうのでしょうか?
回答: 「`ext4` だから復旧できた」ではなく、「`extundelete` を使って復旧した」方に注目してみましょう。 参照しているページから参考リンクを順に辿っていくと、例えば以下のページで解説があり、extundelete では **"パーティションのジャーナルを元に復旧を試みている"** 事がわかります。 extundeleteによる削除済みファイルの復元方法 > > ### より深い理解のために(上級者向け) > > > (前略) > > しかし,ext4/ext3では,inode上のファイル本体を格納していたブロックのアドレスやファイルサイズの情報がすべてクリアされてしまうのです.したがって,未割りあてになっているinodeを強引に読んで目的のファイルを復元してしまうという方法がとれません. > > > そのため,ext4/ext3では,(1)ファイルの特性を使って復元するか[例えばJPEGファイルは仕様上0xFFD8ではじまって0xFFD9で終わることがわかってるため,この情報を頼りに復元することができます],(2)ジャーナルのログエントリを利用して復元するかの2通りしかなく,かつ,いずれもext2の場合より復元できる確率も低く,精度も悪くなります. > > > なお、extundelete の配布ページにも同じような内容が記載されています。 > > extundelete uses information stored in the partition's journal to attempt to recover a file that has been deleted from the partition. > > > (訳) > > extundelete では、パーティションのジャーナルに格納されている情報を使用して、パーティションから削除されたファイルの回復を試みます。 > > > extundelete でも復旧が難しくなるタイミングは、元のファイルで使用していた inode が追跡できなかった、もしくは別のファイルで上書きされてしまったタイミング、ではないでしょうか。 Ubuntu で $ rm ~/.bashrc を実行してしまった > > ただし、 inode が重複したりして追跡が出来なかったようなファイルは、最新の inode で復活されるので、目的のファイルが復活されない場合もあります。 > > >