Смените хостинг: сайт перенесём мы, бесплатно

Перенос в том порядке, в котором он делается

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

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

1. Д-7 — Составить перечень того, что действительно работает. Сайты и их домены, используемая версия PHP, базы и их движок, почтовые ящики и их объём, запланированные задания, сертификаты и даты их истечения, а также сторонние службы, которым известен ваш текущий IP-адрес (платёжный шлюз, SMTP-релей, webhook). Именно этот перечень, а не ваша память, станет итоговой проверкой.
2. Д-7 — Подобрать целевой тариф по реальной нагрузке, а не по тому, за что вы платите сегодня. Измерьте занятое место на диске, размер баз, фактически потребляемую память. Сайту, который укладывается в 6 ГБ, не нужен тариф на 200 ГБ только потому, что так было написано в старом.
3. Д-5 — Открыть новый хостинг и поднять копию. Файлы и базы переносятся первый раз целиком, при этом снаружи ничего не меняется. Эта копия не обязана быть свежей до секунды: она нужна, чтобы убедиться, что приложение запускается.
4. Д-3 — Заморозить изменения на старом сервере. Больше никаких публикаций, никаких обновлений расширений, никаких правок темы до переключения. Всё, что записано после этой точки, придётся синхронизировать вручную.
5. Д-2 — Снизить TTL у записей, которые будут меняться, до 300 секунд. Этот шаг делают минимум за 48 часов до переключения — причина объяснена в разделе о DNS ниже. Это шаг, который чаще всего делают слишком поздно, и единственный, который нельзя догнать.
6. Д-1 — Проверить копию под её настоящим доменным именем, не трогая публичный DNS: измените файл hosts на своём компьютере, чтобы домен указывал на новый IP-адрес. Тогда вы увидите ровно то, что увидят посетители, вместе с абсолютными ссылками и переадресациями.
7. Д-1 — Подготовить целевую зону DNS, не публикуя её. Выпишите точные значения записей A, AAAA, MX, SPF, DKIM, DMARC и CAA, которые собираетесь поставить. Записанные заранее, они избавляют от импровизации в день переключения, когда сайт уже наполовину переехал.
8. День Д — Синхронизировать разницу. Второй проход копирования переносит только то, что изменилось с Д-5, затем свежий дамп базы заменяет предыдущий. Именно этот короткий второй проход и определяет настоящее окно недоступности.
9. День Д — Опубликовать новые записи DNS. Когда TTL в 300 секунд выставлен двумя днями ранее, переключение вступает в силу для большинства посетителей за минуты, а не за двадцать четыре часа.
10. День Д — Пройти проверки в порядке, указанном ниже. Не отмечайте ничего по памяти: откройте список и действительно проверьте.
11. Д+1 — Вернуть TTL к обычному значению; 3600 секунд подходит в большинстве случаев. Постоянно короткий TTL без всякой пользы умножает запросы к вашим серверам имён.
12. Д+7 — Закрыть старый договор, не раньше. Дождитесь, пока на новые ящики придёт почта, пока вы восстановите резервную копию у нового хостинга и перечитаете журналы ошибок. Закрытие договора часто удаляет данные в тот же день.

Что переносится и каким способом

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

• Файлы. rsync по SSH, когда это позволяют обе стороны, иначе SFTP. Два прохода лучше одного: первый полный, пока сайт работает, второй прямо перед переключением — он забирает только различия. Затем проверьте, что права, владельцы и символические ссылки уцелели: неверно настроенный FTP сплющивает их без предупреждения.
• Базы данных. mysqldump --single-transaction --quick для MySQL и MariaDB, pg_dump -Fc для PostgreSQL. Запишите кодировку и правило сортировки исходной базы и создайте целевую базу с теми же: именно эта деталь превращает буквы с диакритикой в нечитаемые символы после импорта.
• Резервная копия панели. Если нынешний хостинг управляется панелью, её встроенный экспорт — файлы, базы, ящики и настройки в одном архиве — часто самый надёжный путь. Наши тарифы веб-хостинга поставляются с панелью Plesk, у которой есть собственные средства резервного копирования и восстановления.
• Образ диска, когда переезжает сервер целиком. На VPS или выделенном сервере есть два пути: скопировать диск как есть (образ raw или qcow2, либо побайтовая копия из системы восстановления) либо начать с чистой системы и развернуть приложение заново. Если нынешний хостинг не даёт доступа к образу диска, остаётся только второй путь — и для системы, которой несколько лет, мы всё равно советуем именно его.
• Сертификаты. Не переносите их: сертификат Let's Encrypt перевыпускается на новом сервере за считаные секунды, как только домен направлен. Если вы платите за сертификат с расширенной проверкой, выгрузите закрытый ключ до закрытия договора, иначе его придётся покупать снова.
• Почтовые ящики. Синхронизация по IMAP переносит письма, структуру папок и признак «прочитано / не прочитано» с одного сервера на другой. Проведите её дважды, как и с файлами: один раз до переключения, один раз после, чтобы забрать письма, пришедшие в промежутке.
• Запланированные задания и службы. Записи cron, таймеры systemd, очереди и постоянно работающие процессы не попадают ни в одну резервную копию сайта. Перенесите их вручную, а затем убедитесь, что после переключения они работают, а не просто объявлены.
• Секреты. Разрешённые ключи SSH, токены API, ключи шифрования приложения, учётные данные служб: они часто лежат вне папки сайта и теряются незаметно. Приложение, которое запускается, но больше не расшифровывает свои данные, — это почти всегда ключ, оставшийся на старом сервере.

DNS: что готовят заранее, что переключают в день Д

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

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

1. За 48 часов: снизить TTL до 300 секунд у всех записей, которые будете менять, — как минимум A и AAAA, плюс MX и связанные CNAME, если переезжает и почта. TTL задают в зоне DNS, у того, кто эту зону держит: в большинстве случаев — у вашего регистратора.
2. Снять текущую зону до того, как её трогать. Запрос dig вашдомен.ru ANY или экспорт зоны из интерфейса даёт исходное состояние. Сохраните его: это точка возврата, если что-то пойдёт не так.
3. A и AAAA. Запись A несёт IPv4-адрес нового хостинга, AAAA — его IPv6-адрес, если он есть. Не забудьте ни www, ни поддомены, которыми действительно пользуются: какой-нибудь webmail, api, тестовый стенд. Забывают обычно те, на которые сами никогда не заходят.
4. MX: запись, о которой забывают. Она указывает сервер, принимающий вашу почту, и не связана с тем, где стоит сайт. Если почта остаётся на месте, не трогайте её: это классическая ошибка переключения «заменим все IP в зоне», которая уводит почту на сервер, ничего о ней не знающий. Если почта переезжает, меняйте MX только после того, как ящики созданы и синхронизированы.
5. SPF. Это одна запись TXT, перечисляющая серверы, которым разрешено отправлять почту от вашего имени. Если она по-прежнему указывает на старый хостинг, письма с нового попадут в спам или будут отклонены. Добавьте новый сервер до переключения, уберите старый после подтверждения переноса — и держите только одну запись SPF: две взаимно нейтрализуются.
6. DKIM. Подпись создаёт отправляющий сервер, а проверяется она открытым ключом, опубликованным в вашей зоне под селектором. Опубликуйте селектор нового сервера до переключения и оставьте старый на несколько дней: два селектора сосуществуют, не мешая друг другу, в отличие от SPF.
7. DMARC. Он указывает получателям, что делать с письмами, не прошедшими предыдущие проверки. Во время переноса оставайтесь на p=none с адресом для отчётов: вы наблюдаете, ничего не ломая, и ужесточаете политику, когда SPF и DKIM в порядке с обеих сторон.
8. CAA, если она есть. Эта запись перечисляет центры, которым разрешено выпускать сертификат для вашего домена. Если в ней нет того, которым пользуется новый хостинг, выпуск молча не состоится, и сайт останется на недействительном HTTPS — без внятного сообщения об ошибке где-либо.
9. Обратный DNS (PTR). Он задаётся не в вашей зоне, а на IP-адресе, то есть у хостинга, который этим адресом владеет. Он важен, как только сервер сам отправляет почту: без PTR, совпадающего с объявленным именем, часть получателей отклонит письмо. У нас обратный DNS можно настроить по запросу.

Настоящая недоступность и как свести её почти к нулю

Того простоя, которого боятся большинство, — «мой сайт будет недоступен, пока расходятся записи DNS» — не существует, если оба хостинга отвечают одновременно. Пока записи расходятся, часть посетителей попадает на старый сервер, часть на новый, и оба показывают сайт. Ошибки не видит никто.

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

• Сайт-визитка или статический сайт: простоя нет вовсе. На стороне сервера ничего не записывается, копию можно снять днём раньше, и переключение не требует особых мер.
• Сайт с базой данных: несколько минут. Сайт переводят в режим только для чтения или обслуживания, выгружают базу, загружают её, переключают. На обычном сайте вся операция укладывается в пять — пятнадцать минут, её планируют на часы низкой нагрузки.
• Интернет-магазин: то же окно, но объявленное. Предупредите команду, выберите действительно спокойное время — часто раннее утро — и потом сверьте последние заказы с двух сторон, прежде чем считать старый сервер ненужным.
• Почта: простоя нет, но есть период наложения. Пока MX не разошёлся везде, письма продолжают приходить на старый сервер. Сохраните к нему доступ на несколько дней и повторите синхронизацию по IMAP после переключения: именно это спасает от потерянного письма.
• Приложение с очередью или отложенными задачами: сначала опустошите очередь. Задача, выполняемая в момент выгрузки, будет потеряна либо отработает дважды. Остановите обработчиков, дайте очереди опустеть, затем выгружайте.

После переключения: проверки по порядку

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

1. Разрешение DNS. Спросите публичный резолвер и резолвер своего провайдера: оба должны вернуть новый адрес. Пока это не так, то, что вы видите в браузере, ничего не доказывает.
2. Сайт отвечает, и с нужной машины. curl -I https://вашдомен.ru должен вернуть код 200; при сомнениях curl --resolve позволяет задать адрес принудительно и сравнить оба сервера рядом.
3. Сертификат. Действителен, на нужное имя и покрывает также www. На автоматический выпуск после расхождения записей уйдёт несколько минут; если прошёл час — идите смотреть запись CAA.
4. Переадресации. HTTP на HTTPS и www на домен без префикса или наоборот — но только в одну сторону, кодом 301, а не 302, и без цепочки из двух переадресаций подряд.
5. Глубокие страницы. Главная работает почти всегда. Откройте пять-шесть внутренних адресов, выбранных наугад: именно там видны потерянные правила перезаписи и абсолютные ссылки, оставшиеся на старом домене.
6. Формы. Отправьте тестовое сообщение через форму обратной связи и убедитесь, что оно пришло. Форма, которая пишет «спасибо», ничего не отправляя, — самый частый дефект после переноса.
7. Оплата, если она есть. Тестовый заказ в песочнице, вплоть до подтверждения и связанного с ним письма. Заодно проверьте, нет ли у шлюза списка разрешённых IP-адресов, который нужно обновить.
8. Исходящая почта. Отправьте письмо с сайта на внешний адрес, откройте заголовок полученного письма и прочитайте результаты SPF и DKIM. Нужен «pass» по обоим; если нет — вернитесь к разделу о DNS.
9. Входящая почта. Напишите извне на один из перенесённых адресов и продолжайте следить за старым ящиком несколько дней.
10. Запланированные задания. Дождитесь, пока одно из них отработает, и проверьте его след, а не только наличие строки в таблице заданий.
11. Журналы ошибок. Читайте их первые 48 часов. Отсутствующее расширение или жёстко прописанный абсолютный путь видны там сразу, обычно раньше, чем кто-либо пожалуется.
12. Первая резервная копия у нового хостинга. Снимите её, затем один раз восстановите, чтобы убедиться, что она пригодна. Это условие, которое нужно выполнить до закрытия старого договора.

Ловушки, которые стоят целого дня

• TTL, снижённый в тот же день. Это не даёт ничего: старое, длинное значение уже в кеше. Часть посетителей весь день остаётся на старом сервере, а вы ищете неисправность, которой нет.
• MX, заменённый по привычке. Замена «всех IP в зоне» уносит почту вместе с сайтом. Если ящики не переезжают, MX не меняется.
• SPF, оставленный на старом сервере. Сайт работает, письма уходят, и никто их не получает — или они падают в спам. Это самый трудный для последующей диагностики дефект, потому что внешне ничего не ломается.
• Старый договор, закрытый слишком рано. Закрытие удаляет данные, часто в тот же день, и уносит с ними письма, пришедшие после переключения, и единственную ещё свежую копию файлов.
• Сертификат, запрошенный до того, как DNS указал на новый сервер. Проверка не проходит, сайт открывается с предупреждением о безопасности, а браузер запоминает ошибку. Дождитесь расхождения записей, затем запросите выпуск.
• robots.txt тестового стенда, скопированный как есть. Строка Disallow: /, унаследованная от тестовой среды, выводит сайт из индекса за несколько дней. Перечитайте этот файл сразу после переключения.
• Версия PHP, изменившаяся без чьего-либо решения. Новый хостинг часто предлагает по умолчанию более свежую версию. Сначала воспроизведите исходную версию, обновляйтесь потом, когда перенос уже позади.
• Забытые кеш и CDN. Если перед сайтом стоит CDN, менять нужно не публичную запись A, а источник, объявленный внутри CDN. И очистите кеш после переключения, иначе вы продолжите отдавать старый сайт.
• Списки разрешённых IP-адресов у сторонних служб. Платёжный шлюз, SMTP-релей, API партнёра, удалённая база данных: всё, что фильтрует по IP-адресу, должно узнать новый до переключения, а не после.

Перенести сервер — это не перенести сайт

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

Перенести сервер — значит собрать машину заново: система, пакеты, службы, межсетевой экран, пользователи, сертификаты, резервные копии. На VPS KVM вы получаете выделенный адрес IPv4, доступ root по SSH и панель с перезагрузкой, переустановкой, снимками и консолью. Эта консоль важна в день переключения: именно она позволяет вернуть управление, если правило межсетевого экрана закрыло вам дверь SSH.

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

Позиции в поиске во время переноса

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

• Адреса, изменившиеся без переадресации. Если структура меняется одновременно с хостингом, подготовьте таблицу соответствий до переключения и отдавайте 301, а не 302. Держите их как минимум двенадцать месяцев.
• Случайный запрет индексирования. robots.txt, заголовок X-Robots-Tag, тег noindex, унаследованный от тестовой среды: проверьте все три в тот же день.
• Сайт, который стал медленнее. Кеш приложения и сжатие на новом хостинге часто нужно включить заново. Сравните время ответа до и после, а не предполагайте его.
• Сломанная карта сайта. Убедитесь, что она остаётся доступной и актуальной, а затем дайте поисковой системе вернуться самой. Темп обхода восстанавливается за несколько дней; форсировать нечего, если адреса не менялись.