Как восстановить VPS после неудачного изменения

После неудачного изменения не начинайте с переустановки всего подряд. Сначала определите границу сбоя: перестал отвечать только сайт, одна служба, SSH или сама операционная система. Чем точнее симптом связан с последним действием, тем уже и надёжнее будет откат.

У этой инструкции три возможных результата. Известную ошибку конфигурации можно вернуть на прежнее значение. Потерянный сетевой доступ часто восстанавливается через консоль хостера. Если система повреждена неизвестным способом или доверие к ней потеряно, правильным восстановлением становится новый VPS из проверенных исходников и копий.

Сначала остановите цепочку изменений

Не запускайте массовое обновление пакетов и не перезагружайте сервер «для проверки», пока не знаете состояние загрузки. Перезагрузка может закрыть последнюю работающую SSH-сессию или активировать конфигурацию, которая ещё не применялась.

Запишите время появления ошибки, последнюю команду, изменённые файлы, текущий IP и доступные способы входа. Если SSH работает, соберите короткий снимок состояния командами только для чтения:

date -u
uptime
systemctl --failed --no-pager
sudo ss -lntup
df -hT

date -u даёт общую временную точку для сопоставления журналов, uptime показывает недавнюю ли была перезагрузка, systemctl --failed перечисляет упавшие службы, ss — слушающие порты, а df помогает сразу заметить заполненный диск. Сохраните вывод локально, прежде чем состояние изменится.

Выберите самый узкий способ возврата

Если известны файл и время изменения, сравните его с сохранённой копией или версией в Git. Не заменяйте весь /etc, когда ошибка находится в одном виртуальном хосте Nginx. Если сбой начался после переключения релиза, верните прежнюю ссылку current, а не пересобирайте сервер.

Полезно заранее различать три понятия:

• rollback возвращает код или конфигурацию к предыдущему рабочему состоянию;
• rescue-среда загружает отдельную систему, чтобы смонтировать и исправить диск VPS;
• rebuild создаёт чистую машину и восстанавливает на ней проверенные данные.

Выбор зависит не от масштаба паники, а от состояния доступа, диска и доверия к системе.

Если не открывается сайт, но SSH доступен

Сначала проверьте конфигурацию именно той службы, которую меняли. Для Nginx тест выполняется без применения файла, после чего можно посмотреть состояние и последние сообщения текущей загрузки:

sudo nginx -t
systemctl status nginx --no-pager
journalctl -u nginx -b --no-pager -n 100

Успешный nginx -t сообщает, что синтаксис корректен и конфигурационные файлы читаются. Если тест показывает путь и строку ошибки, верните эту строку из сохранённой версии, повторите тест и только затем выполните sudo systemctl reload nginx. Команда reload не должна использоваться после проваленного теста.

Для приложения замените имя nginx именем его systemd-службы. В журнале ищите первое сообщение после времени изменения: последующие ошибки часто являются следствием, например невозможность подключиться к уже остановленной базе.

Если SSH пропал после настройки сети

Откройте веб-консоль или последовательную консоль в панели хостера. Это отдельный канал, который не зависит от доступности TCP-порта 22. Проверьте, существует ли сетевой адрес, запущен ли SSH-сервер и слушает ли он ожидаемый порт:

ip -brief address
systemctl status ssh --no-pager
sudo ss -lntp | grep sshd
sudo sshd -t

sshd -t проверяет конфигурацию SSH и ничего не перезапускает. Если проверка успешна, изучите firewall. Возвращайте только нужное правило доступа и по возможности ограничьте его своим внешним IP. Не отключайте firewall целиком на публичном VPS.

Старую консольную сессию оставьте открытой. Из другого терминала установите новый SSH-сеанс и выполните безобидную команду. Только после этого закрывайте аварийную консоль и удаляйте временное правило.

Если сервер не загружается

Сначала посмотрите консоль: сообщение о неверной записи /etc/fstab, повреждённой файловой системе и отсутствующем корневом устройстве требует разных действий. Если загрузчик доступен, rescue.target запускает базовую систему с необходимыми службами, а emergency.target даёт ещё более минимальное окружение. Способ добавить target в параметры ядра зависит от панели и загрузчика.

Когда локальная система не стартует, включите rescue-среду хостера и определите диски. Команды ниже только показывают устройства, файловые системы и известные UUID:

lsblk -f
sudo blkid
sudo file -s /dev/vda1

Не подставляйте /dev/vda1 автоматически: корневой раздел может называться иначе, находиться в LVM или быть зашифрован. Сопоставьте размер, тип файловой системы и UUID с сохранённой схемой. Неверная команда проверки или монтирования, направленная на другой раздел, усложнит восстановление.

Найденную корневую файловую систему сначала можно смонтировать только для чтения. Это позволяет забрать конфигурацию и журналы без новых записей:

sudo install -d -m 0755 /mnt/root
sudo mount -o ro /dev/vda1 /mnt/root
sudo sed -n '1,160p' /mnt/root/etc/fstab

Ожидаемый результат — содержимое fstab установленной системы, а не rescue-среды. Если ошибка очевидна, сохраните исходный файл, перемонтируйте раздел для записи только на время исправления и измените конкретную строку. Перед перезагрузкой размонтируйте файловую систему и верните в панели загрузку с основного диска.

Проверку файловой системы выполняют только штатным инструментом её типа и обычно на размонтированном разделе. Не запускайте fsck наугад: XFS и ext4 обслуживаются разными средствами, а активная файловая система может получить дополнительные повреждения.

Если обновление пакетов прервалось

Сначала убедитесь, что диск не заполнен и другой пакетный процесс не работает. Затем посмотрите журнал установки и состояние незавершённых конфигураций:

df -hT /
ps aux | grep -E '[a]pt|[d]pkg'
sudo tail -n 120 /var/log/apt/term.log
sudo dpkg --audit

Не удаляйте lock-файлы только потому, что менеджер пакетов сообщает о блокировке: активный процесс мог законно держать её. Если процесса нет и dpkg --audit перечисляет незавершённые пакеты, сначала освободите место и разберитесь с конкретной ошибкой. Автоматическая команда исправления без понимания причины способна обновить ещё больше компонентов.

Заполненный диск восстанавливайте без удаления наугад

Команда df показывает заполнение файловой системы, а du — какие каталоги занимают пространство. Удалённый, но открытый процессом файл может оставаться на диске; его покажет lsof +L1, если утилита установлена.

Освобождайте место через штатную ротацию журналов, очистку проверенного временного каталога или перенос собственной резервной копии. Не удаляйте файлы базы, содержимое /var/lib и системные журналы вслепую. После освобождения небольшого резерва перезапустите только службу, которая упала из-за ошибки записи, и проверьте её данные.

Когда исправлять старый VPS уже нельзя

После подтверждённой компрометации root, неизвестного изменения загрузочных файлов или обнаружения посторонних ключей локальный «ремонт» не возвращает доверие. Администратор не может доказать, что нашёл все способы закрепления злоумышленника.

Создайте новый VPS, смените ключи и секреты с доверенного устройства, установите пакеты из официальных источников и восстановите только проверенные данные. Скомпрометированный диск подключайте для расследования или выборочного чтения, но не загружайтесь с него и не переносите исполняемые файлы в production. Подробная последовательность дана в инструкции по восстановлению доверенного сервера.

Проверьте результат снаружи

После возврата доступа повторите исходные проверки и сравните состояние. Затем с другого устройства проверьте DNS, TLS и несколько URL сайта. Убедитесь, что база доступна, фоновые задания не запущены дважды, свободного места достаточно, а новая резервная копия создаётся и скачивается.

Запишите причину, точную команду восстановления и время возврата. Если пришлось угадывать имя диска, путь к конфигурации или способ входа в rescue, добавьте их в аварийную памятку. После восстановления проведите учебную проверку rollback, чтобы следующий сбой не был первым испытанием процедуры.

Источники

• systemd: booting into rescue or emergency targets
• systemctl manual
• Nginx: controlling Nginx
• NIST contingency planning guide