Как организовать резервное копирование сайта

Описывается как организовать резервное копирование сайта и восстановить сайт из копии. Приводятся возможные варианты копирования/восстановления.

Общие соображения.

Любой работающий сайт – объект динамический. В процессе работы сайта происходят изменения – добавляются статьи, комментарии, сообщения на форуме и т. д. Потерять все это обычно в планы владельца сайта не входит. Поэтому, чтобы в случае возникновения каких-либо проблем с железом или программами, можно было быстро восстановить сайт и вернуть его посетителям, необходимо иметь достаточно актуальную копию сайта, пригодную для быстрого восстановления.

Я неоднократно советовал, что делать резервную копию сайта необходимо перед любой установкой/обновлением темы или плагина, а так же перед обновлением ядра WordPress в ствтьях “Как установить плагин WordPress” и “Как обновить плагин WordPress“.

Резервное копирование может быть периодическое и разовое. Переодическое копирование делается постоянно через некоторый временной интервал. Частота периодического резервного копирования зависит от скорости добавления данных. Думаю, для обыкновенного сайта типа блога, такого как этот, целесообразно делать копирование как минимум каждую ночь.

Если изменение/дополнение на сайте происходят достаточно часто (например, интернет-магазин с несколькими сотнями заказов в день), то, наверное, чаще. Необходимо помнить, что сайт может быть восстановлен в состояние на момент последнего копирования и все изменения с этого момента будут утеряны. В случае частого сохранения изменений, необходим компромисс между частотой резервного копирования и временем отклика сайта. Процесс резервного копирования может длиться несколько часов и требует существенных ресурсов сервера, что замедляет время отклика сайта, а это, в свою очередь, может не понравиться посетителям.

Если потеря данных на сайте даже за небольшой период времени может принести серьезные проблемы владельцу, то, кроме резервного копирования, необходимо применять специальные технологии непрерывной доступности, например, такие как High Availability или Fault Tolerance среды виртуализации VMware vSphere®. Как это организовать я опишу позже в отдельном цикле статей.

Разовое копирование необходимо производить непосредственно перед любым изменением ядра WordPress/темы/плагина. Из-за соображений, приведенных в предыдущем абзаце, время внесения изменений следует выбирать в момент, когда сайт посещают минимальное количество пользователей.

Возможные варианты.

Что может случиться с сайтом. В принципе, только две вещи – поломка сервера (“железа” – аппаратных средств, серьезный сбой операционной системы) и “поломка” WordPress или какого-либо его компонента – то есть, все работает, а WordPress нет. В принципе, “железо” поломаться вполне может, что повлечет за собой полное прекращение функционирования сайта и возможную потерю данных. А вот, WordPress, вряд ли. Работал, работал, взял и поломался. Так не бывает. WordPress Вы можете поломать только сами.

Резервное копирование сервера.

Каждая операционная система имеет встроенные или покупные средства резервного копированя. Среды виртуализации – аналогично. Такие средства не имеют никакого отношения к WordPress, но с их помощью можно копировать и восстанавливать целиком сервер (виртуальную машину). Это один из возможных путей решения проблемы сохранения данных.

Преимущества: просто, надежно, используется сотнями тысяч или миллионами пользователей, восстанавливает целиком сервер в состояние на момент последнего копирования.

Недостатки – в процессе восстановления для пользователей недоступен весь сервер со всеми службами и сервисами. В случае поломки железа, такое решение, является единственным выходом, однако, в случае прекращения функционирования сайта после установки очередного плагина выглядит неприемлемым.

Хорошим примером таких средств является VMware vSphere® Data Protection™ – средство резервного копирования/восстановления виртуальных машин.

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

Для обслуживания WordPress, необходимо обеспечить резервное копирование сети виртуальных сайтов/сайта. Это делается при помощи специального плагина. Если задать «WordPress backup» установщику плагинов WordPress или поиску Google, то получите большой список плагинов различной функциональности.

Большинство из них предлагает хранить Ваши резервные копии на их облаке или на облачных сервисах, как Google Drive, Dropbox. В этом случае возникает вопрос с передачей файла копии – у меня сечас полная копия сети виртуальных сайтов превышает 1ГБ и организация передачи такого фала через интернет требует, как минимум некоторых размышлений, даже при хороших каналах связи.

В результате изучения, я остановился на плагинах BackUpWordPress и Online Backup for WordPress. Они бесплатны, можно обойтись без сторонних «облаков», позволяют выполнять разовые, периодические, полные, инкрементальные резервные копирования (для Online Backup for WordPress), загружать файл копии на компьютер администратора пользователя, посылать его по эл. почте (помните пожалуйста про ограничения размеров файлов при их пересылке). Более подробно установка, настройка и выполнение резервного копирования плагинами описана в статьях “Как сделать backup сайта на WordPress” и “Как сделать резервную копию сайта“.

Заметка: Если произошел аппаратный сбой, то, чтобы вернуть наш сайт посетителям из копии, необходимо сначала восстановить/установить весь сервер, а потом – сайт/сеть WordPress, поэтому использовать резервное копирование сайта для восстановления после краха всей системы есть не очень хорошая идея.

Вывод

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

Случай непрерывной доступности в данной статье не рассматриваем.

Продолжение:

Для плагина BackUpWordPress “Как сделать backup сайта на WordPress” и “Восстановление сайта WordPress из резервной копии“.
Для плагина Online Backup for WordPress “Как сделать резервную копию сайта” и “Как восстановить сайт из резервной копии“.

В статье описано как организовать резервное копирование сайта и восстановить сайт из копии. Рассмотрены преимущества и недостатки возможных вариантов копирования и восстановления.

, ,

No comments yet.

Leave a Reply