Как я переносил WordPress между серверами и ничего не потерял

Как я переносил WordPress между серверами и ничего не потерял

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

Расскажу, как я переносил mysurik.ru с одного хостинга на другой и не поседел.

Подготовка — самое важное

Я не люблю сюрпризы. Поэтому перед переездом сделал дамп всего:

1. База данных: wp db export /tmp/mysurik_backup.sql
2. Файлы: tar -czf /tmp/mysurik_files.tar.gz /var/www/mysurik.ru/
3. Проверил целостность: grep -c «INSERT INTO» /tmp/mysurik_backup.sql

Это был план Б. Если что-то пойдёт не так — всегда можно откатиться.

Перенос файлов

На новом сервере создал ту же структуру директорий. Залил архив через rsync — это безопаснее, чем scp или ftp, потому что rsync докачивает файлы при обрыве:

rsync -avz /tmp/mysurik_files.tar.gz mysurik@новый-сервер:/tmp/

На новом сервере распаковал:
tar -xzf /tmp/mysurik_files.tar.gz -C /var/www/

Важный момент: права на файлы. У WordPress свои требования. Я выставил:
chown -R www-data:www-data /var/www/mysurik.ru/
find /var/www/mysurik.ru/ -type d -exec chmod 755 {} \;
find /var/www/mysurik.ru/ -type f -exec chmod 644 {} \;

Перенос базы данных

Создал новую БД и пользователя:
mysql -e «CREATE DATABASE mysurik_ru;»
mysql -e «GRANT ALL ON mysurik_ru.* TO ‘mysurik_ru’@’localhost’ IDENTIFIED BY ‘пароль’;»
mysql -e «FLUSH PRIVILEGES;»

Залил дамп:
mysql mysurik_ru < /tmp/mysurik_backup.sql Правим wp-config.php Это тот момент, где многие спотыкаются. В wp-config.php нужно поменять: - DB_NAME, DB_USER, DB_PASSWORD — под новую БД - WP_HOME и WP_SITEURL — если домен временно меняется Я ещё добавил в wp-config.php несколько строчек для отладки: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); Это спасло, когда после переезда одна из страниц вываливала белую страницу смерти — в debug.log нашёлся конфликт плагина кеширования с версией PHP. Проверка ссылок в базе Если домен остался тем же — тут ничего делать не надо. А если меняется — придётся заменить все вхождения старого домена в базе через wp-cli: wp search-replace 'старый-домен.ru' 'новый-домен.ru' --skip-columns=guid Я не менял домен, но всё равно прогнал search-replace для подстраховки — wp-cli показал 0 замен, значит всё чисто. Акт переноса — DNS Переключил DNS-записи на IP нового сервера. TTL перед этим выставил на 300 секунд (5 минут), чтобы переключение было быстрым. Проверил через nslookup и whatsmydns.net. Через 10 минут сайт открылся на новом сервере. Зашёл в админку — работает. Проверил RSS, sitemap, все страницы — всё на месте. Что пошло не так Из ошибок: на новом сервере стояла другая версия PHP (8.1 против 8.3). Плагин кеширования ругался, пришлось обновить. Ещё imagemagick не обрабатывал webp — доустановил пакет. Итог Переезд занял около часа. Без единого потерянного комментария, файла или настройки. Секрет простой: 1. Полный бекап перед стартом 2. Проверка каждого шага 3. wp-cli как основной инструмент Теперь у меня есть инструкция и скрипт автоматизации на bash — на случай следующего переезда.

Расшифрую детали переезда, которые я пропустил в краткой версии. Потому что именно в мелочах и прячется большая часть подводных камней.

Начну с того, что делать ДО того, как ты начнёшь переносить. Первое — зафиксировать текущее состояние сайта: версию WordPress, список плагинов с версиями, список тем, настройки. Я снял всё это через wp-cli до переезда: wp plugin list, wp theme list, wp option list. Потом, когда на новом сервере что-то не совпадало, я сверялся с этим списком, а не вспоминал по памяти. Ещё я сделал копию wp-config.php и .htaccess (или конфига nginx) — они часто теряются при переездах.

Второе — убедиться, что на новом сервере совместимые версии ПО. У меня было несоответствие PHP: старый хостинг крутил 8.1, новый — 8.3. WordPress работал, но плагин кеширования капризничал. Мой совет: проверь версии PHP, MySQL и расширения (php-gd, php-mbstring, php-xml) ещё до переноса, чтобы не ловить белые страницы после. Меньше сюрпризов — меньше нервов.

Теперь про сам перенос базы детальнее. wp db export — это хорошо, но важно понимать, что в дампе может быть мусор: ревизии, транзиенты, спам-комментарии. Перед экспортом я прогнал лёгкую чистку: удалил старые ревизии, отключил неиспользуемые транзиенты. Дамп стал легче на треть, и залился быстрее. Не критично, но приятно. Ещё я использовал сжатие: wp db export /tmp/backup.sql.gz — с гиговыми базами это реально ускоряет перенос.

Про права на файлы — это то, на чём спотыкается каждый второй. Я выставил стандартные 755 для директорий и 644 для файлов, а владельцем сделал www-data. Но есть нюанс: если у тебя на сайте есть папки, куда WordPress должен писать (uploads, cache), им нужно дать права на запись именно для пользователя, от которого работает PHP. Я после переноса проверил, что загрузка картинок работает, — если бы права были кривые, я бы поймал ошибку «Could not write to directory» при первой же загрузке.

Отдельная тема — кеш. Перед переездом я почистил все кеши: WP Super Cache, объектный кеш Redis, кеш браузера у себя. Потому что перенесённый кеш на новом сервере — это источник необъяснимых багов: то одна страница открывается старая, то другая. После переноса я настроил кеш заново с нуля и прогрел его через простой скрипт, который обходит страницы сайта. Итог: никакого «мусорного» кеша на новом сервере.

Про проверку после переезда — не ограничивайся главной страницей и админкой. Я проверил: внутренние страницы, посты с картинками, RSS-ленту, sitemap.xml, robots.txt, работу комментариев, форму обратной связи, страницу 404, редиректы. Плюс прогонял сайт через сервис проверки ссылок — нашёл пару битых URL, которые всплыли из-за перенесённых настроек постоянных ссылок. Это заняло полчаса, но зато я был уверен, что ничего не сломалось.

Про DNS ещё раз, но с деталями. Смена A-записи — это не мгновенно. Даже с TTL в 5 минут у кого-то старый адрес держится дольше из-за кеширующих резолверов. Поэтому я пару дней жил с двумя серверами: старый продолжал работать (на всякий случай), новый уже отдавал сайт. Через день я убедился, что трафик полностью перешёл, и только потом задеактивировал старый хостинг. Такой подход убрал риск «проснулся — а сайт не работает».

И про то, как избежать потери данных навсегда. Я после переезда не удалял бэкапы сразу — держал их неделю на отдельном диске. Мало ли что всплывёт. И завёл привычку: перед любым серьёзным изменением (переезд, обновление версии, смена темы) — свежий дамп. Стоит это минуту, а спасает от часов боли.

Вот так выглядит мой переезд WordPress изнутри. Не магия, а последовательность проверенных шагов: подготовка, перенос файлов, перенос базы, правка конфигов, проверка, переключение DNS. Если всё сделать по порядку и не спешить — за час-полтора сайт переедет без потерь, и ты почувствуешь себя тем самым «богом администрирования». Я прошёл этот путь уже дважды, и каждый раз после него у меня появлялся готовый чек-лист, который делает следующий переезд ещё быстрее.

Расскажу ещё про скрипт автоматизации, который я упоминал в конце первой части. Это простой bash-скрипт, который делает всё за меня: экспортирует базу, пакует файлы, заливает на новый сервер через rsync, создаёт базу, заливает дамп, правит wp-config из шаблона и запускает проверки. Он не идеален, но берёт на себя 90% рутины. Для меня главная ценность скрипта — не скорость (хотя и она), а предсказуемость: он каждый раз делает одно и то же, без «ой, а про это я забыл». Ошибки ручного переезда — это чаще всего забытые шаги, а не сложность.

Что делать, если после переноса сайт не открывается. У меня есть порядок диагностики, выработанный методом проб и ошибок. Сначала смотрю, отвечает ли nginx и есть ли ошибки в его логах. Потом проверяю PHP: запускаю php -v и смотрю логи PHP-FPM. Потом — база: wp db check и SELECT 1. Дальше включаю WP_DEBUG и смотрю debug.log. В 90% случаев причина находится на одном из этих шагов. Самое частое — несовпадение версий PHP, отсутствующее расширение или неверные креды в wp-config.

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

Ещё одна мелочь, о которой забывают: проверь cron. У WordPress есть wp-cron, который срабатывает при обращении к сайту, но если ты переносишь сайт на новый сервер — убедись, что системный cron настроен. Я при переезде потерял расписание автоматических бэкапов и уведомлений — они молча перестали работать, и я заметил только через неделю. Теперь после любого переезда я проверяю crontab в первую очередь.

И про медиафайлы отдельно. У меня медиатека была большой — несколько гигабайт картинок. Если переносить их в общем архиве — долго. Я вынес загрузки в отдельный rsync, который запускал параллельно с переносом кода. Так общий переезд занял меньше времени. А после переноса я проверил, что все картинки на месте: прогнал скрипт, который сверяет количество файлов в uploads на старом и новом сервере. Числа сошлись — значит, ничего не потерялось.

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

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

И про тесты после переноса ещё пару слов. Я не просто открыл страницы — я прогнал сайт через инструменты проверки скорости и через Google Search Console (попросил переобойти страницы). Так я убедился, что сайт индексируется с нового адреса и скорость не просела. Если у тебя есть рекламные кампании или партнёрки, следящие за конверсией — обязательно проверь, что пиксели и счётчики работают после переезда. Я забыл про один счётчик, и потерял пару дней статистики, пока не заметил.

Если говорить совсем коротко — мой переезд уложился в формулу «подготовка + чек-лист + откат». Подготовка — это бэкапы и список версий. Чек-лист — это пошаговая последовательность, которую я не нарушаю. Откат — это готовый план Б на случай форс-мажора. Собери эти три вещи — и любой переезд WordPress перестанет быть стрессом. Я делал это дважды, и каждый раз после переезда у меня оставался только один вопрос: «Почему я раньше боялся?».

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

И последняя деталь: после переезда не забудь зайти в админку и проверить настройки постоянных ссылок (просто сохранить их ещё раз). Это классический трюк: после переноса WordPress иногда начинает отдавать 404 на страницы, потому что структура ЧПУ «забылась». Пересохранение настроек пересоздаёт правила — и 404 исчезают. Мелочь на минуту, но спасает от паники.