Я случайно архивировал свой целый сервер
Это может быть сделано при наличии сценария для автоматической публикации repo к веб-серверу каждые X минуты, этот сценарий должен только проверить, что изменения произошли с репозиторием и продолжают развертывать его.
Это очень полезно для сценариев разработки, знать, хотя то автоматическое развертывание действительно не рекомендуется для напоминания (я знаю, что Вы не спрашиваете, для которого, это - просто рекомендация),
Это будет зависеть от того, достаточно ли отремонтированы файловые системы, чтобы вы могли смонтировать эти разделы с LiveCD. Не пытайтесь пока загрузить систему. Сначала смонтируйте разделы и разархивируйте все файлы .gz. Это даст вам рабочие копии init и системных двоичных файлов. Затем вы можете использовать grub для восстановления загрузочного сектора. Затем загрузитесь в однопользовательский режим и снова проверьте файловую систему. Если это сработает, у вас будет работающая система. У вас также будет куча распакованных файлов (например, страниц руководства), которые действительно следует заархивировать, но это лучше, чем иметь незагружаемую систему.
Если вы не можете смонтировать разделы с LiveCD, то, к сожалению, вас нет. удачи. На этом этапе ничто не восстановит вашу систему.
Первое, что я попробую, это запустить среду LiveCD и просто попытайтесь разархивировать все, надеясь, что это вернет систему в состояние загрузки. Примечание: я был бы обеспокоен потенциальным повреждением данных, если бы исходный процесс gzip был прерван.
В противном случае я бы попытался перенести БД в новую систему, как предлагали другие, но, как вы столкнулись, это может быть трудоемким проблемы зависимости и конфигурации, которые необходимо решать индивидуально.
Общий консенсус здесь, что вы должны просто смонтировать диск в работающую систему и спасти свои файлы, это не так. Это разумный поступок. Но другой способ более интересный и очень познавательный. Я многому научился, пытаясь выбраться из неприятных ситуаций, когда другие люди просто сдались бы и переустановили с нуля. (Хотя не на сервере, от которого зависят другие люди ...)
В любом случае, пока у вас есть запущенный initramfs (initrd). Это хорошее начало. Но он не может завершить передачу на init, потому что init теперь init.gz , может быть? Чтобы добиться прогресса, полезно знать, какой именно у вас дистрибутив Linux, чтобы мы могли узнать, какие инструменты доступны в его initramfs для экстренного использования.
Представленные вами сообщения об ошибках выглядят так, как будто они могли быть получены из initramfs Debian. . Если это Debian, тогда вы должны получить приглашение оболочки (initramfs) на следующей строке после последней ошибки. Если да, то вам стоит разобраться, что происходит с этими неудачными креплениями. отсутствует / root / dev ? ( / root - это место, где ваша обычная корневая fs должна быть смонтирована во время запуска initramfs)
Если вы не получили приглашение оболочки, то что было после Нет init не найден. Попробуйте передать init = bootarg. будет интересно. Даже если это был всего лишь мигающий курсор, это ключ к разгадке. Если он кажется полностью замороженным, попробуйте получить некоторую информацию о том, какие процессы еще выполняются, используя волшебный sysrq или Ctrl + ScrollLock.
Debian initramfs также позволяет вам запрашивать оболочку на нескольких особых ориентирах, добавляя break = параметр в командной строке ядра. Например,