Перенос сайтов с ISPmanager на FastPanel: пошаговая инструкция и подводные камни

Переносить сайты между серверами с одной и той же панелью — задача понятная: у панелей обычно есть свой инструмент миграции. А вот переезд с ISPmanager на FASTPANEL — это смена панели, и встроенного «нажал кнопку — всё переехало» тут нет. Приходится переносить руками.

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

Общая схема

1. Инвентаризация старого сервера: что вообще переносим.
2. Подготовка нового сервера: пользователи, версии PHP, сайты и базы в FastPanel.
3. Первичная копия файлов и баз.
4. Проверка сайтов через hosts, пока DNS ещё смотрит на старый сервер.
5. Финальная синхронизация и переключение DNS.
6. Почта, SSL, cron и уборка хвостов.

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

Шаг 0. Заранее понизьте TTL

За сутки-двое до переезда уменьшите TTL у A- и MX-записей доменов до 300 секунд. Тогда переключение DNS разойдётся за минуты, а не за часы. Если DNS на Cloudflare и проксирование включено — тем проще, IP origin меняется мгновенно.

Шаг 1. Инвентаризация на старом сервере

Прежде чем что-то копировать, нужно понять, что там лежит. В ISPmanager сайты обычно лежат так:

/var/www/<пользователь>/data/www/<домен>/

Чаще всего пользователь — www-root, но бывают и отдельные.

Список сайтов и их размеры:

du -sh /var/www/*/data/www/* 2>/dev/null | sort -h

Список баз и их размер:

mysql -e "SELECT table_schema AS db,
  ROUND(SUM(data_length+index_length)/1024/1024) AS mb
  FROM information_schema.tables
  GROUP BY table_schema ORDER BY mb DESC;"

Что ещё обязательно записать для каждого сайта:

• Версию PHP. ISPmanager часто использует альтернативные версии (/opt/phpXX). Если сайт работал на PHP 7.2, на новом сервере ставим ту же версию, а не «самую свежую» — обновление PHP это отдельная задача.
• Режим работы PHP — модуль Apache, CGI или PHP-FPM.
• Свои настройки PHP — memory_limit, upload_max_filesize, max_execution_time, disable_functions. В ISPmanager их часто меняли через панель, и это легко забыть.
• Данные для подключения к базе — из конфига CMS (wp-config.php, config.php, .settings.php и т.д.). Удобнее всего создать базы на новом сервере с теми же именами, пользователями и паролями, тогда конфиги сайтов трогать не придётся.
• Cron:

crontab -l -u www-root

• Почтовые ящики — список доменов и ящиков в панели.
• Нестандартный конфиг nginx/Apache — редиректы, свои location, лимиты. Посмотрите конфиги виртуальных хостов, если там что-то правили руками.

Шаг 2. Подготовка нового сервера

В FastPanel структура очень похожа:

/var/www/<пользователь>/data/www/<домен>/

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

Что делаем в FastPanel:

1. Ставим нужные версии PHP.
2. Создаём пользователя (по возможности с тем же именем, что и на старом сервере).
3. Создаём сайты с нужной версией PHP и нужным режимом обработчика.
4. Создаём базы данных с теми же именами, пользователями и паролями.
5. Переносим свои настройки PHP (лимиты, disable_functions).

Если сайтов много, кликать в панели долго. У FastPanel есть консольная утилита mogwai — через неё сайты и базы можно создавать скриптом. Синтаксис зависит от версии панели, смотрите mogwai --help.

Важно про .htaccess

Если сайт на старом сервере работал через Apache и в нём есть .htaccess с правилами (а это почти любой WordPress, OpenCart, Bitrix), то в FastPanel выбирайте режим с Apache. В режиме «чистый nginx + PHP-FPM» .htaccess просто игнорируется, и вы получите 404 на всех страницах, кроме главной.

Шаг 3. Копируем файлы

Удобнее тянуть с нового сервера на себя. Если на старом сервере SSH на нестандартном порту — указываем его:

rsync -aHAX --info=progress2 -e "ssh -p 22" \
  root@OLD_IP:/var/www/www-root/data/www/example.com/ \
  /var/www/www-root/data/www/example.com/

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

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

chown -R www-root:www-root /var/www/www-root/data/www/example.com/

Права на файлы/каталоги, если на старом сервере был бардак:

find /var/www/www-root/data/www/example.com/ -type d -exec chmod 755 {} \;
find /var/www/www-root/data/www/example.com/ -type f -exec chmod 644 {} \;

Шаг 4. Переносим базы данных

На старом сервере:

mysqldump --single-transaction --routines --triggers --events \
  example_db | gzip > /root/example_db.sql.gz

--single-transaction позволяет снять консистентный дамп InnoDB без блокировки таблиц — сайт продолжает работать.

На новом:

zcat example_db.sql.gz | mysql example_db

Грабли с версиями MySQL/MariaDB

• Дамп из MySQL 8 в MariaDB — ошибка Unknown collation: 'utf8mb4_0900_ai_ci'. Лечится заменой в дампе:

zcat example_db.sql.gz | sed 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' | mysql example_db

• Старый сайт и строгий sql_mode. Старые CMS часто пишут в базу «как попало», а новый сервер со строгим sql_mode начинает отдавать ошибки вроде Incorrect integer value или Field doesn't have a default value. Временное решение — ослабить sql_mode для сервера, правильное — чинить код.
• Кодировка. Если на старом сервере база была в cp1251 (бывает у старых Bitrix и DLE) — дампите и заливайте с явным --default-character-set, иначе получите кракозябры.

Шаг 5. Проверка через hosts

Это самый важный шаг, и его часто пропускают. На своём компьютере прописываем в hosts:

NEW_IP  example.com www.example.com

(/etc/hosts на Linux/macOS, C:\Windows\System32\drivers\etc\hosts на Windows.)

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

• главную и внутренние страницы (тут сразу всплывает проблема с .htaccess);
• админку и вход;
• формы и отправку писем;
• загрузку файлов/картинок через админку (проверка прав);
• логи ошибок сайта в FastPanel.

Не забудьте потом убрать строку из hosts, иначе будете долго удивляться, почему у вас «всё работает», а у клиента нет.

Шаг 6. Финальная синхронизация и переключение

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

1. Если можно — ставим сайт на техобслуживание на старом сервере.
2. Повторяем rsync — пройдёт быстро, скопируется только разница.
3. Снимаем свежий дамп базы и заливаем заново.
4. Меняем A-записи в DNS на новый IP.
5. Проверяем, что сайт открывается с нового сервера (curl -I или dig + браузер без hosts).

Старый сервер не выключаем ещё несколько дней — на случай, если что-то забыли.

Шаг 7. Почта

Почту я переношу через imapsync, а не копированием файлов: форматы хранения у панелей разные, а IMAP одинаковый везде.

1. Создаём на новом сервере те же ящики. Пароли проще задать новые и потом сообщить клиенту, либо узнать у клиента старые.
2. Синхронизируем:

imapsync \
  --host1 OLD_IP --user1 info@example.com --password1 'OLD_PASS' \
  --host2 NEW_IP --user2 info@example.com --password2 'NEW_PASS' \
  --ssl1 --ssl2

3. Переключаем MX (и A-запись mail., если она есть).
4. Через пару часов запускаем imapsync ещё раз — доберутся письма, которые пришли на старый сервер, пока расходился DNS.
5. Обновляем SPF — там почти всегда прописан старый IP, и после переезда письма начинают падать в спам. DKIM в FastPanel будет новый — добавьте его запись в DNS.

Шаг 8. SSL, cron и хвосты

• SSL. Let’s Encrypt выпускаем уже после переключения DNS — до этого проверка домена не пройдёт. Если нужно, чтобы HTTPS работал сразу, можно временно перенести старые сертификаты.
• Cron. Переносим задания из crontab -l старого сервера. Проверьте путь к PHP в командах: если там стоял /opt/php74/bin/php, убедитесь, что такой бинарник есть на новом сервере.
• Абсолютные пути. Если пользователь на новом сервере называется иначе, путь /var/www/www-root/... превращается в /var/www/другой_юзер/.... Ищем зашитые пути:

grep -rl "/var/www/www-root" /var/www/newuser/data/www/example.com/ \
  --include=*.php --include=.htaccess --include=*.ini

Особенно этим грешат OpenCart (config.php и admin/config.php), Bitrix и самописные сайты.

• Кэш. После переезда сбросьте кэш CMS — в нём тоже бывают старые пути.

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

Чек-лист перед тем, как гасить старый сервер

• [ ] Все сайты открываются с нового IP без hosts
• [ ] Админки работают, загрузка файлов работает
• [ ] Формы отправляют письма
• [ ] Почта приходит и уходит, SPF/DKIM обновлены
• [ ] SSL выпущены на всех доменах
• [ ] Cron перенесён и отрабатывает
• [ ] Бэкапы настроены на новом сервере
• [ ] Старый сервер работает ещё минимум несколько дней «на всякий случай»

Итог

Перенос с ISPmanager на FastPanel — не сложная, но кропотливая работа. Ломается обычно не сам перенос файлов и баз, а мелочи вокруг: режим PHP, .htaccess, зашитые пути, SPF. Если сначала всё проверить через hosts и только потом переключать DNS, переезд проходит почти незаметно для посетителей сайта.

В следующих статьях разберу другие варианты переездов — VestaCP → HestiaCP и перенос сервера целиком через rsync.