Восстанавливаем удалённый файл через /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//fd/ также может быть ограничен правами и настройками системы. Восстановить данные нужно до закрытия последнего FD: после этого при нулевом link count ядро сможет освободить inode и блоки файла.
🔥 Поэтому после случайного rm активного файла не спешите перезапускать процесс — сначала проверьте: sudo lsof +L1. Пока FD открыт, данные ещё могут быть доступны через /proc//fd/.
🚪 Linux Ready | #практика
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//fd/ также может быть ограничен правами и настройками системы. Восстановить данные нужно до закрытия последнего FD: после этого при нулевом link count ядро сможет освободить inode и блоки файла.
🔥 Поэтому после случайного rm активного файла не спешите перезапускать процесс — сначала проверьте: sudo lsof +L1. Пока FD открыт, данные ещё могут быть доступны через /proc//fd/.
🚪 Linux Ready | #практика