Восстановить удаленную версию конфигурации nginx
Сообщение no init foundсообщает мне, что ядро Linux уже запущено, но не может найти /sbin/initв корневой файловой системе, возможно, потому, что оно ищет не в том месте.
Узнайте, как настройки загрузчика Linux определяют корневую файловую систему. Обычно это опция root=для ядра Linux.
Если корневая файловая система идентифицируется как /dev/sdaN(, где N — это число ), то она указывает N-й раздел на том диске, который будет обнаружен первым драйверами, включенными в ваш файл initramfs/initrd. Когда у вас подключен только диск Linux, это предположение верно, и ваша система загружается нормально. Но когда оба диска подключены, ваш диск с Windows обнаруживается первым, и опция root=/dev/sdaNэффективно указывает на неправильный диск.
Лучший способ исправить это — указать корневую файловую систему так, чтобы она не зависела от порядка обнаружения дисков.
В Linux запустите blkidот имени пользователя root. Он перечислит все разделы диска, которые он может видеть, и все идентификаторы для них. Найдите строку, соответствующую разделу, содержащему вашу корневую файловую систему :, в ней должно быть указано значение UUID=<a long hexadecimal string>. Он может иметь или не иметь LABEL=<a short name>. Также будут внесены в список PARTUUIDи, возможно, PARTLABEL; игнорируй их.
В большинстве дистрибутивов Linuxвы можете изменить опцию root=/dev/sdaNна форму root=UUID=<the long hexadecimal string form blkid>. Таким образом, ваша корневая файловая система будет явно идентифицирована по уникальному UUID файловой системы, а не по порядку ее обнаружения.
Поскольку вы не указали название и версию вашего дистрибутива Linux, я не могу сказать вам, где именно вы должны сделать эту модификацию, так как расположение конфигурации загрузчика несколько различается в разных дистрибутивах Linux. Но в современных дистрибутивах /etc/default/grubможет быть хорошим предположением. После изменения /etc/default/grubвам, как правило, придется выполнить какую-то команду для обновления фактического загрузчика :, это может быть update-grubили grub-mkconfigили что-то подобное.
Вы не можете восстановить его. в следующий раз ты должен сделать:
sed -ibak 's/php7.2-fpm/php7.4-fpm/g' /etc/nginx/sites-enabled/default
Это заменит файл /etc/nginx/sites-enabled/defaultвнесенными вами изменениями. И создаст /etc/nginx/sites-enabled/defaultbakв качестве резервной копии.
Если вам ультра повезло, у вас может быть похожий файл в /etc/nginx/sites-available/default.
Изучение запущенного процесса Nginx
Если Nginx все еще работает (, не перезапускайте его! ), вы можете попросить его сделать дамп конфигурации . У меня нет опыта работы с Nginx, так что это просто то, что я читал в Интернете, я не знаю, сколько информации вы можете восстановить таким образом или что может пойти не так, если вы попробуете это сделать.
/usr/sbin/nginx -c /some/other/config -T
В более старых версиях вы можете попытаться получить дамп конфигурации из запущенного процесса трудным путем . Я не знаю, насколько это сложно и есть ли надежда прочитать файл конфигурации после того, как сервер поработает какое-то время.
Вы можете получить дамп информации о конфигурации в ее внутреннем двоичном представлении , даже если исходный текст файла конфигурации более недоступен. По крайней мере, у вас была бы конфигурация, но не комментарии.
Поиск удаленных файлов
Удаленный контент остается на диске до тех пор, пока не будет перезаписан. Но найти его бывает очень сложно. Дисковые блоки с удаленным содержимым немедленно становятся доступными для повторного использования, и нет особой причины, по которой длинные -удаленные блоки будут перезаписываться перед вновь удаленными блоками. Так что не надейтесь.
Еще одна причина не питать надежды состоит в том, что вы, скорее всего, найдете много старых копий файла.Если файл больше, чем блок файловой системы (, часто 4 КБ, но это зависит от файловой системы и конфигурации ), может быть трудно или невозможно собрать части одной версии вместе. Но есть небольшой шанс, что вы сможете что-то найти.
Убедитесь, что вы больше не пишете на диск . В идеале вы должны монтировать файловую систему только для чтения -. Команда mount -o remount,ro /делает это, но она работает только в том случае, если нет файлов, открытых для записи, поэтому, например, она не будет работать, если /var/logнаходится в той же файловой системе, что и /etc. Вы можете отключить службу ведения журналов, чтобы журналы не перезаписывали только что удаленный файл. Возможно, вам придется форсировать проблему . Если вы решите не форсировать это, будьте очень осторожны, чтобы не писать как можно больше. Если вам нужно установить новое программное обеспечение, убедитесь, что записываете в другую файловую систему. Если вы что-то восстановили, запишите их в какую-нибудь другую файловую систему.
Восстановление файлов затруднено. Это акт отчаяния. Если вам действительно нужно это сделать, я предлагаю начать с руководства по Arch Wiki (. В Arch Wiki обычно содержится полезная информация, даже если вы не используете Arch Linux ).
Предотвращение подобных инцидентов в будущем
Сделать резервную копию .
Держите файлы конфигурации под контролем версий. Я использую etckeeper для
/etcна всех машинах Linux, которые я обслуживаю. Активируйте ежедневную автоматическую фиксацию, если вы не дисциплинированы в отношении фиксации. Помимо хранения копий старых версий, это дает вам возможность задокументировать, почему вы внесли изменение.