/proc, пока процесс держит его открытым!rm удаляет имя файла из каталога, но если какой-либо процесс продолжает держать файл открытым через файловый дескриптор, данные остаются доступны до закрытия последнего такого дескриптора.Предположим, работающий сервис пишет в лог, который случайно удалили:
rm /var/log/app.log
Найти открытые файлы с нулевым количеством жёстких ссылок можно через
lsof. Опция +L1 выбирает открытые файлы, у которых link count меньше 1:sudo lsof +L1
Для удалённого лога вывод может выглядеть так:
app 4217 root 5w REG ... /var/log/app.log (deleted)
Здесь
4217 — PID процесса, 5 — номер файлового дескриптора, а w означает, что он открыт на запись.Соответствующий FD доступен через
procfs:sudo ls -l /proc/4217/fd/5
Символическая ссылка будет указывать на уже удалённый pathname:
/proc/4217/fd/5 -> /var/log/app.log (deleted)
Хотя имени файла в каталоге уже нет, открытый файловый дескриптор всё ещё связан с файловым объектом. Пока последний такой FD не закрыт, содержимое можно скопировать через
/proc:sudo cp /proc/4217/fd/5 /tmp/app.log.recovered
Проверяем восстановленную копию:
ls -lh /tmp/app.log.recovered
При необходимости сравниваем размеры:
sudo stat /proc/4217/fd/5
stat /tmp/app.log.recovered
Это не классический
undelete — cp создаёт новый файл с новым inode и копирует доступное содержимое. Если процесс продолжает запись, копия не гарантирует консистентный snapshot. Доступ через /proc/<PID>/fd/<FD> также может быть ограничен правами и настройками системы. Восстановить данные нужно до закрытия последнего FD: после этого при нулевом link count ядро сможет освободить inode и блоки файла.🔥 Поэтому после случайного
rm активного файла не спешите перезапускать процесс — сначала проверьте: sudo lsof +L1. Пока FD открыт, данные ещё могут быть доступны через /proc/<PID>/fd/<FD>.🚪 Linux Ready | #практика