Резервное копирование сайта на WordPress

Резервное копирование сайта WordPress

Всем привет! Сегодня речь пойдет про резервное копирование сайта. Резервное копирование — это очень важная составляющая любого сайта. Мы так стараемся над своими блогами, ночами не спим, всё своё свободное время тратим на развитие нашего детища. И в один «прекрасный» момент – всё летит к чертям. Причин может быть десятки: блог взломали, проблемы у хостера, проблемы с базой данных, неудачно установилось обновление движка WordPress или плагина, не совместимы версии плагина и движка, мы сами можем что-то не то нечаянно сделать… Придумывать можно сколько угодно, но случится что-то еще. В интернете много статей с описаниями плагинов резервного копирования, в которых говорится, как настроить плагин для создания резервной копии. Но очень мало информации о том, как это всё потом восстанавливать. Опишу, как сделать различные резервные копии, и как из них потом восстановиться.

Содержание:

  1. Общие правила
  2. Ручное создание резервной копии
  3. Плагины резервного копирования
    3.1. BackUpWordPress
    3.2. BackWPup
    3.3. Другие плагины
  4. Восстановление из резервной копии

1 Общие правила

Резервное копирование представляет собой создание полной или частичной копии сайта, а так же последующее помещение копии в надежное хранилище. Как я уже не раз говорил, блог/сайт на WordPress состоит из двух частей. Одна часть – база данных, вторая часть – файлы. Копировать можно по отдельности, а можно всё сразу. Важно понимать соответствие между базой данных и файлами. Поэтому я предпочитаю делать полный бэкап.

Резервную копию необходимо поместить в надежное место. Лучше, если это будет не жесткий диск Вашего компьютера, а что-нибудь типа Яндекс.Диск, Google диск, Dropbox. Старайтесь не делать копии слишком часто. Хранить и разбираться в них будет неудобно. Необходимо найти золотую середину оптимальности. Предположим место для хранения ограничено 4 копиями. А на блоге у Вас появляются 2-3 статьи в неделю. Раз в неделю копию сделать будет достаточно. При этом у Вас будет, на всякий случай, архив месячной давности, и самое страшное – Вы потеряете 2-3 последние статьи.

Помимо текущих архивов, создаваемых периодически нужно делать бэкап перед каждым обновлением. Установленные плагины могут не заработать с новой версией движка. А так же, желательно иметь ключевые архивы – архив, сделанный сразу после установки WordPress, архив сделанный после установки всех плагинов и полной настройки блога и темы, и прочие подобные архивы. Поясню для чего это нужно на примере своего опыта.

Давно это было, сделал для знакомого сайт. Небольшая посещаемость, немного информации, в общем, обычный сайт – визитка, на движке WordPress. В то время я не сильно озадачивался проблемами безопасности. Сделал резервную копию (к этому вопросу я всегда подходил серьезно). Жил сайт несколько лет, за этот период было сделано еще несколько копий вручную. Однажды обнаружил, что почта с сайта не отправляется (не работает форма обратной связи, заказ онлайн). Начал разбираться, выяснилось, что хостинг блокирует отправку почты. Позвонил в поддержку, оказалось, в файлах есть скрипты, по сигнатурам – вирусы. Посмотрел и правда есть. Разобрался. В работающий сайт вшили скрипты, которые в определенное время делали почтовую рассылку писем (спам). А вирус появился давно, просто не обнаруживал себя. И в одну из предыдущих резервных копий попал. Т.е. откатываться к предыдущему бэкапу было бессмысленно. Пришлось сравнивать файлы движка с самой первой резервной копией, смотреть что изменилось, чистить. Да, рутина, да пришлось повозиться. Но в итоге все файлы привел в порядок, и сайт снова нормально заработал, и хостинг снял все блокировки.

Небольшой итог:
— нужно делать резервную копию базы данных и файлов блога;
— хранить резервные копии нужно в надежном месте, желательно на облачных серверах;
— хранить нужно ключевые копии и несколько текущих.

2. Ручное создание резервной копии

Резервная копия файлов блога. Заходим на сайт по FTP. Копируем все файлы. На компьютере создаем архив из полученных файлов. Резервная копия фалов сайта готова! Есть небольшая хитрость. Если копировать по FTP все файлы блога, это может занять продолжительное время. Часто, в панели управления хостера есть возможность создать архив всех файлов. А по FTP скачивать одним архивом будет в несколько раз быстрее.

Резервная копия базы данных. Заходим на страницу входа в phpMyAdmin. Адрес этой страницы нужно уточнить у хостинг-провайдера (Рис 1).

Вход в phpMyAdmin. Блог Андрея Дубина
Рис. 1. Вход в phpMyAdmin.

Выбираем нужную базу данных в списке слева, в моем случае она одна. Когда откроется список таблиц, кликаем «Экспорт» (Рис 2).

Экспорт базы данных MySQL. Блог Андрея Дубина
Рис. 2. Экспорт базы данных MySQL.

Здесь ничего не меняем, все настройки по умолчанию, все таблицы выделены. Кликаем «Вперед» или «ОК». Вот скрин с моими настройками (Рис 3).

Экспорт базы данных MySQL. Блог Андрея Дубина
Рис. 3. Экспорт базы данных MySQL.

Сохраняем файл «ВашаБазаДанных.sql». Сохраняем архив с файлами и файл базы данных в одну папку, называем ее датой создания. Бэкап готов. Весь процесс занимает около 10 минут. Не сложно и не долго. Давайте теперь посмотрим, как можно автоматизировать этот процесс.

3. Плагины резервного копирования

Конечно, есть плагины для резервного копирования. Конечно, ими нужно пользоваться. Зачем тратить время на то, что может делаться автоматически. В нашем арсенале огромное количество разных плагинов. В каталоге плагинов WordPress их более 300. Нужно подобрать варианты плагинов, наиболее подходящие Вам. Расскажу про несколько наиболее популярных и понравившихся мне.

3.1. BackUpWordPress

Плагин BackUpWordPress. Блог Андрея Дубина
Рис. 4. Плагин BackUpWordPress.

Устанавливаем плагин, активируем, всё как обычно. Плагин частично русифицирован. Настроек немного, и они достаточно простые. После активации плагин помещается в настройки админ-панели.

Настройка плагина BackUpWordPress. Блог Андрея Дубина
Рис. 5. Настройка плагина BackUpWordPress.

Блок с расписаниями и возможность добавить новое расписание (1). Блок со списком настроек текущего расписания (2). Блок со списком резервных копий (3). Если навести мышкой на путь сохранения резервных копий, то появится всплывающая подсказка «Проверьте закладку Помощь, чтобы научиться изменять путь расположения резервных копий». Проверяем закладку Помощь (4).

Настройка плагина BackUpWordPress. Блог Андрея Дубина
Рис. 6. Настройка плагина BackUpWordPress.

Есть возможность настроить разные переменные. Меня всё устраивает, кроме папки, в которой хранятся резервные копии, я ее изменил. Для этого необходимо, зайти на сайт по FTP, создать нужную папку(например, wp-content/backups/backupwordpress) и в конец файла wp-config.php прописать строку:

define( ‘HMBKP_PATH’, ‘/home/host/mysite.ru/docs/wp-content/backups/backupwordpress’ );

Отлично, где хранить бэкапы настроили. Теперь настроим, что сохранять и когда. Кликаем «Добавить расписание».

Резервная копия. Выбор типа резервирования. Только файлы, только база данных, файлы и база данных.

Расписание. Выбор регулярности создания бэкапа. От раз в час до раз в месяц. Подбирайте оптимальный вариант для себя.

StartTime. Время для запуска скрипта резервного копирования. Лучше выбрать время наименьшей активности посетителей на сайте, всё таки копирование сайта — это серьезная ресурсозатратная процедура.

Количество резервных копий на этом сервере. Укажите сколько копий хранить. После создания бэкапа самый старший удаляется, если их количество больше введенного здесь числа.

Уведомление по электронной почте. Если укажете в этом поле почту, после завершения создания резервной копии будет отправлено письмо с отчетом. Если размер резервной копии будет меньше 10Мб, то она будет прикреплена к письму. В примере у меня пустой движок WordPress. Резервная копия БД + файлы занимает 14Мб.

После создания расписания можно задать исключения любых файлов и папок из бэкапа. Сами бэкапы автоматически исключаются и не входят в архив с новым бэкапом.

Плюсы. Небольшой плагин, очень простой в настройке, частично русифицирован, делает резервную копию БД и файлов. Есть возможность исключить папки и файлы из резервной копии.

Минусы. Следует отметить, что данный плагин не умеет выгружать бэкапы в какое-нибудь хранилище.

3.2. BackWPup

Плагин BackWPup. Блог Андрея Дубина
Рис. 7. Плагин BackWPup.

Устанавливаем плагин, активируем. После активации плагин помещается в меню панели управления со своим подменю.

Dashboard. Страница быстрого доступа к часто используемым функциям плагина (Рис 8).

Настройка плагина BackWPup. Блог Андрея Дубина
Рис. 8. Настройка плагина BackWPup.

Jobs. Страница с заданиями на резервное копирование. Можно изменить любую задачу, удалить, добавить новую (Рис 9).

Настройка плагина BackWPup. Блог Андрея Дубина
Рис. 9. Настройка плагина BackWPup.

Add new job. Добавление расписания (Рис 10).

Настройка плагина BackWPup. Блог Андрея Дубина
Рис. 10. Настройка плагина BackWPup.

Закладка General. Основные настройки. Можно задать имя задачи (Please name this job). Что нужно включить в бэкап (This job is a …). Поставьте галочку напротив нужного действия. Можно включить в копию базу данных, файлы сайта. Так же можно включить XML – экспорт блога в файл, список установленных плагинов. После включения опции появляется новая закладка с более детальными настройками. Можно задать имя файла резервной копии (Archive name). Можно выбрать формат архива (Archive Format). Так же есть различные варианты, что сделать с архивом резервной копии (Where should your backup file be stored?): В папку на хостинге, отправить на почту (если размер архива не превышает 20Мб), на диск Dropbox, и на некоторые другие диски. Еще есть настройки уведомлений по почте.

Закладка Schedule. Настройки расписания резервного копирования. Либо вручную, либо по расписанию.

Закладка DB Backup. Настройки базы данных. Можно исключить какие-либо таблицы, если необходимо. Так же можно задать название файла базы данных и сжатие.

Закладка Files. Настройки файлов. Можно исключить папки, если необходимо.

Ну и другие закладки, если Вы выбрали соответствующие галочки на закладке General. Настройки не сложные.

Logs. По каждому заданию резервного копирования можно посмотреть подробный отчет (Рис 11).

Настройка плагина BackWPup. Блог Андрея Дубина
Рис. 11. Настройка плагина BackWPup.

Backups. Список бэкапов, каждый можно скачать или удалить, посмотреть где на хостинге лежит (Рис 12).

Настройка плагина BackWPup. Блог Андрея Дубина
Рис. 12. Настройка плагина BackWPup.

Settings. Страница настроек плагина. Достаточно тонко можно настроить плагин. Но особых изменений не требуется. Можете оставить все настройки по умолчанию (Рис 13).

Настройка плагина BackWPup. Блог Андрея Дубина
Рис. 13. Настройка плагина BackWPup.

Плюсы. Плагин, имеющий достаточно большой спектр настроек, делает резервную копию БД и файлов. Есть возможность исключить папки и файлы из резервной копии. Данный плагин умеет выгружать резервные копии в различные облачные сервисы, в том числе DropBox. Отправляет отчет о проделанной работе на почту.

Минусы. Плагин не русифицирован. Не умеет выгружать в Google Disk. Хотя это небольшой минус, ведь есть другие облачные сервисы. Но лично мне хотелось бы в GoogleDosk.

3.3. Другие плагины

Как я уже говорил, плагинов огромное количество. Расскажу коротко еще о некоторых, интересных плагинах.

Backup & Restore Dropbox. Плагин делает резервную копию базы данных и файлов по расписанию и отправляет в облачное хранилище DropBox. К сожалению, автоматическое копирование по расписанию только в платной версии PRO. Один из вариантов – это использовать плагин для резервного копирования, а в облачное хранилище бэкапить только папку с архивами. Таким образом резервная копия создается на хостинге и отправляется в облако.

Dropbox – это сервис облачного хранения данных. Бесплатный аккаунт – 2Гб. Вполне достаточно для резервных копий блога. Принцип такой – есть 2Гб на сервере, на любое устройство (компьютер, ноут, телефон) ставиться приложение, которое синхронизирует папку облака с локальной папкой. Плагин делает резервную копию, кидает ее в облако. При синхронизации этот бэкап попадает в локальную папку компьютера. Вы имеете бэкап на надежном сервере и на своем компьютере. Очень удобно.

Google Drive for WordPress. Плагин, очень похож на предыдущий, но только для GoogleDrive. Устанавливаете, настраиваете резервное копирование по расписанию, и все бэкапы пересылаются в аккаунт облака GoogleDrive. Очень удобно. Тем более, что очень много телефонов на андроиде. Есть андроид, должен быть аккаунт gmail. А это означает, что и GoogleDrive уже тоже есть. Если кто-то из обладателей андроидных телефонов этого не знал — теперь в теме.

WP Database backup. Хороший, популярный плагин для резервного копирования базы данных. Если файлы не изменяются, а статьи без изображений, то резервное копирование базы данных – то, что надо.

Use your Drive. Хотелось рассказать про этот плагин. Его особенность в том, что этот плагин синхронизируется с аккаунтом GoogleDrive. Т.е. в облаке находится точная копия файлов сайта, зеркало сайта. Достаточно интересная идея. Вы имеете точную копию сайта в облаке и на своем компьютере (если стоит приложение синхронизации облака с компьютером). Минус данной схемы в том, что копия только файлов. Если сюда подключить, например, предыдущий плагин, который будет делать резервные копии базы данных и складывать их в папку на хостиге, а данный плагин будет всё синхронизировать с облаком, то получим достаточно неплохую связку.

UpdraftPlus. К сожалению, к этому очень популярному плагину хочу написать отрицательный отзыв. Мои отношения с ним не задались. Резервное копирование, который делает этот плагин – несколько папок из каталога wp-content. Базу данных делает адекватно. Но вот файлы… Что потом с этим делать? Мне плагин не понравился именно перспективами восстановления. Настройки простые, удобные, всё красиво и здорово. Но восстановиться без бубнов не получится.

4. Восстановление из резервной копии

Создание резервной копии — очень важный момент в блоговедении. Но не менее важный – восстановление.

С восстановлением файлов трудностей не должно возникнуть. При выборе плагина мы обратили внимание, что при создании архива резервной копии, в архив попадают все файлы. Теперь все файлы из архива необходимо залить на сайт по FTP.

Восстановление базы данных посложнее. Для примера возьму файл базы из архива плагина BackUpWordPress. На сервере удалю все таблицы из базы данных (Рис 14).

Восстановление базы данных MySQL. Блог Андрея Дубина
Рис. 14. Восстановление базы данных MySQL.

Кликаем «Импорт». Выбираем файл *.sql из архива резервной копии (Рис 15).

Восстановление базы данных MySQL. Блог Андрея Дубина
Рис. 15. Восстановление базы данных MySQL.

Кликаем «Вперед». Дожидаемся надписи об успешном импорте (Рис 16).

16 Восстановление базы данных MySQL. Блог Андрея Дубина
Рис. 16. Восстановление базы данных MySQL.

Заходим на сайт, в админку, проверяем работоспособность. Все работает. Проверка завершена успешно. Кстати, файл БД должен быть не больше 1,536МБ, в моем случае. Если файл будет больше, нужно будет либо менять настройки сервера из панели управления хостингом, либо делить файл БД на части, либо через поддержку решать. У каждого хостера свои ограничения. Здесь нет ничего страшного. Этот вопрос достаточно легко решаем. Просто будьте к этому готовы.

Немного юмора
Говоришь, говоришь им… Делайте бэкапы!
Ре-гу-ляр-но де-лай-те бэк-апы…
— бормотала уборщица, энергично работая шваброй в серверной.

Желаю, чтобы ваши бэкапы лежали и пылились на облаке, и никогда не использовались по назначению!

Автор: Андрей Дубин.

10 thoughts on “Резервное копирование сайта на WordPress

  1. Ничто не совершенно! И чтобы не попасть впросак, лучше все же выполнять резервное копирование сайта.

  2. Очень нужная вещь, всегда стараюсь делать резервное копирование, чтобы если что не остаться «с носом».

  3. Интересная и нужная информация пользуюсь регулярно, пока неприятностей не было, Бог миловал.

  4. Удивляюсь тому, что многие даже не думают о резервном копировании. Ведь чаще всего сайты лежат на сторонних серверах, а это значит, что полного контроля над ними у владельцев всё равно нет!

  5. Спасибо за подробный обзор. Делать копии это очень важно. У меня пару раз была проблема с сайтом, но мне помогал хостинг с резервными копиями. Всё обошлось хорошо. Но, знать, как их можно сделать надо обязательно. Мало ли что?

  6. Бэкапы во всем должны быть и сайт не исключение. Каждый день на почту приходит архив базы данных, и раз в неделю делаю полный бэкап и файловой системы тоже. + beget хостинг сам делает каждый день бекапы и выкладывает в админку.

  7. На мой взгляд резервное копирование лучше делать почаще. Тогда в случае чего, хоть что-нибудь да останется.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*