... 特定の時間にコピーする (そしてファイルのコンテンツのその時点のスナップショットのみを収集する) よりも優れているのは、"tail -f" です。 " そのファイルを新しいファイルに:
tail -c +0 -f /proc/PIDofProgram>/fd/# > /new/path/to/file
(tail の慎重なプログラマーのおかげで、バイナリ出力でも動作します。)
実行時に tail -f 自体はファイルを開いたままにして、元のプログラムが終了したときにファイルがディスクから削除されるのを安全に防ぎます。したがって、tail -f を停止しないでください。 元のプログラムが終了した直後 - 末尾の /new/path/to/file を確認してください まずかどうか あなたが欲しいもの。そうでない場合 (またはその他の理由で満足できない場合) は、元のファイルをもう一度コピーできますが、今回は後 すべての書き込みは「プログラム」によって終了し、まだ実行中の tail -f から の /proc/PIDoftail/fd/ ディレクトリ。
/home が NFS の場合、アクセス/コピーできる .nfsNNNNNNNNNN ファイルが /home/vi にあります。ホームがローカル ファイルシステムの場合、/proc/PID/fd/3 リンクから同じことができるはずです:
cp /proc/PID/fd/3 /tmp/recovered_file
実際にファイルの削除を取り消したい場合は、この件に関するブログ投稿をご覧ください。
lsof を使用して inode 番号を見つけ、debugfs を使用してそれへのハード リンクを再作成します。例:
# lsof -p 12345 | grep /var/log/messages
syslogd 12345 root 3w REG 8,3 3000 987654 /var/log/messages (deleted)
# mount | grep var
/dev/sda2 on /var type ext3 (rw)
# debugfs -w /dev/sda2
debugfs: cd log
debugfs: ln <987654> tmp
debugfs: mi tmp
Mode [0100600]
User ID [0]
Group ID [0]
Size [3181271]
Creation time [1375916400]
Modification time [1375916322]
Access time [1375939901]
Deletion time [9601027] 0
Link count [0] 1
Block count [6232]
File flags [0x0]
...snip...
debugfs: q
# mv /var/log/tmp /var/log/messages
# ls -al /var/log/messages
-rw------- 0 root root 3301 Aug 8 10:10 /var/log/messages
あなたが文句を言う前に、私は今手元に削除されたファイルを持っていないので、私は上記のトランスクリプトを偽造しました;-)
mi を使用しています 削除時間とリンク数を適切な値 (それぞれ 0 と 1) にリセットしますが、正しく機能しません - ls でリンク数がゼロのままであることがわかります .カーネルが inode データをキャッシュしている可能性があると思います。安全のために、debugfs を使用した後は、できるだけ早い機会に fsck を実行する必要があります。
私の経験では、一時ファイル名を使用してリンクを作成し、適切な名前に変更する必要があります。元のファイル名に直接リンクすると、ディレクトリが破損するようです。 YMMV!
- http://glandium.org/blog/?p=87
- http://www.cyberciti.biz/tips/linux-ext3-ext4-deleted-files-recovery-howto.html