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

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

Нужен перенос прямо сейчас? Не переустанавливайте старый VPS, не удаляйте услугу и не меняйте DNS на неподготовленный сервер. Сначала зафиксируйте доступные источники данных и создайте срочный тикет. Для типового сайта или приложения на одном VPS целевое время восстановления основной функции — от 1 до 3 часов после оплаты, получения рабочих доступов и подготовки нового сервера.

Что сделать в первые 15 минут

1. Не удаляйте и не переустанавливайте старый VPS. Даже если панель показывает ошибку, диск или виртуальная машина ещё могут быть доступны через SSH, RDP, KVM, rescue-режим, snapshot или API провайдера.
2. Не перезагружайте сервер несколько раз подряд. Если проблема связана с файловой системой, диском или незавершённым обновлением, повторные перезапуски могут усложнить восстановление.
3. Проверьте доступ напрямую по IP. Панель провайдера может не работать, пока сам VPS продолжает отвечать по SSH, RDP, HTTP или через VPN.
4. Найдите последнюю резервную копию. Проверьте дату, размер и место хранения. Копия на том же недоступном VPS сейчас не считается доступной резервной копией.
5. Сохраните всё, что ещё открывается. Скачайте backup, экспорт базы, конфигурацию приложения, список доменов, сведения о DNS и данные о текущем окружении на независимое устройство или хранилище.
6. Остановите несогласованные изменения. Не обновляйте приложение, не меняйте версии PHP и базы данных, не запускайте очистку диска и не переключайте DNS до подготовки нового сервера.

Если SSH ещё отвечает, можно собрать первичную диагностику безопасными командами, которые ничего не изменяют:

uptime
df -h
df -i
free -m
systemctl --failed
journalctl -p err -n 80 --no-pager
ss -lntup

Сохраните вывод и приложите его к тикету. Если команды незнакомы, лучше не продолжать диагностику вслепую: для начала достаточно сообщить IP, операционную систему, симптомы и время появления проблемы.

Можно ли перенести проект, если панель провайдера не работает

SSH или RDP доступен

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

Есть KVM, rescue-режим, snapshot или доступ к диску

Старый VPS можно загрузить во временной среде, подключить его диск только для чтения или восстановить snapshot на отдельной машине. Такой путь требует больше диагностики, но часто позволяет забрать данные даже при неработающей операционной системе.

Старый сервер полностью недоступен, но есть независимый backup

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

Нет ни доступа, ни резервной копии

Можно развернуть новый сервер, восстановить приложение из репозитория, настроить DNS и вернуть статическую или частично рабочую версию сервиса. Но данные, которые существуют только на недоступном диске прежнего провайдера, технически невозможно воссоздать. Параллельно придётся добиваться доступа к старому VPS, snapshot или выгрузке диска.

Когда аварийный перенос реально занимает 1–3 часа

Для типового односерверного проекта мы ставим цель вернуть основную функцию на новом VPS в течение 1–3 часов. Это может быть сайт, интернет-магазин, API, личный кабинет, небольшой SaaS-сервис, бот или корпоративное приложение.

Такое окно реально, если:

• есть рабочий SSH/RDP-доступ к старому серверу либо проверяемая резервная копия;
• новый VPS уже активирован или может быть быстро подготовлен;
• есть доступ к DNS-зоне домена;
• объём данных позволяет передать критическую часть за доступное время;
• проект работает на понятном стеке без неизвестных внешних зависимостей;
• лицензии, API и сторонние сервисы допускают смену IP;
• состав работ согласован, счёт оплачен и временные доступы переданы инженеру.

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

Как проходит экстренный перенос

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

Первые 15 минут: определяем путь восстановления

• проверяем SSH, RDP, панель, KVM, rescue и доступность backup;
• определяем операционную систему, панель управления, веб-сервер и базу данных;
• выделяем критические функции, которые нужно вернуть первыми;
• оцениваем размер данных, допустимый простой и риски потери новых записей;
• подтверждаем, подходит ли проект под окно 1–3 часа.

15–45 минут: готовим новый VPS

• подбираем ресурсы под текущую нагрузку;
• устанавливаем совместимую операционную систему и необходимые пакеты;
• настраиваем SSH-ключи, firewall, системное время и базовую защиту;
• готовим веб-сервер, PHP или другое окружение, базу данных и каталоги приложения;
• проверяем диск, сеть и доступность нужных портов.

30–120 минут: переносим данные и конфигурацию

• копируем файлы сайта и пользовательские загрузки;
• создаём согласованную копию MySQL, MariaDB, PostgreSQL или другой базы;
• переносим конфигурации Nginx, Apache, PHP-FPM и системных служб;
• восстанавливаем cron, systemd-таймеры, очереди и фоновые процессы;
• для Docker переносим compose-файлы, переменные окружения, секреты и постоянные volumes;
• проверяем владельцев файлов, права доступа и пути, которые могли измениться.

60–180 минут: проверяем и переключаем

• открываем проект на новом сервере через временный домен или локальную запись hosts;
• проверяем подключение к базе, авторизацию, загрузку файлов и критические операции;
• выполняем финальную синхронизацию изменяемых данных;
• переключаем необходимые записи DNS;
• проверяем TLS-сертификат, внешнюю доступность, журналы и мониторинг;
• сохраняем старый сервер как точку возврата, если прежний провайдер оставляет к нему доступ.

Что именно нужно перенести

Работающий сайт — это не только каталог с файлами. Перед переключением проверяется весь контур проекта:

• Приложение: исходный код, пользовательские файлы, конфигурация, переменные окружения и секреты.
• База данных: корректный dump, backup или репликация. Простое копирование файлов работающей базы может дать повреждённое или несогласованное состояние.
• Веб-окружение: Nginx или Apache, PHP-FPM, Node.js, Python, Java и необходимые расширения.
• Фоновые процессы: cron, очереди, workers, systemd-службы, планировщики и обработчики событий.
• DNS: записи A, AAAA, CNAME, MX и другие используемые записи. Забытый AAAA может продолжить направлять часть пользователей на старый сервер.
• HTTPS: выпуск или перенос сертификата, цепочка сертификатов и автоматическое продление.
• Почта: ящики, MX, SPF, DKIM, DMARC и PTR. Почтовый контур оценивается отдельно, особенно если переносится большая история писем.
• Внешние интеграции: платёжные уведомления, webhook, API, IP allowlist, облачные хранилища, CDN и сторонние базы.
• Лицензии: панели и коммерческое ПО, привязанные к старому IP или идентификатору сервера.
• Безопасность: SSH-ключи, firewall, закрытые порты, учётные записи и смена временных доступов после завершения работ.

Как уменьшить простой и не потерять новые данные

Безопасный перенос выполняется параллельно со старой инфраструктурой, пока это возможно:

1. На новый VPS переносится основная масса файлов.
2. Приложение проверяется без изменения публичного DNS.
3. Перед финальным переносом кратко ограничивается запись новых данных, если это требуется архитектурой.
4. Выполняется повторная синхронизация файлов и актуальная выгрузка базы.
5. Проверяются авторизация, запись в базу, загрузка файлов, платежи, API и фоновые задачи.
6. Меняются только необходимые DNS-записи. Переносить сами DNS-серверы во время аварии обычно не требуется.
7. После переключения отслеживаются запросы, ошибки приложения, нагрузка и доступность со сторонней сети.

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

Если есть подозрение на взлом

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

В таком случае безопаснее:

• развернуть чистую операционную систему;
• перенести только проверенные данные и конфигурацию;
• сверить приложение с репозиторием или чистым дистрибутивом;
• сменить пароли, API-ключи, токены и SSH-ключи;
• проверить cron, systemd, автозагрузку, пользователей и открытые порты;
• сохранить старый диск отдельно для последующего анализа.

Такая миграция обычно занимает больше времени, но слепой перенос заражённой системы лишь перемещает аварию на новый IP.

Как проверяется результат

Открытая главная страница ещё не означает, что перенос завершён. Перед сдачей нужно проверить:

• ожидаемые HTTP-ответы и отсутствие циклических редиректов;
• вход пользователей и администраторов;
• чтение и запись данных в базе;
• загрузку и скачивание файлов;
• формы, заказы, оплаты, webhook и API;
• cron, очереди и фоновые workers;
• отправку и получение почты, если она входит в контур;
• DNS, HTTPS и доступность по IPv4 и IPv6;
• логи приложения и системных служб после тестовых операций;
• внешний мониторинг и новую независимую резервную копию.

Что отправить для быстрой оценки

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

Тема: Экстренный перенос VPS

1. Домен и критический сервис:
2. Когда началась недоступность:
3. Что именно не работает:
4. Старый провайдер и IP:
5. SSH/RDP доступен: да / нет
6. Панель, KVM или rescue доступны: да / нет
7. Резервная копия: где находится, дата и размер
8. ОС, панель и основной стек:
9. Примерный объём данных:
10. Есть ли доступ к DNS:
11. Допустимый простой:
12. Почта, Docker, лицензии, API и другие зависимости:
13. Что должно заработать в первую очередь:

Не отправляйте пароли и приватные ключи в Telegram или открытом чате. Для работы лучше создать временный SSH-ключ или отдельную техническую учётную запись, передать доступ по согласованному закрытому каналу, а после переноса отключить его.

Как запустить аварийный перенос

Команда HSTQ сначала проверит, можно ли восстановить основной сервис в течение 1–3 часов, определит состав работ, необходимую конфигурацию нового VPS, возможный простой и стоимость. Вы будете знать границы задачи до оплаты, а не после начала переноса.

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

Создать тикет «Экстренный перенос VPS»

Если войти в личный кабинет не получается, используйте Telegram для первичного обращения, но не отправляйте туда серверные пароли. Чем раньше доступны backup, DNS и хотя бы один способ подключения к старому серверу, тем выше вероятность вернуть проект в работу в пределах 1–3 часов.