2016/10/18 20:17:28

Linuxの恐怖体験「rmで間違ってファイル消してしまった!」そんな時はextundeleteでリカバリ

目次(クリックするとジャンプします)
  • 1:消しちゃった…?
  • 2:extundeleteのインストール
  • 3:リカバリの手順
  • 3.1:前提条件
  • 3.2:パーティションの特定
  • 3.3:リカバリ対象時間の設定
  • 3.4:リカバリするファイル・ディレクトリの指定
  • 3.5:コマンドの実行
  • 3.6:アンマウントの必要性
  • 3.7:リカバリ後
  • 4:まとめ

消しちゃった…?

rmコマンドで重要なファイルを消してしまったことがあるのは@MINOだけではないはず。

コマンドに慣れてくるとrm -rfでやろうとするので、ヘタするとディレクトリごと逝くこともあります。 タイポしなけれないいんですがね…。

さて消してしまったのを嘆いていてもしょうがありません。なんとかしてファイルなりディレクトリなりを復活させないと誰かに土下座しないといけなくなります。

土下座をするのはいいのですが、土下座しても許されない場合もちらほら。

extundeleteのインストール

debian/ubuntuではパッケージがありますので、以下で簡単にインストールできます。

$ sudo apt-get install extundelete

ArchLinuxもパッケージがあるそうです。ほかは調べてません…。

もしパッケージがないディストリビューションの場合はソースからインストールしてください。

extundeleteの説明(英語)

ソースは以下にあります。

https://sourceforge.net/projects/extundelete/files/latest/download

GitHubには置いてないのかな?

リカバリの手順

前提条件

extundeleteはファイルシステムがext3ext4であることが必要です。

パーティションの特定

まず消してしまったファイル・ディレクトリが存在しているパーティションを特定します。

$sudo fdisk -l

@MINOのノートパソコンでは以下のように出力がありました。これは各位の運用で全く構成が異なるのであくまでも例です。

Disk /dev/sda: 698.7 GiB, 750156374016 bytes, 1465149168 sectors
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: 5CCB0D33-B60A-4A0B-89E7-A2AAD59F12A3

Device         Start        End   Sectors   Size Type
/dev/sda1       2048     616447    614400   300M Windows recovery environment
/dev/sda2     616448     821247    204800   100M EFI System
/dev/sda3     821248    1083391    262144   128M Microsoft reserved
/dev/sda4    1083392  310534143 309450752 147.6G Microsoft basic data
/dev/sda5  310534144  701159423 390625280 186.3G Linux filesystem
/dev/sda6  701159424  712878079  11718656   5.6G Linux swap
/dev/sda7  712880128 1103505127 390625000 186.3G Microsoft basic data

Disk /dev/mmcblk0: 29.9 GiB, 32127320064 bytes, 62748672 sectors
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x0cbcc978

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk0p1       8192 62748671 62740480 29.9G  c W95 FAT32 (LBA)

デュアルブートしているのでwindowsのパーティションが存在していますが(/dev/sda7)これは関係なくて、@MINOのシステムでは/dev/sda5(Linux filesystem)が対象のパーティションとわかります。

dfコマンドでTオプションをつけるとファイルシステムも確認できます。

$df -T

このような出力があります。

ファイルシス   タイプ   1K-ブロック     使用    使用可 使用% マウント位置
/dev/sda5      ext4       192115292 56200072 126133204   31% /
~~~
~~~

ext3 ext4以外のファイルシステムを使っている場合は…ここで脱落です…。

リカバリ対象時間の設定

特定したパーティションを指定します。

時間で指定するのが一般的なようです。いつからいつまでという指定が可能です。

オプション 意味
–after いつから
–before いつまで

日付時間の指定はエポックタイムで行うようです。エポックタイムはUTC1970-01-01T00:00:00からの経過秒です。UNIX時間とも言います。

現在時のエポックタイムは以下の様にして取得できます。

$ date +%s
1462172732

任意の日付を指定する場合は以下です。

date +%s --date "2016-01-01 00:00"
1451574000

2016年1月1日00:00から2016年1月1日2:00までを指定する場合は以下のようになります。

extundelete --after 1451574000 --before 1451581200

コマンド展開を使ってもOKです。

extundelete --after $(date +%s --date "2016-01-01 00:00") --before (date +%s --date "2016-01-01 02:00")

もし現在までとしたいなら--before は設定せず--afterのみ設定します。

リカバリするファイル・ディレクトリの指定

次にリカバリしたいファイル・ディレクトリを指定します。

オプション 意味
–restore-files ファイル指定
–restore-directory ディレクトリ指定
–restore-all すべてを対象に

ファイル・ディレクトリはパスで設定します。例えばこうです。

extundelete --restore-file /home/hoge/hoge.dat
extundelete --restore-directory /home/hoge/

対象がしっかりわかっている場合はファイル・ディレクトリを指定するのもいいですが、--restore-allを指定すると、rmされたファイル・ディレクトリがすべてリカバリの対象になります。このオプションは結構便利です。とりあえず迷ったら--restore-allで良いと思います。

コマンドの実行

さてここまで来たら後は先ほど調べたパーティションを指定します。ここまでのコマンドを全部書いたものが以下です。

$ sudo extundelete --after 1451574000 --before 1451581200 --restore-all /dev/sda5/

これを実行するとファイルのリカバリが始まります。

extundeleteコマンドを実行した時のカレントディレクトリにリカバリディレクトリが作られます。

アンマウントの必要性

コマンドを実行すると以下のようなメッセージが出力されるかもしれません。

Only show and process deleted entries if they are deleted on or after 1462150800 and before 9223372036854775807.
NOTICE: Extended attributes are not restored.
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.
The partition should be unmounted to undelete any files without further data loss.
If the partition is not currently mounted, this message indicates 
it was improperly unmounted, and you should run fsck before continuing.
If you decide to continue, extundelete may overwrite some of the deleted
files and make recovering those files impossible.  You should unmount the
file system and check it with fsck before using extundelete.
Would you like to continue? (y/n) 

これはリカバリ対象のパーティションのアンマウントが行われていない場合に出力される警告です。

extundeleteではアンマウントしていないパーティションでは問題が発生する可能性があります。もう少し具体的に言うとファイルを上書きしてしまう可能性があることを示唆しています。

extundelete may overwrite some of the deleted files and make recovering those files impossible.

ディレクトリごとにパーティションを分けている場合はアンマウントも簡単かもしれませんが、ルートにパーティションをマウントしている場合はumountはビジーで失敗するかと思うので、別システムからのリカバリが必要になります。

一応、アンマウントしなくてもextundeleteは実行でき、@MINOの場合いままで不都合はありませんでした

でも慎重を期すならアンマウントできる体制でリカバリした方がいいです。この辺は自己責任ですので…。

リカバリ後

さてリカバリが終わるとRECOVERED_FILES/というディレクトリにリカバリが成功したファイルディレクトリが入っています。

$ ls -al
~~
~~
drwxr-xr-x  6 root      root        4096  5月  2 15:20 RECOVERED_FILES
~~
~~

後はこの中から目的のファイルを探してください。

無事リカバリできていると涙がでますね!

まとめ

rm -rfでまちがったものを消した時の冷や汗といったら。でもこのextundeleteがあると安心できますね。

でもあまり過信は禁物です。リカバリが100%ではありません。時間が経過するとリカバリできなくなる可能性が高いです。

まずは不用意なrmをしないことが肝要のようです。