Как перенести PHP-скрипт на другой сервер

Перенос скрипта — это не «скопировать папку по FTP». Три части: файлы (включая загрузки), дамп MySQL, новые доступы в конфиге. Забыли дамп — получили пустой сайт с красивой вёрсткой. Забыли files/ или uploads/ — карточки без картинок.

Делайте перенос в одно окно времени: сняли копию → развернули → переключили DNS. Долгая жизнь на двух серверах без синхронизации заканчивается расхождением заказов и объявлений.

Что снять на старом сервере

1. Архив document root целиком. Не только «php-файлы», а cache можете исключить, если уверены — загрузки нельзя.
2. Дамп базы: все таблицы, с данными. Кодировка utf8mb4. Как снимать и заливать — миграция MySQL dump.
3. Запись текущих доступов: хост БД, имя, пользователь (пароль лучше пересоздать на новом месте).
4. Список cron-задач из панели — их тоже перенесёте.

Перед архивом имеет смысл почистить временный мусор, но не удаляйте то, в чём не уверены. Рабочий бэкап-ритуал: бэкап PHP и MySQL.

Подготовка нового хоста

Сверьте PHP и модули со требованиями. Создайте пустую базу utf8mb4 и пользователя с правами на неё. Document root должен указывать на каталог, куда распакуете скрипт.

На shared — домен уже привязан к public_html. На VDS — vhost Nginx/Apache готов, SSL можно включить сразу или после проверки по IP/hosts: SSL, Nginx + PHP-FPM.

Развёртывание

1. Залейте архив, распакуйте в корень сайта. Проверьте, что index.php лежит именно там, куда смотрит веб-сервер — не на уровень выше.
2. Импортируйте дамп в пустую базу.
3. Пропишите в конфиге новые хост, имя БД, логин, пароль. Старые root/пустой пароль с локалки сюда не тащите.
4. Выставьте права на upload/cache: chmod.
5. Поднимите cron на новом месте: cron.

Если после переноса белый экран — сначала error_log и коннект к БД, не повторная заливка поверх. Часто в конфиге остался старый хост localhost с неверным сокетом или старый пароль. См. ошибка базы и 500.

URL в базе и смешанный контент

Многие скрипты хранят полный URL сайта в настройках или в контенте. После смены домена картинки могут бить на старый хост. Обновите URL в админке (если есть поле «адрес сайта») и проверьте несколько карточек с медиа.

Если включили HTTPS на новом сервере, а в контенте остались http-ссылки — браузер ругается на смешанный контент, формы оплаты и кабинет страдают. Прогон после SSL: мануал SSL.

DNS и простой

Пока проверяете новый сервер, можно прописать домен в файл hosts на своей машине и не трогать публичный DNS. Убедились — уменьшаете TTL заранее (за сутки) и переключаете A-запись.

Почта и внешние колбэки (платежи, Telegram) смотрят на публичный домен. После переключения DNS проверьте вебхуки и return URL в кабинетах платёжек.

Права и владелец файлов

На новом VDS архив часто оказывается от root, а PHP-FPM работает от www-data. Симптом: «не могу загрузить изображение», permission denied в логе. Смените владельца на пользователя пула и верните 755/644. На shared панель обычно сама выравнивает владельца при загрузке через файловый менеджер.

Что проверить глазами

• Главная, внутренняя ЧПУ-страница, поиск.
• Вход в админку и кабинет пользователя.
• Одна запись в базу: новое объявление, заказ, комментарий — что есть в продукте.
• Одна загрузка файла.
• Письмо с формы, если настроено.

Локальный прогон перед боем удобно делать на MicroServer, перенос с локалки на хостинг — тот же чеклист.

Откат

Держите архив и дамп со старого сервера, пока новый не поживёт пару дней. Откат DNS + восстановление из бэкапа быстрее, чем «починить на месте» неизвестно что. Если застряли — в поддержку: продукт, старый/новый хост, текст ошибки, без паролей — как писать.

Почта и внешние сервисы

SMTP-пароли в конфиге переезжают с файлами — проверьте, что новый сервер вообще может ходить наружу на 465/587. Некоторые VDS режут исходящую почту до верификации. Платежные webhook URL при смене домена обновляются в кабинетах платёжек отдельно — дамп базы сам это за вас у эквайера не сделает.

Telegram-боты и API-ключи тоже в конфиге/БД. После переноса отправьте тестовое уведомление.

Сокращение простоя

1. Заранее поднять новый сервер и развернуть копию.
2. Проверить по hosts.
3. Перед финалом снять свежий дамп (дельта).
4. Импортировать дельту, переключить DNS.
5. Старый cron выключить сразу.

Для больших баз финальный дамп с --single-transaction и сжатием: миграция MySQL. Общий бэкап-ритуал: бэкап.

Кириллица и сериализация

Слепой search-replace по дампу для смены домена опасен: сериализованные строки PHP хранят длину. Заменили http://old на https://new без пересчёта длины — получите битые опции и странные 500. Лучше менять URL штатными инструментами продукта или скриптами, понимающими serialize. Если после «замены домена в sql» белый экран — откатите дамп.

Разные панели

С ISPmanager на ISPmanager перенос привычнее. Со shared Apache на голый Nginx — заложите время на rewrite: Nginx. Со shared на shared другого хостера — смотрите префиксы имён БД и путь к php для cron: cron.

Подбор целевой площадки: хостинг, VDS. SSL на новом месте: SSL.

Локальный промежуточный этап

Иногда удобно: прод → локальный MicroServer → новый VDS. На локалке ловите сюрпризы дампа без даунтайма. Стек: MicroServer, импорт: phpMyAdmin. Требования PHP на всех трёх точках должны быть совместимы: требования.

Финишный чеклист

• DNS и SSL.
• Админка, кабинет, тестовая запись в БД.
• Картинка из upload открывается.
• Cron живой, на старом выключен.
• Почта и платежный колбэк.
• Мониторинг переключён на новый URL — мониторинг.
• Firewall на новом VDS не забыт — firewall.

Права после распаковки: chmod. Установка с нуля, если решили не тащить старый мусор: установка.