Каждый веб-разработчик регулярно сталкивается с задачей миграции. Сюда входят и развёртывание (deploy) локальной версии на удалённом сервере, и перенос работающего сайта с одного сервера на другой. Некоторые печатные издания для программистов называются «Cookbook» – что буквально значит «книга рецептов». Рецептов множество, какой из них лучший — дело вкуса. В этом материале автор расскажет о том, какую технологию переноса типичного сайта на WordPress он считает оптимальной, и почему.
Также данный материал подойдёт для тех, кто хочет узнать больше о резервном копировании сайта и последующем его восстановлении. Потому как по сути это два необходимых шага для осуществления миграции.
Резервное копирование данных
С технической точки зрения нам предстоит сделать копии двух составляющих сайта:
- Файловой системы
- Базы данных
Каждый веб-разработчик должен заботиться о сохранности данных веб-сайта. Поэтому, как правило, после того как рабочая версия развёрнута на удалённом сервере, разработчик сайта настраивает резервное копирование данных или «бэкап» (от англ. «backup copy», резервная копия).
Иногда заботу о создании резервных копий проявляется хостинг-компания. Чаще всего это случается, когда вы пользуетесь услугой простого сайтов.
В чём главная цель разработчика при переносе сайта с одного сервера на другой? Ничего не потерять. То есть на новом месте сайт должен быть полностью идентичен тому же сайту на старом.
Перво-наперво, вы должны убедиться в том, что после создания резервной копии сайта на нём не будут производиться какие-либо изменения.
Самый простой путь — обратиться ко всем редакторам сайта с просьбой не вносить изменения в содержимое сайта на время переноса (допустим, на ближайшие полчаса). Если, например, вы ведёте блог на WordPress, то договариваться с кем-либо нет необходимости.
В случае, когда такой возможности нет, необходимо перевести сайт в режим обслуживания.
Режим обслуживания
Вы могли заметить, что когда WordPress обновляет плагины или ядро системы, посетители сайта видят вместо его содержимого белый фон и поверх большой заголовок «Сайт ненадолго закрыт на техническое обслуживание. Зайдите через минуту.».
Как принудительно перевести в него сайт?
Для этого необходимо в корне сайта создать файл под названием .maintenance и разместить в нём следующий PHP-код:
<?php $upgrading = time();
Результат:
В принципе, этого будет достаточно для того, чтобы никто (кроме администратора сервера) не смог пользоваться сайтом.
Однако, если вы хотите сделать страницу более привлекательной, можете создать в папке wp-content файл maintenance.php, который будет загружаться вместо исходного текста. В нём вы можете сверстать какую угодно картинку для поджидающего окончания работ пользователя.
Также можно порекомендовать специальный плагин, которые можно использовать в тех же целях:
Теперь, когда мы точно знаем, что никакие данные в течение процесса миграции изменены не будут, можем приступать к создании резервной копии базы данных.
Резервная копия базы данных
Способов создания резервной копии базы данных WordPress существует несколько:
- При помощи плагинов WP-DB-Backup, WP Database Backup и прочих.
- При помощи браузерной утилиты phpMyAdmin
- При помощи консоли сервера
- При помощи панели
С целью экономии места в посте не буду рассказывать про первые два способа, они достаточно тривиальны.
Если у вас есть доступ к консоли сервера, и вы умеете пользоваться терминалом — это заметно ускорит работу.
Прежде всего потому, что создании резервной копии выполняется одной единственной командой:
mysqldump -u[пользователь] -p[пароль] [имя_базы_данных] > [имя_файла_резервной_копии].sql
По-хорошему будет заархивировать дамп базы на ходу:
mysqldump -u[пользователь] -p[пароль] [имя_базы_данных] | gzip >[имя_файла_резервной_копии].sql.gz
Текстовые файлы, коим является дамп базы, архивируются наилучшим образом. Размер архива может быть значительно ниже размера дампа базы. Это важно при переносе, т.к. 100Мб перенести куда быстрее, чем 1Гб, например.
Некоторые хостинг-компании предоставляют возможность архивирования данных сайта через панель управления услугами:
После чего на почту приходит заархивированная копия базы данных и сайта.
Однако, далеко не каждый предоставляет подобные возможности клиентам, поэтому если данный вариант присутствует — удобнее всего пользоваться им.
Резервная копия файлов
Файловая система WordPress обычно выглядит следующим образом (без поддиректорий и их содержимого):
├── index.php
├── license.txt
├── readme.html
├── wp-activate.php
├── wp-admin
├── wp-blog-header.php
├── wp-comments-post.php
├── wp-config-sample.php
├── wp-config.php
├── wp-content
├── wp-cron.php
├── wp-includes
├── wp-links-opml.php
├── wp-load.php
├── wp-login.php
├── wp-mail.php
├── wp-settings.php
├── wp-signup.php
├── wp-trackback.php
└── xmlrpc.php
В принципе, больше всего нас интересуют папка wp-content и конфигурационный файл wp-config.php.
Прежде всего потому, что все остальные папки и файлы у различных установок WordPress (в случае использования последней версии системы) не отличаются друг от друга.
Важно: самый быстрый способ переноса файлов — создание архива, перенос архива и последующая разархивация на конечном сервере.
WordPress состоит из сотен файлов. В случае, когда вы продолжительное время ведёте сайт, к этому прибавляются ещё все загруженные вами изображения, плагины и темы.
Представьте себе перенос по FTP тысячи или даже нескольких тысяч маленьких файлов. Для переноса каждого из них требуется сначала установить, а потом разорвать соединение. В итоге процесс получается долгим и иногда случается что-либо потерять в пути. Тем более, когда файлы переносятся сначала на локальный компьютер, а потом уже — на новый удалённый сервер.
Используя для переноса архив, вы перемещаете всего 1 файл. Да, он много больше размером, но за счёт того, что требуется всего лишь одно соединение с сервером, перенос совершается быстрее. При текущих скоростях доступа к сети Интернет разница во времени может составлять десятки, сотни раз.
Настоятельно рекомендую для транспортировки большого скопления мелких файлов использовать архив в роли контейнера.
Так можно использовать консольные утилиты наподобие
rsync, но для этого необходимо иметь навыки работы с консолью севера. Несколько обучающих материалов по теме на англ. — одна и вторая.
Восстановление данных
Итак, архив файлов сайта и дамп базы данных перенесены на новый сервер.
Воссоздание файловой структуры
Первым делом необходимо распаковать архив таким образом, чтобы полностью восстановить исходную структуру файлов и папок.
Чтобы восстановить исходную структуру и не напортачить с папками, необходимо руководствоваться следующим правилом:
Распаковывать архив необходимо там же, где он был создан.
Например, если вы сжимали сайт при помощи консольного архиватора из корня сайта zip -r "full-backup.zip" *, то и распаковывать на новом сервере его необходимо также в корне сайта unzip full-backup.zip.
Обратите внимание, что невидимые файлы, коим является .htaccess не всегда архивируются вместе с остальными. Поэтому, если на вашем новом сайте не работают «красивые адреса», первым делом проверьте, перенесли ли вы .htaccess в корень сайта.
Не забудьте удалить архив с файловой структурой сайта с сервера, чтобы его не могли скачать посторонние.
Воссоздание базы данных
Прежде чем восстанавливать базу данных, необходимо убедиться, что на новом сервере уже создана соответствующая новая база данных.
Если же её ещё нет, то создать новую базы данных можно разными способами:
- Через веб-интерфейс при помощи утилиты phpMyAdmin
- Через панель управления
- Через консоль сервера следующей командой:
mysql -u[имя_пользователя] -p; # после ввода пароля вы войдете в режим командной строки MySQL mysql: CREATE DATABASE [имя_базы_данных] CHARACTER SET utf8 COLLATE utf8_general_ci; CHARACTER SET utf8 COLLATE utf8_general_ci; CHARACTER SET utf8 COLLATE utf8_general_ci; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER ON[имя_базы_данных] .* TO [имя_пользователя]@localhost IDENTIFIED BY '[пароль]';
В результате мы должны иметь на руках:
- Имя базы данных
- Имя пользователя
- Пароль
В некоторых случаях, когда база данных находится на другом сервере, нам необходимо ещё знать адрес хоста (обычно — localhost, если на той же машине).
Используя эти данные мы должны импортировать наш дамп базы данных.
Опять-таки, сделать это мы можем теми же средствами.
В phpMyAdmin выбираем базу данных, вкладку «Импорт», выбираем файл дампа и отправляем форму запроса.
Если вы работаете через консоль, используйте команду mysql -u[имя_пользователя] -p[пароль] [имя_базы_данных] < [дамп_базы_данных].sql.
В случае, если дамп базы данных был заархивинован: gunzip < [дамп_базы_данных].sql.gz |mysql -u[имя_пользователя] -p[пароль] [имя_базы_данных].
Не забудьте удалить дамп базы данных с сервера или перенести его в безопасное место, в случае, если он там был.
Настройка файла конфигурации
Теперь необходимо открыть в редакторе файл wp-config.php и установить соответствующие настройки для соединения с новой базой данных:
Не забудьте удалить файл .maintenance из корневой папки сайта.
Остаётся только проверить работоспособность сайта!
Заключение
Надеюсь, что данное руководство пригодится тем, кто ещё только озаботился вопросом миграции WordPress-сайта и ищет ответов на вопросы.
Вероятно, более опытные веб-разработчики захотят поделиться с коллегами собственными наработками по теме.
Что же, для этого и созданы комментарии. Поэтому любые советы, дополнения и просто обмен опытом категорически приветствуются.
P.S. Важное дополнение в комментарии от nik_vr:
При переносе с localhost'а на реальный сервер нельзя забывать про адрес сайта. Смена домена с одновременным переносом по вашей инструкции сделает сайт абсолютно неработоспособным. По-этому в инструкцию стоит добавить ещё один шаг (актуальный при смене домена, в т.ч. — при переносе с локального сервера на боевой). Для примера будем считать, что сайд переносится с домена mysite.local на домен mysite.ru.
В сохранённом дампе базы данных WordPress ищем все вхождения mysite.local и заменяем на mysite.ru. Можно это сделать в любом нормальном текстовом редакторе (например, Notepad++). После замены аккуратно сохраняем БД, не забывая о кодировке (в случае с более или менее современными версиями WordPress нужна кодировка UTF-8 без BOM).
После импорта базы данных можно выполнить следующую MySQL-команду:
UPDATE wp_options SET option_value = 'http://mysite.ru' WHERE option_value = 'http://mysite.local';
Автор: CuamckuyKot
