К сожалению любой хостер — это не вечно живой дедушка Ленин и потенциально обладает нехорошей тенденцией умирать именно тогда, когда это меньше всего ждешь. Эта трагическая случайность и произошла в прошлый вторник с моим, теперь уже почти бывшим, хостером «Украина-Хост».
Понятно, что сразу же суетиться я не стал — потенциально, мог произойти лишь небольшой сбой в работе серверов и через максимум сутки сайт бы снова заработал (неприятно, но пережить можно). Но учитывая, что сервер «упал» во вторник утром и по состоянию на утро четверга все так же валялся пузом кверху и даже не пытался встать, я понял, что тут счастья мне точно не будет — и принял решение переезжать. (Кстати, сервер поднялся только вечером в воскресенье — через 6 дней с момента падения).
Зачастую, главной бедой становится не только сама неработоспособность сайта, но и отсутствие возможности быстро получить резервные копии файлов и сразу же перенести проекты к другой, более «живучей» хостинг-компании. Учитывая, что в моем случае поддержка упорно игнорировала все вопросы на тему — «когда все заработает» (что, в принципе, и понятно — нечего отвечать), связываться с ними еще и по вопросу получения резервных копий смысла явно не было ни малейшего.
Соответственно, сегодня мы поговорим о том — как создать полноценную резервную копию своего блога или сайта в автоматическом режиме и о тех шагах, которые нужно предпринять в том случае, если вы понимаете, что необходимость в переносе проекта уже действительно назрела.
Задолго до произошедшего, я создал аккаунт на Dropbox (зарегистрировавшись по этой ссылке, вы получите +250 Мбайт дополнительногго пространства) — меня давно интересовала идея организовать себе онлайн-хранилище резервных копий сайтов, но с обязательной синхронизацией с локальным компьютером. С одной стороны, удобство онлайна — все копии всегда под рукой и в случае аварии легко восстанавливаются в любой момент и с любого компьютера, а с другой — преимущества оффлайна, позволяющие не зависеть от работоспособности сервиса.
Однако ручное бекапирование — процесс очень тяжелый и утомительный, причем даже не столько физически, сколько требующий постоянной «зарубки» в памяти — «не забыть сделать бекап». Но ведь все мы помним, что WordPress славен не только большой прожорливостью с точки зрения памяти, но также и огромным количеством разного рода плагинов, часть из которых оказывается очень и очень полезной.
Готовимся к «клинической смерти»
Именно к этой категории плагинов и относится расширение под названием WP Time Machine, позволяющее автоматически создавать резервные копии жизненно важных частей сайта с загрузкой получившегося архива на Dropbox. Особо нужно отметить тот набор файлов, которые входят в состав резервного пакета:
- полная копия базы MySQL;
- полная копия содержимого папки wp-content;
- основной файл .htaccess — лежащий в корне сайта.
Одним из больших преимуществ формирования именно такого пакета, является наличие в архиве всей папки «wp-content». К сожалению, основная часть плагинов для бекапирования чаще всего формирует только копию базы данных, а вот файлы нужно сохранять вручную.
При этом, директория «wp-content», как вы помните, содержит не только папку «uploads» со всеми загруженными файлами, но также и папку с плагинами, темами и языковыми файлами WordPress. То есть, по-сути, это именно те файлы, которые и являются вашей личной частью блога — все остальное относится уже к платформе и разворачивается на сервере по-умолчанию — при установке CMS. Единственное чего не хватает, но, думаю, автор плагина через некоторое время добавит — это копии файла wp-config.php.
Наличие папок «plugins», «themes» и «languages» позволяет развернуть сайт на новом месте жительства в несколько раз быстрее, по сравнению с обычной установкой WordPress. С одной стороны — не нужно вручную устанавливать все расширения, а с другой — любые правки, внесенные в файлы плагинов — PHP, CSS, переводы плагинов, языковые переменные и т.д. — не нужно производить заново.
Давайте подробно рассмотрим настройки плагина WP Time Machine, которые я использую. Сразу обратите внимание, что у плагина несколько нетрадиционный интерфейс — выбор производится в одном и том же пункте опции.
Current offsite service: Dropbox — выбор сервиса для сохранения резервных копий. Плагин предоставляет 3 варианта сохранения ваших резервных копий: Dropbox, Amazon S3, FTP. Первый — хранение резервных копий на серверах Dropbox, второй — Amazon Simple Storage Service (Amazon S3) и третий — ваш внешний ftp-сервер.
Относительно хранения резервных копий на ftp-сервере — не настраивайте расположение хранилища на тот же сервер, где расположен сам сайт. Как показал опыт — сервера могут не только лишаться подачи электроэнергии или посыпавшихся винчестеров, но также и неплохо гореть, а пожарные вдобавок еще и заливают их водой.
File format: .tar.gz — выбор формата для создания архива. Альтернативой является формирование архивов в zip, но на моем сервере этот режим не заработал, а кроме того — архив в .tar.gz меньше по размеру, чем в .zip.
Using Post Publish event to trigger backups — если включить эту опцию, то резервная копия будет создаваться автоматически при публикации новой записи в блоге.
Use time-stamped subdirectories to store multiple backups — формировать название папки резервной копии с указанием даты и времени создания. Например, «backup-2010-10-01».
Include cache related directories — включить в архив папку cache, расположенную в папке wp-content. В принципе, включать эту опцию нет особой необходимости, разве что вам по какой-либо причине необходимо обязательно перенести кеш страниц.
Stop logging | View log | Clear log — опции, управляющие лог-файлами плагина. Какие-либо отдельные настройки — не требуются.
Email — если вы выбрали в качестве сервиса для хранения резервных копий Dropbox, в это поле необходимо ввести тот email, с которым вы зарегистрированы в сервисе.
Password — ваш пароль для доступа к сервису Dropbox.
После ввода пароля, обязательно нажмите на строчку «Save my Password» (она изменится на Don’t save my Password»). В противном случае, пароль не сохранится и автоматическое создание резервных копий будет невозможно, т.к. плагин не сможет войти на сервер Dropbox.
Directory — папка в аккаунте Dropbox, в которую будут складываться сформированные резервные копии. Я использую вот такой вариант «backups/proofsite/proofsite», в котором backups — основная папка для резервных копий, «proofsite» — папка для хранения резервных копий этого блога и «proofsite» — заготовка, к которой будут приставлены время и дата создания архива.
После завершения настройки, нажимаем кнопку «Generate wp Time Machine Archive», ждем появления надписи о том, что архив создан и обязательно проверяем его физическое наличие на Dropbox.
Возрождаемся из пепла
Итак, до падения сервера на «Украина-Хост», я установил плагин WP Time Machine и, не смотря на то, что сервер был полностью недоступен — легко развернул копию блога на новом сервере. Ниже описана последовательность моих действий:
- Заказать и оплатить новый хостинг. Кстати, многие хостинг-компании предоставляют 3-5 дней тестового периода, которым можно воспользоваться как временным пристанищем — без оплаты.
- Скачать свежую версию WordPress — раньше я пользовался отличной сборкой от Lecactus, но в последнее время Иван переквалифицировался в «ФотоКактус» и начиная с 2.8.6, сборки перестали выходить. Соответственно, я взял русскую версию с официального сайта WordPress.
- Установить свежую версию на новый хостинг. Обычная классическая установка WordPress — ничего экстраординарного.
- Открыть панель управления доменами регистратора сайта и изменить DNS записи, перенаправив адресацию домена на новый хостинг — сделаем это заранее, чтобы не терять время.
- Распаковать архив «wpTimeMachine-content-files.tar.gz», ранее созданный WP Time Machine.
- Закачать полученное содержимое папки «wp-content» — на новый сервер с помощью FTP или менеджера файлов, с заменой существующих файлов.
- Переименовать файл «wpTimeMachine-htaccess.txt» в «.htaccess» и закачать его в корень новой копии WordPress.
- Создать с помощью панели управления хостингом новую базу данных, нового пользователя и дать ему соответствующие права.
- Отредактировать файл «wp-config-sample.php», добавив в него информацию о новой базе и новом пользователе и переименовав его в «wp-config.php».
- Импортировать содержимое файла «wpTimeMachine-data-files.sql» с помощью phpMyAdmin в новую базу (функция «импорт»). Созданные WordPress на этапе установки демонстрационные данные будут удалены.
- Дождаться обновления DNS (до 72 часов, но обычно гораздо быстрее) и открыть сайт по старому домену, но на новом хостинге.
Вот так, за 11 простых шагов, я абсолютно без головной боли и болезненных телодвижений для получения у предыдущего хостера резервных копий, развернул новую версию блога на другом сервере, где вы в данный момент и читаете эту статью.
А как вы решали проблемы с упавшими серверами и переносом сайта?
Обратите внимание! wp Time Machine версии 1.9.21 вызывает проблемы с загрузчиком изображений в WordPress 3.3! Либо откатитесь на версию 1.9.16 (у меня она работает) либо до появления новой версии, рекомендуется не использовать этот плагин.