Что делать, если VPS не отвечает: базовая диагностика перед миграцией

Внезапная недоступность VPS — это всегда стресс. Но важно не бросаться в миграцию, а сначала локализовать проблему. Переезд на новый сервер не решит ни проблему с сетью, ни повреждённую файловую систему. Ниже — последовательность действий, которая поможет понять, что произошло и стоит ли вообще переезжать.

1. Проверка доступности снаружи

Для начала проверьте, виден ли сервер в сети. С рабочей машины выполните ping и traceroute:

ping -c 4 192.0.2.1
traceroute -m 30 192.0.2.1

Если ping не проходит, но traceroute показывает точку обрыва, возможно, проблема на уровне сети или у хостинг-провайдера. Если же пакеты доходят до сервера, значит, сеть работает, а сбой вызван самим VPS.

Не забудьте проверить доступность с другой сети — возможно, блокировка на вашей стороне или файервол.

2. Доступность по SSH и HTTP

Следующий шаг — проверить, отвечает ли сервер на ключевые порты. Используйте telnet или netcat:

nc -zv 192.0.2.1 22
nc -zv 192.0.2.1 80

Порт 22 открыт и SSH принимает соединения? Тогда проблема может быть в службах выше. Если порт закрыт, проверьте настройки файервола на самом сервере. Для этого войдите в панель управления хостинга и используйте консоль VPS (веб-терминал), чтобы исключить сбои на сетевом интерфейсе.

3. Состояние ресурсов: память, диск, нагрузка

Когда доступ есть, оцените ресурсы. Перегрузка по памяти или диску — частая причина зависаний. Выполните:

free -h
df -h
iostat -x 1 3
uptime

Если память полностью заполнена, диск почти полон или load average выше количества ядер, сервер может деградировать. В таком случае миграция на более мощный VPS или оптимизация приложений — разумное решение.

Проверьте также, нет ли процессов, убивающих память (например, приложения с утечками). OOM-killer оставляет записи в журнале.

4. Системные журналы и dmesg

Журналы покажут, что происходило перед падением. Смотрите системный журнал и сообщения ядра:

journalctl -xb -p err
dmesg -T | tail -50

Ищите признаки нехватки памяти (Out of memory), ошибки I/O (I/O errors), неисправности диска (smart, ata). Если обнаруживаются критические ошибки ядра, миграция на тот же образ без предварительной диагностики приведёт к повторению проблемы на новом сервере.

5. Проверка файловой системы и целостности данных

Перед миграцией обязательно проверите диски на ошибки. Для ext4:

fsck -fn /dev/vda1

Обратите внимание, что проверка должна выполняться при размонтированном разделе, поэтому планируйте её на время простоя. Повреждённая файловая система может вызывать случайные сбои, и при переезде вы рискуете перенести и эти ошибки.

Также сделайте резервную копию. Без полного бэкапа любая миграция опасна.

6. Тестирование на новом VPS перед переносом

Если вы собираетесь мигрировать, восстановите копию на резервном VPS и повторите нагрузочное тестирование. Проверьте сеть, запустите те же команды (ping, ssh, curl к приложению), дайте поработать несколько часов. Только после того, как новый сервер стабильно отвечает, можно переключить трафик.

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

7. Когда миграция действительно нужна

Миграция оправдана, если:

• текущий VPS не соответствует нагрузке по CPU, RAM или диску;
• наблюдаются постоянные сбои из-за проблем оборудования провайдера;
• требуется сменить регион или провайдера.

Во всех остальных случаях стоит сначала устранить причину, а не переносить её на новый сервер.