Как восстановить и перенести серверную инфраструктуру: практический чек-лист

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

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

Быстрый маршрут: ответьте на три вопроса.

1. Где находятся данные? Доступен исходный сервер, резервная копия, реплика или только исходный код?
2. Какой тип системы требуется восстановить? Обычный веб-сервис, распределенный кластер или вычислительная среда с GPU?
3. Где ее можно запустить? Подтверждены ли ресурсы нужной конфигурации в конкретном регионе и пуле, а также возможность их выделить именно вашему аккаунту?

Если хотя бы на один вопрос нет ответа, не начинайте массовый перенос. Сначала закройте соответствующий риск.

1. С чего начать: определить проблему и приоритет восстановления

В первые минуты важно отделить сбой интерфейса управления от недоступности самой инфраструктуры. Ошибка в панели провайдера, обрыв SSH, неработающий DNS и повреждение базы данных требуют разных действий. Попытка лечить их одним перезапуском может ухудшить ситуацию.

Что именно недоступно

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

Какие системы восстанавливать первыми

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

RTO (Recovery Time Objective) - целевое время восстановления сервиса. RPO (Recovery Point Objective) - максимально допустимый возраст восстановленных данных. Если последняя рабочая копия сделана шесть часов назад, нельзя обещать RPO в несколько минут без других источников изменений.

Результат этапа: не общее заключение о том, что сервер не работает, а список затронутых систем, приоритетов и известных источников данных.

2. Данные: как восстановить их, если сервер недоступен

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

Сценарий А. Исходный сервер или экспорт доступны

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

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

После создания копии проверьте, что архив читается, а восстановление возможно в изолированной среде. Успешное завершение команды копирования не подтверждает пригодность данных.

Сценарий Б. Сервер недоступен, но есть другие источники

Поиск стоит начинать вне недоступной площадки: независимое объектное хранилище, вынесенная реплика, архив БД, снимок диска в другом контуре, данные интеграционных систем, выгрузки и артефакты CI/CD.

Сценарий В. Нет доступа и нет подтвержденной копии

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

Порядок действий:

1. Откройте обращение через официальный канал владельца инфраструктуры. Укажите идентификаторы ресурсов, временной интервал и требуемый способ получения данных. Не передавайте пароли или ключи в открытом обращении.
2. Проведите поиск независимых резервных копий и данных у доверенных контрагентов. Сверьте период, полноту и юридические права на использование.
3. Отдельно оцените возможность частичного восстановления: код, каталог товаров, документы, медиафайлы и транзакции могут находиться в разных системах.
4. Подготовьте чистую целевую среду, не выдавая ее за восстановленную систему. До возврата данных можно восстановить инфраструктурный каркас, автоматизацию развертывания и изолированный стенд.
5. Зафиксируйте, что именно невозможно вернуть, какие записи придется реконструировать и кто принимает бизнес-риск.

Результат этапа: известен не только план миграции, но и реалистичный объем восстанавливаемых данных.

3. Выбор стратегии переноса: обычный проект, highload или GPU

Универсальная рекомендация взять сервер мощнее прежнего плохо работает. Одному приложению важна производительность одного ядра, другому - задержка сети между сервисами, третьему - пропускная способность дисков или память ускорителя.

Стандартные проекты

Для большинства небольших веб-сервисов практический маршрут начинается с инвентаризации приложения, его БД и внешних зависимостей. На новой площадке подготавливают Linux, безопасный доступ, контейнерную или обычную среду исполнения, сетевые правила, сертификаты и резервное копирование. Затем проводят пробное восстановление и только после этого переключают домен.

Высоконагруженные системы

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

GPU и машинное обучение

Для inference важны задержка, пропускная способность, память GPU, совместимость библиотек и размер моделей. Для обучения добавляются скорость загрузки датасетов, межузловая сеть, устойчивость длительных задач и возможность возобновления из контрольных точек. Доступность GPU конкретной модели необходимо подтверждать до миграции, а не после переноса данных.

4. Как найти провайдера и проверить свободные мощности

Главная ошибка при срочном переносе - принять исправную статус-страницу за доказательство наличия свободных серверов. Это разные сведения.

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

Где проверять: четыре примера

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

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

Как проверять мощность до переноса

1. Выберите разрешенные законом и договором регионы размещения.
2. Сверьте требуемую конфигурацию: CPU, RAM, GPU, тип диска, IOPS, сеть, внешний IP и managed-сервисы.
3. Проверьте ограничения и квоты аккаунта; при необходимости запросите их увеличение.
4. Попытайтесь создать тестовый ресурс подходящего класса в целевой зоне либо получите подтверждение от провайдера, если создание требует отдельного согласования.
5. Проверьте полученный ресурс: фактические характеристики, сеть, диски, доступы и время подготовки.
6. Оцените не только цену вычислений, но и хранение, исходящий трафик, резервные копии, балансировщики, лицензии и поддержку.
7. Уточните возможность последующего масштабирования и условия восстановления после отказа зоны.

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

5. Правовые ограничения: где допустимо размещать данные

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

В российских проектах особое значение имеют требования Федерального закона № 152-ФЗ. Часть 5 статьи 18 регулирует использование баз данных при сборе персональных данных граждан РФ, а статья 12 - трансграничную передачу персональных данных. Конкретная схема обработки, исключения, уведомления и ограничения оцениваются применительно к оператору и его процессам. Сам факт наличия сервера за границей не позволяет сделать однозначный вывод о законности или незаконности всей архитектуры.

Официальные тексты: статья 18 Закона № 152-ФЗ и статья 12 Закона № 152-ФЗ.

6. Чистый Linux-сервер: от root-доступа до работающего приложения

Ниже приведен базовый маршрут для одного сервера с Ubuntu Server 24.04 LTS. Он подходит как ориентир для типового веб-приложения, но не заменяет инфраструктурный проект, настройку отказоустойчивости или развертывание распределенного кластера. Команды выполняются на собственном или разрешенном к администрированию сервере.

Шаг 1. Узнать параметры системы

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

cat /etc/os-release
uname -m
nproc
free -h
lsblk -f
df -h
ip -brief address
ip route

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

Источник: Ubuntu Server: системные требования.

Шаг 2. Создать отдельную административную учетную запись

Если доступ предоставлен только под root, создайте отдельного пользователя с правом администрирования. Имя operator здесь пример: в вашей системе оно должно соответствовать принятой политике учетных записей.

adduser operator
usermod -aG sudo operator
id operator

Команда adduser интерактивна и запросит пароль. Дальше добавьте публичный SSH-ключ администратора разрешенным в организации способом, проверьте права на .ssh и authorized_keys. Приватный ключ никуда не копируйте.

Откройте второе SSH-подключение от имени нового пользователя и убедитесь, что sudo работает. Старую сессию root оставьте открытой до окончания проверки. Только после этого можно отдельно согласовывать изменение правил входа по SSH.

Критерий перехода: новый пользователь действительно входит по SSH и имеет только необходимые права. Не блокируйте root-доступ до проверки альтернативного входа.

Источник: Ubuntu Server: рекомендации по безопасности.

Шаг 3. Подготовить обновления и сетевую защиту

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

sudo apt update
apt list --upgradable
sudo apt upgrade

Далее изучите текущие правила и реальный SSH-порт. Пример ниже предполагает, что SSH работает на TCP/22. Если используется другой порт, команда должна быть изменена до включения firewall.

sudo ufw status verbose
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status numbered

Не запускайте sudo ufw enable автоматически. Сначала проверьте правила, сетевые ACL провайдера, порядок доступа к сервисам и наличие резервного административного канала. После включения firewall в рамках согласованной операции необходимо повторно проверить подключение из отдельной сессии.

Особое внимание к Docker: опубликованные порты контейнеров могут обходить ожидаемые ограничения UFW. Ограничения доступа к контейнерам нужно проектировать с учетом поведения Docker и сетевых правил на уровне провайдера.

Источники: Ubuntu: Firewall, Docker Engine: установка и сетевые ограничения.

Шаг 4. Подготовить Docker и Compose, если они предусмотрены проектом

Для контейнерного приложения используйте поддерживаемый способ установки Docker Engine и Compose Plugin из официального репозитория Docker. Набор команд, ключи репозитория и конфликты с установленными пакетами зависят от состояния ОС, поэтому копировать старые инструкции по установке Docker без проверки не следует.

Порядок: проверить существующие пакеты и версии → подключить официальный репозиторий → установить Docker Engine и Compose Plugin → проверить службу и клиент.

После установки:

sudo systemctl status docker --no-pager
docker --version
docker compose version

Ожидаемый результат: служба работает, обе команды выводят установленные версии. Если пользователь не входит в соответствующую группу, для административных команд может потребоваться sudo. Членство в группе docker дает расширенные права на хосте; не назначайте его автоматически.

Источник: официальная инструкция установки Docker Engine на Ubuntu.

Шаг 5. Развернуть приложение из проверенного источника

На этом этапе должно быть ясно, откуда поступает приложение: проверенный контейнерный образ, утвержденный release-артефакт или репозиторий с известным коммитом. Нельзя брать произвольный образ из неизвестного registry, переносить секреты в исходный код или запускать приложение с необоснованными привилегиями.

Предположим, что у вас уже есть проверенные compose.yaml, образы и необходимые переменные окружения. Тогда безопасная подготовительная проверка выглядит так:

cd /srv/app
sudo docker compose config --quiet
sudo docker compose images

/srv/app - пример заранее подготовленной директории. Здесь нет универсального compose-файла: конфигурация портов, томов, healthcheck, сетей и пользователей контейнеров определяется вашим проектом. Обратите внимание, что docker compose config может показывать подставленные значения переменных; не публикуйте такой вывод целиком, если в нем есть секреты.

После проверки конфигурации, артефактов и сети запуск согласовывается отдельно:

sudo docker compose up -d
sudo docker compose ps

Ожидаемый результат: нужные контейнеры созданы и запущены. Это пока не доказательство исправности приложения. Далее необходима проверка health endpoint, зависимостей, логов и данных.

Источник: Docker Compose CLI.

Шаг 6. Восстановить БД в контролируемой среде

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

Для PostgreSQL архив пользовательского формата pg_dump -Fc можно сначала просмотреть, не изменяя базу:

pg_restore --list /secure-backups/database.dump

Этот пример применим именно к поддерживаемым архивным форматам pg_restore, а не ко всем файлам .sql или снимкам диска. Просмотр списка объектов не гарантирует успешного восстановления: затем требуется тестовая БД, сверка схемы, записей, ограничений, прав и ожидаемого состояния приложения.

Для MySQL, ClickHouse и других хранилищ используйте их штатные механизмы восстановления. Нельзя подменять процедуру восстановления БД копированием случайных файлов каталога данных.

Источник: PostgreSQL: pg_restore.

Шаг 7. Настроить публикацию, домен и HTTPS

До изменения DNS проверьте, что приложение отвечает локально, reverse proxy направляет запросы по правильному маршруту, нужные порты разрешены, а HTTP- и HTTPS-проверки согласованы с политикой безопасности.

Если приложение публикуется через NGINX, сперва проверьте синтаксис уже подготовленной конфигурации:

sudo nginx -t
sudo systemctl status nginx --no-pager

Для выпуска сертификата через Certbot доменное имя должно указывать на нужный сервер; выбранный способ HTTP- или DNS-подтверждения требует выполнения соответствующих условий. Перед запуском Certbot изучите инструкцию под вашу ОС и конфигурацию веб-сервера.

После настройки домена и сертификата:

curl --fail --silent --show-error --head https://example.com/

Адрес example.com следует заменить своим доменом. Код HTTP 200 не обязателен для всех приложений, но ответ должен соответствовать ожидаемому контракту. curl -I обращается методом HEAD, который также не все приложения поддерживают; для них используйте штатный health endpoint с GET.

Источник: Certbot: инструкции для NGINX.

Шаг 8. Настроить резервные копии и проверить восстановление

Без проверяемого восстановления резервное копирование остается предположением. Укажите источник данных, частоту копирования, срок хранения, шифрование, владельца процедуры и место хранения вне единственного сервера, отказ которого нужно пережить.

Минимальная проверка:

• Создать копию штатным механизмом приложения или СУБД.
• Убедиться, что файл или объект создан, читается и имеет ожидаемый формат.
• Восстановить копию в отдельной среде.
• Проверить ключевые таблицы, связи, пользовательские файлы и корректность запуска.
• Зафиксировать фактически достигнутые RPO и время восстановления.

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

7. Особые случаи: Kubernetes, ClickHouse и GPU

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

Kubernetes: проверять не только Deployments

Прежде чем переносить приложения, зафиксируйте версию Kubernetes, API и манифесты, ingress-контроллеры, storage classes, PersistentVolumeClaims, секреты, сетевые политики, внешние балансировщики и зависимости от облачных контроллеров.

Если у вас есть авторизованный доступ к исходному кластеру, несколько команд чтения помогут оценить состояние:

kubectl version
kubectl get nodes -o wide
kubectl get pods -A
kubectl get pvc -A
kubectl get storageclass

Ожидаемый результат: видны версии клиента/сервера (при доступности API), узлы, поды и требования к постоянному хранению. При недоступном API команды не заменяют резервную копию кластерного состояния. Не экспортируйте секреты в открытые файлы или логи.

В новой локации необходимо заново проверить сетевую связность, DNS, ingress, постоянные тома, права сервисных аккаунтов и recovery-процедуры stateful-компонентов. Простое применение старых YAML-файлов не переносит содержимое хранилищ.

Источник: Kubernetes: kubectl.

ClickHouse: сначала топология и согласованность

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

Пример диагностического запроса для авторизованного подключения:

SELECT database, table, engine
FROM system.tables
WHERE database NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema')
ORDER BY database, table;

Запрос показывает структуру таблиц, но не подтверждает состояние репликации или целостность данных. Для реплицируемых таблиц отдельно исследуют системные представления и применяют документированную для конкретной версии процедуру backup/restore. Команды изменения топологии или переключения реплик универсальными быть не могут.

Источник: ClickHouse: системные таблицы.

GPU/ML: сначала совместимость, потом перенос моделей

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

На сервере NVIDIA с установленными драйверами диагностику можно начать так:

nvidia-smi

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

Источник: NVIDIA: nvidia-smi.

8. Приемка и переключение production

Переключение пользователей должно происходить по согласованному критерию готовности, а не по одному успешному HTTP-запросу.

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

Порядок: завершить тесты → зафиксировать состояние данных → согласовать момент переключения → изменить маршрутизацию → проверить реальные пользовательские операции → наблюдать за метриками → объявить завершение после согласованного периода контроля.

9. Частые ошибки и условия эскалации

Когда нужно прекратить самостоятельную миграцию

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

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

10. Итоговый чек-лист переноса серверной инфраструктуры

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

11. Когда стоит привлечь инфраструктурную команду

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

Особенно это относится к Kubernetes и ClickHouse, миграции больших баз данных, GPU-кластерам, работе с единственным экземпляром критичных данных и системам, где ошибка переключения может повлиять на финансовые операции.

ИНДЕВИУМ помогает оценивать инфраструктурные требования, подбирать серверные мощности, организовывать миграцию и развертывание проектов. Подробнее о подходах и вариантах сотрудничества - в разделе миграции и развертывания серверной инфраструктуры.

Основные нормативные и технические источники: Закон № 152-ФЗ, закон № 38-ФЗ о рекламе, Ubuntu Server, Docker Docs, PostgreSQL Documentation, Kubernetes Documentation, ClickHouse Documentation, NVIDIA Documentation. Ссылки на документацию провайдеров приведены непосредственно в сравнительной таблице.