Как перенести VPS на новый хостинг без простоя

Большинство миграций проваливаются не во время копирования. Они проваливаются в те двадцать минут после смены DNS, когда половина интернета всё ещё обращается к старому серверу, а другая половина уже перешла на новый — и обе машины принимают запись. Файлы пришли целиком, сайт открывается, а заказы тем временем оседают в двух базах данных, которые никогда не удастся свести воедино. Избежать этого — почти не вопрос скорости передачи, а почти целиком вопрос последовательности: что вы меняете первым, что замораживаете и что продолжаете держать включённым, пока не убедитесь наверняка.

Что на самом деле означает «без простоя»

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

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

Проведите инвентаризацию, прежде чем копировать

На сервере накапливаются вещи, которые никто не задокументировал: cron-задача, добавленная во время инцидента, правило файрвола для адреса партнёра, API-ключ, вставленный в файл сервиса. Копия их не унесёт с собой, и вы будете находить их по одному в течение следующих двух недель. Полчаса инвентаризации сейчас снимают почти всю эту проблему.

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

Выбирайте точку назначения по тому, что нельзя изменить потом

Характеристики можно подстроить позже; несколько свойств — нельзя, и именно их стоит решать осознанно, пока у вас ещё есть свободный выбор. Раз уж вы всё равно переезжаете, это самый дешёвый момент, чтобы избавиться от ограничения, с которым вы до сих пор мирились в обход.

• Локация — ею фиксируются и задержка до ваших пользователей, и применимое законодательство. /locations перечисляет регионы и их характеристики round-trip; выбирайте тот, что откажет независимо от того, который вы покидаете.
• Юридическая почва — если причина переезда в том, что нынешний провайдер пересылает жалобы быстрее, чем пакеты. /offshore-hosting разбирает, что юрисдикция реально контролирует, а что нет.
• Платёжная идентичность — хостинг, который требует документы прежде, чем принять оплату, по своей конструкции уже заводит на вас досье. /no-kyc-vps и /pay-with описывают альтернативу — баланс, пополняемый криптовалютой, без карты и без имени, привязанного к машине.
• Запас — потому что мигрировать дважды не планирует никто. /vps перечисляет тарифы, а на /guides есть методика подбора размера, если текущую машину так толком никогда и не измеряли.
• IPv6 и чистый IPv4 — переработанный адрес может прийти с чужой репутацией на борту, проверьте это прежде, чем оно станет проблемой почты.

Снизьте TTL DNS заранее, за несколько дней

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

1. 1

   Узнайте текущий TTL

   dig +noall +answer yourdomain.com показывает оставшееся время кеширования; запрос напрямую к вашему авторитетному DNS-серверу через dig @ns1.example.net yourdomain.com показывает настроенное значение. Запишите его — оно задаёт длину периода ожидания.

2. 2

   Снизьте его до 300 секунд

   Снизьте TTL для каждой записи, которая изменится: A, AAAA и любых MX или CNAME, указывающих на хост. Пять минут — достаточно мало, чтобы переключение прошло комфортно, и достаточно много, чтобы не заваливать запросами ваши DNS-серверы.

3. 3

   Переждите старый TTL, а затем подождите ещё раз

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

Соберите новый сервер заново, а не клонируйте старый

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

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

• Разверните, обновите и защитите машину прежде, чем к ней прикоснётся что-либо ещё: SSH только по ключам, файрвол с политикой «запретить по умолчанию», автоматические обновления безопасности. На /guides есть часовая версия этого чек-листа.
• Устанавливайте те же основные версии среды выполнения и базы данных, что и в продакшене. Миграция — неудачный момент, чтобы заодно обновить PostgreSQL с 14 до 17, — вносите одно изменение за раз, чтобы у любого сбоя было ровно одно объяснение.
• Пересоздайте пользователей и группы с теми же числовыми ID до копирования файлов — либо потом вручную исправьте владельца. Передача с --numeric-ids сохраняет номера в неприкосновенности; сопоставить их с правильными именами — уже ваша задача.
• Добавьте новый адрес в каждый белый список, где сейчас указан старый, — API партнёров, файрволы управляемых баз данных, платёжные шлюзы, ваш собственный мониторинг, — пока оба адреса ещё действительны.

Копируйте файлы в два прохода

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

Запускайте первый проход когда угодно — можно и за несколько дней. Он переносит основной объём: каталог загрузок, почтовую очередь, тома контейнеров, годы накопленных медиафайлов. К моменту переключения он устареет, и именно для этого нужен второй проход.

• Используйте rsync -aAXH --numeric-ids --info=progress2 через SSH: -a для обычных атрибутов, -A для ACL, -X для расширенных атрибутов, -H для жёстких ссылок — это важно, если что-то на машине занимается дедупликацией.
• Исключите то, что не должно переноситься: /proc, /sys, /dev, /run, временные каталоги, кеш пакетов и логи, которые вам не нужны. Копирование интерфейсов ядра в лучшем случае тратит время впустую, а в худшем — подвешивает передачу.
• Добавляйте --delete только во втором проходе. В первом он безобиден; во втором он удаляет файлы, которые с тех пор были удалены на источнике, — а это как раз тот дрейф, который вы пытаетесь устранить.
• Копируйте системную конфигурацию выборочно, а не целиком. Вам нужны vhost-ы веб-сервера, юниты сервисов и конфигурация приложения — а не таблица файловых систем старой машины, её сетевые настройки или machine ID.
• Сгенерируйте одноразовый SSH-ключ для передачи, авторизуйте его на точке назначения и удалите, когда миграция завершена. Ключ миграции, который провисит ещё два года, — это учётные данные, о выдаче которых никто уже не вспомнит.

Между проходами проверяйте, а не полагайтесь на удачу. Запуск второго прохода с --dry-run выводит именно то, что он собирается изменить: список из нескольких сотен недавних файлов — это нормально, а список из сорока тысяч означает, что исключение настроено неверно или что-то без причины переписывает временные метки.

Перенесите базу данных, не потеряв ни одной записи

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

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

Выпустите TLS-сертификат до переключения, а не после

Сертификат на новом сервере обязан быть действительным уже в момент прихода первого пользователя. Обнаружить обратное означает, что каждый посетитель упрётся в предупреждение браузера, а если вы отправляете заголовки HSTS — а отправлять их стоит, — обойти его он не сможет. Есть два способа заранее получить рабочий сертификат, пока DNS ещё никуда не переключён.

• Скопируйте существующий. Целиком каталог состояния ACME — либо просто сертификат и ключ оттуда, где их хранит ваш клиент. Он действителен немедленно, потому что действительность никак не связана с тем, какой сервер хранит файл, а продление возобновится в обычном режиме, как только переключится DNS.
• Выпустите новый через проверку DNS-01, которая подтверждает контроль над доменом через TXT-запись, а не через HTTP-запрос к текущему адресу. Это работает и до миграции, и до переключения, и для wildcard-сертификатов, с которыми HTTP-01 не справляется вовсе.
• Не пытайтесь пройти проверку HTTP-01 на новом сервере до переключения. Запрос challenge приходит на порт 80 по имени домена, а домен всё ещё резолвится в старую машину, поэтому проверка каждый раз будет проваливаться.

Проверьте это, не трогая DNS, — зарезолвив имя хоста на новый адрес для одной-единственной команды: curl -sI --resolve yourdomain.com:443:198.51.100.10 https://yourdomain.com/, подставив реальный адрес. Эта одна строка — самая ценная проверка во всей миграции. Она задействует настоящий vhost, настоящий сертификат и настоящий стек приложения на новой машине — и именно так вы находите неправильную настройку, пока найти её ещё ничего не стоит.

Если сервер отправляет почту, начинайте раньше

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

• Проверьте новый адрес по основным чёрным спискам, прежде чем окончательно на нём остановиться. Переработанный IP с историей стоит поменять, пока замена ещё бесплатна.
• Настройте на новом адресе обратную DNS-запись на имя вашего почтового хоста. Принимающие серверы проверяют, что прямое и обратное преобразование совпадают, а одного лишь отсутствующего PTR достаточно, чтобы письмо занесли в спам.
• Добавьте новый адрес в SPF до переключения и уберите старый уже после — на время перекрытия должны быть указаны оба, чтобы почта проходила аутентификацию независимо от того, какой сервер её реально отправил.
• Скопируйте закрытые ключи DKIM вместо того, чтобы генерировать новые, — тогда селектор, уже опубликованный в DNS, продолжит проходить проверку. Генерация заново означает повторную публикацию, а у повторной публикации своя задержка распространения.
• Прогревайте новый адрес постепенно, если у вас есть сколько-нибудь заметный объём отправки. Сервер, который всё своё существование не отправил ни одного письма, а потом разом выдаёт десять тысяч сообщений, для принимающей стороны неотличим от скомпрометированного хоста.

Переключение

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

1. 1

   Заморозьте запись на старом сервере

   Режим техобслуживания, пользователь базы данных только для чтения или ошибка на путях записи на уровне обратного прокси. Чтение всё это время по-прежнему обслуживает старая машина — именно это держит сайт на плаву, пока переносятся данные.

2. 2

   Отключите все таймеры на старом сервере

   Закомментируйте crontab-записи, остановите таймеры, остановите обработчики очередей. С этого момента старая машина не должна обрабатывать вообще ничего, иначе задачи выполнятся дважды: два счёта, два письма, две доставки webhook.

3. 3

   Выполните финальную дельту

   Второй проход по файлам с --delete, затем финальный дамп базы данных или довыполнение репликой отставания. Это короткий этап, максимум несколько минут, потому что основной объём уже перенёс первый проход.

4. 4

   Проверьте новый сервер по его настоящему имени хоста

   С помощью описанного выше трюка с --resolve прогоните страницу, которая читает из базы данных, вход в систему и один путь записи. Убедитесь, что количество строк совпадает с источником. Сделайте всё это до изменения DNS, пока откат всё ещё абсолютно ничего не стоит.

5. 5

   Переключите DNS и запустите сервисы

   Обновите записи A и AAAA на новый адрес, затем включите и запустите приложение и его таймеры на новом сервере. Трафик начнёт приходить уже в пределах одного TTL и будет продолжать смещаться в течение следующего часа.

6. 6

   Оставьте старый сервер обслуживать чтение

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

Первые 48 часов

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

• Наблюдайте за access-логом старого сервера. Каждый запрос, который туда всё ещё приходит, — это немигрировавшая зависимость: зашитый адрес в интеграции с партнёром, мобильный клиент с устаревшим кешем, проверка мониторинга, у которой нет хозяина. Этот лог и есть список дел.
• Убедитесь, что таймеры на новом хосте реально сработали. Не что они включены — а что они выполнились, в ожидаемое время и с ожидаемым результатом. cron-задача, которая тихо ничего не делает, выглядит в точности как задача, которая работает.
• Проверьте продление сертификата по-настоящему, тестовым прогоном, а не узнавайте через шестьдесят дней, что ваш ACME-клиент всё это время пытался продлить его через сервер, который больше не получает challenge.
• Проверьте прохождение почты целиком в обоих направлениях, включая всё, что приложение отправляет автоматически. Сброс пароля — классическая жертва, потому что его никто не тестирует, пока он не понадобится реальному пользователю.
• Снимите резервную копию нового сервера и восстановите её куда-нибудь. Новая машина без проверенной резервной копии — положение хуже того, из которого вы уехали; на /guides есть развёрнутая версия этого довода.
• Верните TTL DNS к обычному значению, как только убедитесь, что всё в порядке. Оставить его на 300 секундах навсегда — это небольшие, но постоянные издержки на количество запросов и задержку без какой-либо оставшейся выгоды.

Вывод старого сервера из эксплуатации

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

• Прежде чем что-либо трогать, дождитесь, пока access-лог старого сервера не затихнет. Отмена услуги, пока платёжный провайдер ещё шлёт webhook на старый адрес, — вот как миграция неделей позже превращается в инцидент.
• Не просто удаляйте, а ротируйте: каждую учётную запись, которая была на старом сервере, — API-ключи, пароли баз данных, ключи развёртывания, временный ключ миграции. Считайте скомпрометированным всё, что жило на машине, которая вам больше не подконтрольна, — рано или поздно так оно и есть.
• Перезапишите данные перед тем, как освободить том. Уничтожьте чувствительные каталоги (shred), либо заполните свободное место одним большим файлом со случайными данными и удалите его. На виртуализированном диске это несовершенно, но куда лучше, чем ничего.
• Сделайте финальный архив всего, что может пригодиться для справки, — логи, конфигурацию, историю команд оболочки, которая документирует, что на самом деле было сделано, — и храните его в зашифрованном виде там, где нет ни одного из двух серверов.
• Отменяйте услугу только после того, как новый сервер пережил полный платёжный цикл и полную проверку резервного копирования и восстановления. Этот месяц перекрытия — самая дешёвая страховка во всём процессе.

Таймлайн, который можно скопировать

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

Как миграции на самом деле идут не так

Не через копирование. Через то, чего никогда не было на диске, и через то, что выполнилось дважды.

• Оба сервера пишут одновременно — окно split-brain, единственный здесь сбой без чистого решения. Предотвращается не инструментами, а порядком действий: сначала остановить старый, потом запустить новый.
• Таймеры работают на обеих машинах — вот как клиенты получают всё в двух экземплярах. Отключайте старые до финальной синхронизации, а не после.
• TTL, который так и не снизили, — превращает пятиминутное переключение в суточный хвост, на который никто не планировал выделять людей.
• Владелец файлов оказывается неверным, потому что числовые ID различаются между машинами, — приложение запускается, а затем не может писать в собственный каталог загрузок.
• Сертификат, который собирались уладить уже после переключения, сталкивается с заголовком HSTS, который не оставляет посетителям способа пройти дальше.
• Адрес, зашитый где-то вне вашего контроля, — интеграция с партнёром, правило файрвола, DNS-запись для поддомена, о существовании которого вы уже забыли.
• Отмена старого сервера в день переезда — это устранение пути отката ровно в тот момент, когда, по статистике, он нужнее всего.