Ушли с шареда и всё сломалось: семь вещей, которые забывают перенести

MAATRIX

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

Cron-задачи, настроенные через панель, а не через код

На шаред-хостинге расписание задач почти никогда не хранится в проекте. Вы заходите в cPanel, ISPmanager или похожую панель, открываете раздел «Cron Jobs», вписываете команду и время — и всё, задача работает. В git это не попадает, в README не упоминается, и через полгода о ней помнит разве что человек, который её создавал (а если это подрядчик, который давно не работает над проектом — не помнит уже никто).

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

crontab -l

Если shell-доступа нет, единственный источник — раздел Cron Jobs в веб-интерфейсе панели: открывайте его и построчно копируйте команды, расписание и от чьего пользователя они выполняются (на шареде это обычно пользователь вашего аккаунта, но иногда бывает несколько логинов на один сайт).

Отдельная ловушка — задачи, зашитые в саму CMS через её собственный планировщик (WP-Cron в WordPress, встроенные задачи Bitrix), которые панель хостинга запускала настоящим системным cron вместо запроса при заходе посетителя. На VPS их нужно явно перевести на системный cron с отключением псевдо-крона внутри приложения — иначе задачи либо не будут запускаться вовремя, либо будут запускаться дважды, если вы забыли выключить старый механизм.

На новом сервере задачи прописываются в crontab -e целевого пользователя (не root, если приложение не должно работать от root) или отдельным файлом в /etc/cron.d/. Второй вариант удобнее для инвентаризации — файл лежит в системе, его видно при простом ls, и его можно положить под версионный контроль вместе с остальной конфигурацией сервера.

SSL-сертификаты, которые панель выпускала и продлевала сама

На большинстве современных шаред-тарифов SSL идёт «из коробки»: панель хостинга сама заказывает сертификат Let's Encrypt (или включённый в тариф платный), сама проходит проверку домена и сама продлевает его за несколько дней до истечения. Вы никогда не видели этот процесс — просто в браузере всегда был замок.

На VPS такой магии по умолчанию нет. Сертификат нужно заказать и настроить автопродление самостоятельно — обычно через certbot или acme.sh, привязанные к вашему веб-серверу:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Частая причина простоя в первые дни — не «забыли настроить certbot», а забыли, что домен ещё указывает на старый сервер в момент, когда на новом уже пытаются пройти HTTP-01 challenge: проверка не проходит, сертификат не выпускается. Правильный порядок: снизить TTL DNS-записи заранее, переключить DNS, дождаться, пока запросы реально пойдут на новый IP, и только после этого запускать certbot. Подробности выпуска сертификата — в статье о настройке Let's Encrypt на VPS.

Если сайтов на сервере несколько и у каждого свой сертификат (мультидоменный shared-тариф часто выпускал SSL сразу на все поддомены через SAN-сертификат или wildcard), выпишите полный список доменов и поддоменов из панели заранее — легко забыть тестовый поддомен dev.example.com или почтовый webmail.example.com, который тоже был защищён общим сертификатом хостинга.

Почта: SPF, DKIM, DMARC и ящики на домене

Если почта домена жила на хостинге (mail.example.com, встроенные почтовые ящики панели), это одно из самых болезненных мест переезда — и одно из самых незаметных, пока не начнут отваливаться письма. Панель хостинга обычно сама прописывала SPF-запись, включающую её почтовые серверы, сама генерировала ключ DKIM и подключала его, а DMARC либо тоже настраивала, либо оставляла минимальным.

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

Минимальный чек перед переездом:

• Выписать текущие SPF, DKIM и DMARC записи (dig TXT example.com, dig TXT default._domainkey.example.com — селектор DKIM смотрите в панели, у разных хостингов он называется по-разному).
• Понять, куда реально переезжает почта: остаётся на старом хостинге, переезжает на новый сервер или уходит на внешний сервис.
• Если почта переезжает — новый SPF должен включать новые IP или инфраструктуру отправки, DKIM — новый ключ, привязанный к новому серверу.
• Не включать DMARC в режим p=reject сразу после переезда, пока не убедились, что все легитимные каналы отправки (включая CRM, рассылки, транзакционные письма) проходят проверку — слишком строгая политика сразу после переезда рискует отрезать часть легитимной почты.

Подробно про сам процесс настройки записей — в статье про SPF, DKIM и DMARC на VPS. Если решаете перенести почту на собственный сервер, а не просто продублировать настройки — заложите на это отдельное время: это самостоятельная миграция со своими рисками потери писем, а не строчка в общем плане переезда сайта.

Файлы вне основной директории проекта

Стандартный сценарий деплоя — вытянуть код из git, накатить его на новый сервер. Проблема в том, что далеко не все файлы сайта лежат в git. Загруженные пользователями изображения, PDF-счета, аватарки, файлы из CMS-медиатеки — на многих проектах они физически хранятся в отдельной директории (/wp-content/uploads, /storage/app/public, кастомная папка вроде /files или /data), которая в .gitignore и никогда не была частью репозитория.

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

Что стоит сделать перед переездом:

1. Пройтись по конфигурации приложения и найти все пути, куда пишутся загруженные файлы (переменные вроде UPLOAD_DIR, MEDIA_ROOT, настройки CMS).
2. Отдельно проверить, не настроено ли у CMS хранение медиа во внешнем облаке (S3-совместимое хранилище) — тогда файлы переносить не нужно, но нужно перенести доступы к этому хранилищу (см. следующий пункт про секреты).
3. Перенести эти директории явно, отдельной командой rsync, а не полагаться на то, что они «приедут вместе с кодом»:

rsync -avz --progress user@old-host:/home/user/public_html/wp-content/uploads/ /var/www/example.com/wp-content/uploads/

1. Сверить размер директории на старом и новом сервере (du -sh) — это простая, но надёжная проверка, что перенеслось действительно всё, а не только видимая часть.

На шаред-хостинге к тому же нередко теряются права доступа и расширенные атрибуты файлов при переносе через FTP или веб-файловый менеджер — после переноса стоит явно сверить права на директорию загрузок (ls -la), а не полагаться на то, что FTP-клиент перенёс их корректно.

Переменные окружения и секреты, настроенные через панель

Многие панели хостинга дают удобный интерфейс для переменных окружения приложения — вписал ключ API, пароль от почтового сервиса, токен платёжной системы в отдельном разделе, и панель сама подставляет их в PHP через getenv(), никак не касаясь кода. Это удобно ровно до момента переезда: эти значения не лежат ни в git, ни в конфиге проекта — они существуют только в базе данных панели управления, и с закрытием аккаунта на старом хостинге пропадут безвозвратно.

Перед переездом нужно явно выгрузить все такие переменные — не пересказом по памяти, а построчной сверкой раздела «Environment Variables» или «PHP Variables» в панели. На новом сервере они переносятся в .env-файл проекта или в системный сервис — например, через EnvironmentFile в unit-файле systemd:

# /etc/systemd/system/example-app.service
[Service]
EnvironmentFile=/etc/example-app/app.env

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

DNS-записи, которые панель создавала автоматически

Панели хостинга часто заводят DNS-записи сами, без явного действия владельца сайта: поддомен webmail. для веб-интерфейса почты, autoconfig./autodiscover. для настройки почтовых клиентов, MX-записи под встроенный почтовый сервис, иногда служебные записи для встроенного антиспама или CDN тарифа. Всё это добавлялось в момент подключения соответствующей функции, без отдельного уведомления «мы создали DNS-запись» — просто заработало и работает.

Если DNS-зона домена управляется через ту же панель хостинга (а не через отдельный DNS-провайдер или регистратора), при переезде на VPS с самостоятельным управлением DNS все эти записи нужно перенести вручную — панель их с собой не заберёт, потому что переезжает сайт, а не DNS-хостинг. Практический способ ничего не упустить — выгрузить зону целиком, если панель это позволяет (Export Zone File в разделе DNS), либо построчно пройтись по каждой записи через dig:

dig example.com ANY +noall +answer
dig webmail.example.com A
dig autoconfig.example.com CNAME

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

Редиректы и правила, специфичные для среды shared-хостинга

На шаред-хостинге веб-сервер почти всегда Apache, и вся логика — редиректы с http на https, склейка www/без www, запрет доступа к каталогам, кастомные страницы ошибок, защита паролем через .htpasswd — прописана в .htaccess. Этот файл легко не заметить: он скрытый (начинается с точки), не всегда попадает в бэкап через обычный файловый менеджер, и уж точно не будет автоматически понят nginx, если на VPS вы ставите именно его.

На nginx правил .htaccess не существует в принципе — весь функционал нужно переписать в блоки server и location. Например, типичный редирект с www на без-www в .htaccess:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

превращается в отдельный серверный блок nginx:

server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Если на VPS ставится Apache (например, ради совместимости с существующими .htaccess), правила можно перенести почти без изменений — но тогда стоит явно включить AllowOverride All в конфиге виртуального хоста, иначе .htaccess будет просто молча игнорироваться, и вы не сразу поймёте, почему редиректы не работают, хотя файл на месте.

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

Частые вопросы