Перенос на офшорный хостинг без простоя

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

У обоих рисков одно и то же лекарство, и это не инструмент. Это порядок действий. Миграция, выполненная в правильной последовательности, не оставляет окна недоступности сайта, потому что оба сервера какое-то время работают одновременно, а DNS переключается последним. Миграция, выполненная в неправильном порядке, одновременно даёт и простой, и след. Дальше — эта последовательность, описанная для тех, кто переезжает на офшорный хостинг без KYC, а не просто перекладывает сайт между двумя обычными провайдерами: механика та же, а вот зачистка после переезда — нет.

Что на самом деле означает «нулевой простой»

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

Обратите внимание: по-настоящему бесплатна только первая строка. Везде дальше «нулевой простой» означает «заморозка записи настолько короткая, что на неё никто не заводит тикет». Две минуты режима только для чтения в 04:00 — это статистическая погрешность; два часа раздвоенной записи в две базы — это выходные, потраченные на сверку. Выбирайте заморозку.

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

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

Важная деталь: само снижение TTL подчиняется старому TTL. Резолверы узнают о новом, более коротком значении только тогда, когда истечёт срок жизни старой закэшированной копии. Поэтому снижайте TTL до 300 секунд минимум за один полный период старого TTL до переключения — при суточном TTL это значит сделать это за 24–48 часов. Тогда весь интернет сходится на новой записи в течение пяти минут после изменения, и переключение перестаёт быть событием с интригой.

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

Составьте опись того, что переносите, а не того, что помните

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

• Запланированные задачи. crontab -l для каждого пользователя, плюс таймеры systemd. Здесь прячутся хуки продления сертификатов и ночные задания.
• Определения сервисов. Собственные юниты systemd, vhosts веб-сервера, пулы PHP-FPM, любой конфиг supervisor.
• Секреты и окружение. Файлы .env, API-ключи, пароли базы данных, соли приложения — и учтите, что их нужно не просто скопировать, а сменить.
• Материалы TLS. Сертификаты и, что важнее, аккаунт ACME и конфигурация продления.
• Почтовая идентичность. Приватные ключи DKIM, записи SPF и DMARC. Несовпадение здесь не ломается громко — оно просто тихо отправляет вашу почту в спам.
• Загруженные медиафайлы. Часто лежат вне корня сайта, часто оказываются самым тяжёлым, что у вас есть.
• Всё внешнее, что доверяет вашему IP. Белые списки платёжного шлюза, адреса для вебхуков, файрволы баз данных, сторонние API с ограничением по IP. Это причина номер один ситуации «сайт работает, а оформление заказа сломано» в три часа ночи.
• Список пакетов. dpkg --get-selections или его аналог — чтобы на новой машине были те же расширения и библиотеки, а не почти те же.

Запишите список до того, как начнёте копировать. Позже эта опись станет вашим планом тестирования — каждая её строка — это то, что нужно проверить на новом сервере, прежде чем о нём узнает DNS.

Сначала соберите новый сервер и защитите его прежде, чем он станет что-то хранить

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

Осознанно повторите старое окружение: тот же дистрибутив и та же мажорная версия, та же мажорная версия PHP, Node или Python, та же мажорная версия базы данных. Соблазн заодно всё модернизировать огромен, и ему нужно полностью сопротивляться. Если сайт сломается после переключения, вы хотите, чтобы изменилась ровно одна переменная. Обновляйте стек через пару недель, в скучный будний день, с возможностью откатиться.

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

Копируйте данные дважды: сначала медленный проход, потом быстрый

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

Для файлов rsync -aHAX --numeric-ids сохраняет права, владельца, жёсткие ссылки и расширенные атрибуты; флаг --numeric-ids важен, потому что UID редко совпадают между двумя свежесобранными машинами. Запустите его один раз заранее, затем ещё раз непосредственно перед переключением с теми же аргументами — второй запуск перенесёт только дельту.

Базы данных требуют той же двухфазной обработки, но других инструментов. mysqldump --single-transaction или pg_dump дают согласованный ранний снимок, на котором можно собирать и тестировать систему. При переключении либо снимите второй дамп во время короткой заморозки записи, либо — для крупной базы, где даже короткая заморозка ощутима, — заранее, за несколько дней, разверните новый сервер как реплику старого, дайте ей догнать мастер и затем повысьте её. Репликация сокращает заморозку до секунд. Она же превращает двухчасовую миграцию в двухдневный проект, поэтому используйте её только тогда, когда размер базы этого действительно требует.

Протестируйте новый сервер прежде, чем о нём узнает DNS

Вы можете отдавать реальное имя хоста с нового IP, не меняя ни одной публичной записи, — и вам стоит это сделать: именно это делает переключение скучным и бессобытийным. Добавьте строку в локальный /etc/hosts, направив домен на новый IP, либо пропустите этот шаг и поручите то же самое curl для одного запроса:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Теперь пройдитесь по описи. Загрузите главную страницу и три страницы поглубже. Войдите в аккаунт. Отправьте форму. Загрузите файл. Проверьте, что подключение к базе данных смотрит на новую, локальную, а не всё ещё на старый хост через интернет — ошибка, которая прекрасно работает ровно до того момента, как вы отмените старый сервер. Запустите cron-задачи вручную и прочитайте их вывод. Проверьте редиректы и то, что отсутствующий URL по-прежнему возвращает 404, а не 200.

Выпустите TLS-сертификат сейчас, до переключения, а не после. Используйте проверку DNS-01: она подтверждает владение доменом через TXT-запись и потому работает, пока запись A всё ещё указывает на старый сервер. Если дождаться проверки HTTP-01 после смены DNS, каждый ранний посетитель в этот промежуток получит предупреждение о сертификате — самостоятельно устроенный простой ровно в том окне, которое вы и пытались защитить.

Переключение по шагам

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

1. Если от сайта зависит кто-то ещё, объявите об окне обслуживания, затем переведите старый сайт в режим только для чтения или обслуживания.
2. Отключите cron и фоновые обработчики на старом хосте. Сделайте это до запуска их на новом, а не после.
3. Выполните финальный проход дельты rsync и финальный дамп базы данных, затем импортируйте его.
4. Запустите приложение на новом сервере и заново прогоните дымовые тесты через --resolve, уже на финальных данных.
5. Смените записи A и AAAA на новый IP. При TTL в 300 секунд весь интернет подтянется в течение пяти минут.
6. Включите cron и обработчики на новом хосте.
7. Смотрите на оба лога доступа бок о бок. Трафик стекает со старого сервера и появляется на новом; когда старый затихает, переключение завершено.
8. Оставьте старый сервер работающим, обслуживающим запросы и нетронутым на неделю. Это ваш путь отката.

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

Что миграция оставляет после себя

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

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

Вопрос домена: перенести или начать с чистого листа?

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

• Оставить домен, сменить регистратора. Разумно, когда у домена есть ценность — ссылки, позиции в выдаче, имя, которое люди набирают руками. Это фиксирует будущее записи WHOIS, но не её историю, и сохраняет в целости все сигналы ранжирования. Для большинства коммерческих сайтов это правильный ответ.
• Оставить домен, не менять вообще ничего, кроме хостинга. Вполне разумно, если вы переезжали ради юрисдикции, аптайма или позиции по DMCA, а не ради анонимности. Простейший из возможных ходов, нулевой риск для SEO.
• Новый домен с редиректом со старого. Сохраняет позиции в выдаче и публично, навсегда связывает два имени. Выбирайте этот вариант ради преемственности, но никогда ради приватности — редирект и есть та самая связь.
• Новый домен, чистый разрыв. Единственный вариант, реально разрывающий связь, и он стоит вам всех позиций в выдаче и всех входящих ссылок, что у вас были. Регистрируйте его приватно с самого начала, потому что домен анонимен ровно настолько, насколько анонимна была его первая регистрация. Наш гайд по анонимной регистрации домена за криптовалюту подробно разбирает, как сделать это правильно.

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

Правильно выводите старый хост из эксплуатации

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

1. Убедитесь, что ничто больше не указывает на старый IP: проверьте жёстко прописанные адреса в сторонних вебхуках, белых списках, мониторинге, и любую забытую DNS-запись вроде случайно оставшегося поддомена mail или cpanel.
2. Смените все секреты, когда-либо жившие на этой машине, — пароли баз данных, API-ключи, соли приложения, ключи DKIM, ключи SSH. Не переносите их на новый сервер.
3. Удалите свои публичные ключи SSH и любой доступ поддержки со старого сервера.
4. Удалите приложение, дампы и бэкапы, затем перезапишите свободное место, чтобы беглое чтение переработанного тома не дало ничего.
5. Только после этого отключайте услугу и удаляйте из старого аккаунта любой сохранённый способ оплаты.

Вся последовательность на одной странице

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

1. За два дня: снизьте DNS TTL до 300 секунд.
2. За два дня: закажите и защитите сервер назначения, версия в версию повторяя старый стек.
3. За несколько дней: составьте опись — cron, секреты, TLS, почтовые ключи, медиа, белые списки IP, пакеты.
4. За несколько дней: выполните первую полную копию данных, напрямую между хостами.
5. До окна: выпустите сертификат через DNS-01 и проверьте всё через --resolve.
6. Окно (минуты): заморозьте запись, отключите старый cron, выполните дельта-копирование и финальный дамп, запустите новое приложение.
7. Окно (секунды): смените запись A, затем включите cron на новом хосте.
8. Следующая неделя: держите старый сервер живым как путь отката, следите за обоими логами, затем снова поднимите TTL.
9. После этого: смените секреты, зачистите диск, отмените услугу — и помните о том, чего переезд стереть не мог.

В этом списке нет ничего сложного. Каждый болезненный шаг — это шаг, сделанный не по порядку: TTL, сниженный в ночь переключения, сертификат, выпущенный после смены DNS, cron-задача, оставленная активной на машине, которая больше не авторитетна. Выстройте порядок правильно — и самой интересной частью миграции станет выбор, куда поставить сервер, а не сам переезд. Если вы ещё не определились с этим, начните с гайда по юрисдикциям.