🥷 Секретные материалы: Воскрешаем удаленный файл из небытия (Linux)

Коллеги, ситуация — ночной кошмар. Вы чистили место на сервере и случайно сделали `rm -rf` не в той директории. Удалили критически важный лог, конфиг, а то и рабочий файл базы данных. Бэкап был вчера. Паника? Заявление по собственному?

Стоп. Если процесс, который работал с этим файлом, всё ещё запущен и держит его открытым, файл физически жив. Linux не удаляет данные с диска, пока на inode есть хотя бы одна ссылка (в данном случае — файловый дескриптор в оперативной памяти ядра).

Показываю «черную магию» системного администрирования — как достать удаленный файл прямо из подсистемы `/proc`.

Шаг 1: Находим, кто держит наш файл
Допустим, мы удалили access.log. Ищем процесс, который его писал:

lsof | grep deleted

Вы увидите примерно такую строку:
nginx 12345 root 3w REG 8,1 5000000 123456 /var/log/nginx/access.log (deleted)

Нам нужны две цифры: PID процесса (12345) и номер файлового дескриптора — FD (**3**, буква 'w' значит write).

Шаг 2: Ныряем в /proc
В Linux всё является файлом, включая сами процессы. Переходим в системную директорию этого процесса:

cd /proc/12345/fd

Если сделать ls -l, вы увидите симлинк под номером 3, указывающий на наш удаленный файл.

Шаг 3: Воскрешение
Не пытайтесь сделать mv или редактировать этот линк. Мы просто копируем живое содержимое дескриптора обратно на диск:

cp 3 /var/log/nginx/access.log

После этого нужно мягко перезапустить сервис (например, `systemctl reload nginx`), чтобы он отпустил старый дескриптор, "забыл" удаленный файл и подхватил наш восстановленный.

Это фундаментальное знание архитектуры VFS (Virtual File System), которое однажды спасет вам карьеру. Никаких сторонних утилит для восстановления данных вроде `testdisk` или `photorec`. Главное правило — если удалили нужный файл, НИ В КОЕМ СЛУЧАЕ не убивайте сервис, который с ним работал!

#linux #darkarts #recovery #sysadmin #magic #admin_future