Из файловой копии VPS часто можно вернуть приложение, конфигурацию и загруженные документы. Базу нужно проверять отдельно: скопированный каталог работающей СУБД может оказаться непригодным для запуска. Beget прямо предупреждает, что файловый способ подходит не всем сервисам. Руководство Beget по копированию VPS.
Разберите архив по тому, как данные восстанавливаются
| Что нашли | Первый шаг |
|---|---|
| Репозиторий и конфигурацию | Развернуть приложение совместимой версии |
| SQL-дамп | Импортировать отдельно и проверить контрольные записи |
| Каталог данных СУБД | Проверить версию, тип копии и возможность запуска на копии файлов |
| Тома контейнеров | Сопоставить с сервисами и путями монтирования |
| Очередь или её хранилище | Понять, какие операции можно повторить безопасно |
| Журналы и метрики | Определить последний успешный запуск и время сбоя |
Если архив скопирован во время работы приложений, у разных файлов могут быть разные моменты создания. У базы и очереди это особенно заметно: в одном архиве задача числится открытой, а платёжный сервис уже считает её выполненной. Отметьте такие расхождения до запуска обработчиков.
Какие проверки провести в изоляции
Начните со входа и чтения данных. Затем выполните тестовую запись и проверьте, что она остаётся в базе после нового подключения. Для фоновых задач заведите тестовый объект, который не вызывает настоящих писем, списаний и запросов к боевым API. Посмотрите журнал исполнения и результат со стороны приложения.
Проверьте права на файлы и доступ к внешним хранилищам. Если в старом архиве сохранились токены, уточните, какие из них уже отозваны. При подозрении на раскрытие выпустите новые. Запишите, кто отвечает за обновления ОС и приложения после перехода.
Как провести переключение без двух активных обработчиков
Перед запуском проверьте, что старый сервер не продолжает получать те же события. У платёжных вебхуков, рассылок и фоновых заданий должна быть одна рабочая точка обработки. Смените адрес у внешних сервисов по согласованному порядку и проследите за первыми результатами. Повторную доставку события сопоставляйте по его идентификатору, если система его предоставляет.
Представим, что сервис принимает заявки через API и складывает задания в очередь. После восстановления первый запрос создаётся, но пользователь не видит результата. В такой ситуации сравните состояние задачи в очереди и журнал исполнителя. Проверка только HTTP-кода пропустит этот сбой.
Что записать для следующего восстановления
Укажите дату пригодной копии, сколько заняло восстановление и какие операции проверили. Перечислите зависимости, которые пришлось восстанавливать вручную. Для каждой задачи назначьте ответственного и место хранения следующей копии. Отдельно зафиксируйте, сколько недавних данных компания может восстановить по внешним источникам.
Когда можно отказаться от старой машины
Сохраните старые журналы, конфигурацию и контрольную копию данных до того, как команда примет новую площадку. Проверьте редкие задачи, которые не срабатывают при обычном заходе на сайт: ночной экспорт, выгрузку документов и обновление сертификатов. Если какой-то процесс запускается раз в месяц, его лучше проверить в изоляции, чем ждать календарного запуска.
Резервный сервер имеет смысл только тогда, когда понятно, как вернуть в работу данные. Если копия лежит там же, где работает основной сервис, предусмотрите ещё один путь доступа к ней.
Что искать в архиве
Сохраните исходную копию и работайте с дубликатом. Найдите исходный код, конфигурацию веб-сервера, файлы развёртывания, задания cron, тома контейнеров и пользовательские загрузки. Отдельно найдите дампы базы или проверьте, есть ли управляемая база за пределами VPS. Секреты храните в закрытом хранилище и обновите их, если есть основания считать, что они могли быть раскрыты.
Сначала база, затем приложение
Если есть логический дамп, восстановите его в изолированную базу и сравните даты и контрольные записи. Если остались только файлы СУБД, выясните точную версию и способ создания копии. Работайте с копией файлов в отдельной среде. Для сервиса с оплатой сверяйте восстановленные записи с выгрузкой платёжного провайдера до запуска фоновой обработки.
На новом VPS установите нужные версии компонентов и разверните приложение. Проверьте доступ к данным, загрузки, API и вход. Пока идёт проверка, оставьте выключенными фоновые отправки и обработчики внешних событий. Затем включайте их по одному и отслеживайте повторы: восстановленная очередь может содержать задачу, которая уже была выполнена до сбоя.
Что может остаться за пределами файловой копии
Отдельно проверьте внешние диски, объектное хранилище, секреты CI, сертификаты, конфигурацию балансировщика и задачи, запускаемые вне сервера. Бывает, что приложение на новом VPS стартует, но не находит файлы, которые раньше монтировались с другого диска. Список таких зависимостей удобно составить по конфигурации и журналу первого запуска.
Ссылки в рейтинге партнёрские. Ссылка Hostland ведёт в раздел выделенных серверов, доступность VPS уточняйте у провайдера.
Рейтинг VPS/VDS
VPS/VDS ����� ���� ���室�騬 ���⮬ ��� ����⠭������� �ࢨ�, � ��� �㦭� ᮡ�⢥��� ��⥬�� ����ன�� ��� 䮭��� ������. �� ������ �����, �� 䠩����� ����� �����筮 ��� �ਫ������, ��� ����⠭����� ���� � �� �㤥� ���㦨���� �ࢥ�.
Что проверить после запуска
Проверьте сайт и API снаружи, убедитесь, что новые записи сохраняются, а фоновые задачи завершаются. Настройте регулярную выгрузку базы и файлов вне нового VPS. Восстановите пробную копию отдельно и засеките время. Тогда при следующем инциденте у команды будет проверенный порядок действий и понятная дата последнего пригодного архива.
Как подобрать VPS/VDS для восстановления сервиса
Рейтинг ниже уже перечисляет варианты в согласованном порядке: Timeweb Cloud, Selectel, EdgeCenter, VDSina, SpaceWeb, AdminVPS, Sprintbox, Hostland, HandyHost и FirstVDS. Он служит отправной точкой для запроса условий, а не сравнительным тестом производительности и не подтверждением восстановления каждого типа файлов. Перед заказом подтвердите доступность подходящей конфигурации и услуги миграции. Для Hostland отдельно уточните именно VPS/VDS: партнёрская ссылка рейтинга ведёт в раздел выделенных серверов, что само по себе не доказывает наличие нужной виртуальной услуги.
Для выбора сравнивайте не число ядер на витрине, а профиль нагрузки: пиковое число запросов, потребление памяти, объём базы, рост загрузок, хранение резервных копий и необходимость отдельной среды для тестирования. Если точных метрик нет, начните с текущих журналов и счёта ресурсов до сбоя, а затем проверьте нагрузку на временной копии.
До создания сервера опишите требования приложений
Составьте перечень версий операционной системы, языка, базы и веб-сервера, которые нужны приложению. Отдельно перечислите cron, контейнеры, очереди, точки монтирования, API и внешнее объектное хранилище. Зафиксируйте порты, домены и требования к сертификатам, но не переносите секреты в общий документ. Так вы избежите ситуации, когда приложение стартует, но не запускаются фоновые обработчики или не находятся постоянные данные.
Спросите будущего администратора, кто устанавливает обновления и следит за журналами, кто отвечает за копии и как быстро можно получить консоль при отказе сети. Для VPS с самостоятельным администрированием заложите часы специалиста и резервный доступ. Услуга VPS сама по себе не является планом обслуживания.
Восстановите сервис в изоляции
Поднимите сеть с ограниченным доступом и восстановите базу и приложение отдельно от боевого трафика. Отключите реальные уведомления, платежные операции и обработку вебхуков. Сначала проверьте чтение данных, затем тестовую запись, после — очередь и интеграции в безопасном режиме. Убедитесь, что задания не обработают повторно уже оплаченные заказы. Для каждой проверки записывайте входные условия и результат, не включая в журнал токены или клиентские данные.
Проверьте создание новой резервной копии на целевой стороне и убедитесь, что она сохраняется вне единственного диска сервера. Для бэкапа важен не факт создания архива, а возможность развернуть его в изолированной среде. Назначьте ответственного за периодическую проверку восстановления и срок хранения копий.
Согласуйте переключение и период наблюдения
До изменения DNS договоритесь, в какой момент прекращается запись на старом источнике и как передаются последние данные. Для API отдельно проверьте вебхуки, очереди и внешние IP allowlist. Перенесите сертификаты безопасным способом или выпустите новые. После переключения проверьте пользовательский путь снаружи: вход, создание записи, получение результата и отправку уведомления.
Оставьте период наблюдения, в который команда проверяет задержки, ошибки, расход памяти и заполнение диска. Не удаляйте исходную файловую копию и не отключайте прежний сервер, пока не прошли основные сценарии и не сохранены новые данные. Зафиксируйте время восстановления и потерю данных, если она была. Следующее восстановление будет быстрее, если из этих заметок сделать проверяемую инструкцию и провести пробный запуск заранее.
Проверьте восстановление до назначения VPS основным
Создайте изолированную копию сервера и проверьте, что архив можно не только распаковать, но и использовать для запуска приложения. Зафиксируйте версии операционной системы, базы, интерпретатора и веб-сервера, затем сопоставьте их с конфигурацией в архиве. Проверяйте зависимости по одной: постоянные тома, файлы окружения, сертификаты, записи DNS, секреты CI, внешнее объектное хранилище. Если файл отсутствует, найдите источник и владельца, а не подставляйте предполагаемое значение.
Для базы используйте логический дамп или проверенный механизм резервного копирования. Копия активного каталога СУБД не гарантирует согласованность. В тестовой среде сравните количество важных таблиц и контрольные данные. Выполните тестовую запись, перезапустите приложение и убедитесь, что запись сохранилась. Для очередей проверьте, что завершённые операции не будут выполнены повторно.
Не забывайте о доступе и безопасности нового сервера
Перед запуском проверьте SSH-доступ, отдельные учётные записи, ключи, права на файлы и закрытые переменные окружения. Если инцидент мог затронуть архив или сервер, обновите секреты и ключи интеграций. Не переносите старые временные аккаунты без необходимости. Закройте тестовые порты и ограничьте доступ к административным страницам в соответствии с архитектурой проекта.
Проверьте обновления ОС и компонентов в рамках отдельного плана. Не выполняйте крупные обновления параллельно восстановлению, если это не требуется для запуска: так сложнее определить источник ошибки. Зафиксируйте, кто будет устанавливать патчи после миграции и кто получает уведомление о критической проблеме.
Подготовьте два способа восстановить работу
Кроме основного VPS, храните копию файлов и базы в отдельном месте, доступном при проблеме с аккаунтом хостинга. Проверьте, что у ответственного есть права на скачивание и ключ восстановления. Хранение архива у того же поставщика может быть удобно, но не поможет, если недоступна панель или аккаунт целиком. План должен предусматривать независимый маршрут получения данных.
Запишите дату последней проверенной копии и время тестового восстановления. Если восстановление занимает дольше допустимого бизнесом, измените частоту копий, автоматизацию или архитектуру. Само наличие резервного сервера не заменяет проверку базы и приложений.
Завершите перенос по критериям, а не по факту запуска
Назначьте контрольные сценарии: вход пользователя, чтение и запись данных, приём заявки, генерация документа, обработка очереди и отправка уведомления. Определите, кто подтверждает их прохождение и сколько длится период наблюдения. После переключения сверяйте события по идентификаторам и времени. Сохраняйте прежний сервер до завершения этой проверки, но не оставляйте его параллельно обрабатывать одни и те же события.
Итоговый протокол должен содержать версии, дату копии, продолжительность восстановления, известную потерю данных и оставшиеся риски. Не включайте в него ключи, токены и клиентские данные. На основании протокола обновите инструкцию и проведите повторное тестовое восстановление через установленный срок.