Резервное копирование и бэкап веб-сайта

Сегодня научимся создавать резервную копию сайта на 1С-Битрикс локально на веб-сервер и в облако 1С-Битрикс

Статья уже не новая, решил освежить ее с учетом новых возможностей резервного копирования и своих знаний.

1. Локальная резервная копия сайта без многосайтовости

В 1С-Битрикс резервное копирование уже почти совершенно, как и кэширование, есть целый раздел настроек для резервирования сайта, для этого переходим в:
Настройки - Инструменты - Резервное копирование - Создание резервной копии

Создание резервной копии

Тут выбираем Размещение резервной копии - в папке сайта
Создание резервной копии

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



Далее рассмотрим все заданные настройки детально по пунктам.

1.1. Архивировать БД (Базу данных)

Обязательно в архив отправляем БД и исключаем статистику, поисковый индекс и журнал событий, т.к. это все может занимать большой объем данных, чем больше БД, тем больше это будет занимать  места

1.2. Архивировать ядро

Обязательно архивируем ядро (движок Битрикса, систему) иначе как его потом восстановить

1.3. Архивировать публичную часть

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

1.4. Исключить из архива файлы и директории по маске

Исключаем из архива файлы и директории по маске до версии Битрикс 12, в старших версиях типа Битрикс 16 в этом нет смысла, сейчас резервное копирование хорошо доработано, все эти папки он исключает сам, но все же есть нюансы, о них расскажу ниже.


Если Битрикс младше 12 версии, что надо исключить 100%:

/bitrix/backup - в старых версиях в бэкап летят все прошлые бэкапы и архив сайта бесконечно может расти, в итоге израсходовать все дисковое пространство сервера, наглядно можно заметить, когда например, кроном прилетят сообщения об ошибках, что невозможно что-то сделать или на сайте перестает работать ресайз изображений и все картинки расползаются по дизайну, шаблон сайта внешне просто разлетается.
Но все равно эта папка в архиве будет, т.к. в нее скрипт размещает дамп БД, для дальнейшего восстановления сайта, но прошлых бэкапов там уже не будет.

/bitrix/cache - исключаем неуправляемый кэш;

/bitrix/managed_cache - исключаем управляемый кэш;

/bitrix/stack_cache - исключаем файлы кэша с "вытеснением";

/upload/resize_cache - исключаем файлы кэша ресайза изображений;
Это папка для динамического ресайза изображений с помощью API Битрикс, после восстановления сайта кэш автоматически будет создаваться при открытии страниц посетителями, изображения автоматически уменьшаются и один раз создается кэш, исходные изображения хранятся в других папках и с ними ничего не случится.
Также будет полезно избавиться от множества брошенных файлов в кэше, от неиспользуемого мусора.

Это были самые необходимые папки для исключения из бэкапа, что еще можно исключить?
Есть еще одна папка в которой хранятся всякие мастера и демо-решения

/bitrix/wizards

Это будет прилично занимать места в каждом бэкапе, в моем случае это базовая установка 1С-Битрикс редакция Бизнес размер папки 67 Мегабайт, но у вас может быть и больше, если установлены другие мастера.

Но если исключить всю папку, то вы можете потерять такой полезный мастер, как Местоположения 2.0, если вы разработчик, сможете вручную залить мастер взяв с другого сайта, когда понадобится, т.е. он может быть понадобится, а может быть и нет, всяко бывает, поэтому, если вы не разработчик, наверно самым правильным решением будет удалить ненужные мастера через админку, а нужные оставить для дальнейшего использования, вдруг понадобятся, удаляются мастера и решения в двух местах:

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

1.4.2. Далее чистим список мастеров от ненужных, в моем случае всего два мастера будут мусором, все остальное может пригодиться, в том числе и Мастер настройки Интернет-магазина

1.5. Исключаем из архива файлы определенного размера

Это вам пригодится для исключения из бэкапа больших файлов загруженных на сайт, те же архивы, видео и т.д, но если оно действительно не понадобится при восстановлении сайта.
Я всегда оставляю как есть, т.е. 0 кб, не приходилось ничего исключать.

1.6. Пропускать символические ссылки на директории

Тут у меня всегда тоже все по-умолчанию, галочка снята, но где-то может пригодиться, если есть символьные ссылки на сторонние папки на сервере, которые тоже видимо можно забекапить, но об этом знает только ваш разработчик.


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

1.7. Шифровать данные резервной копии

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

1.8. Проверить целостность архива после завершения

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

1.9. Отключить компрессию архива

Отключив сжатие бэкапа мы снижаем нагрузку на процессор, но увеличиваем размер бэкапа на диске.
У меня железки мощные, поэтому я опцию не включаю.

1.10. Длительность шага и Интервал

Этими настройками также можно регулировать нагрузку на веб-сервер, но об этом расскажу ниже.
На большинстве хостингах важно установить Длительность шага не больше 29 сек. и Интервал не меньше 1 сек.

Опция напрямую зависит от настроек PHP вашего хостинга, по умолчанию у многих установлено в 30 сек.
max_execution_time = 30

Поэтому можете наблюдать такую ошибку, когда заданное вами время явно превышает допустимое на веб-сервере


При установленном значении в "0" архивация будет выполнена за один шаг.

Как проверить разрешенное сервером время выполнения php-скрипта?
- Можно опытным путем проверить, попробуйте установить Длительность шага 60 сек., если появится ошибка, пробуйте 31 сек, если есть ошибка, пробуйте 29 сек, если нет ошибки, значит 30 сек. ограничение.

- Можно в админке Битрикс узнать здесь:
Настройки - Инструменты - Диагностика - Настройки PHP

На этой странице увидим стандартную страницу настроек php.ini на веб-сервере

Находим опцию поиском браузера, в Firefox это Ctrl + F, но тут опять возникают вопросы, видим два столбца с разными значениями, куда смотреть, что действует?

Local Value -  показывает настройки хоста (сайта) в котором вы просматриваете настройки, эти значения локальные в рамках сайта, они могут задаваться в самом Битрикс в файлах
/bitrix/php_interface/dbconn.php
.htaccess

Master Value - эти значения задаются в настройках сервера в файле php.ini в зависимости от окружения на вашем сервере, это может быть:
/etc/php5/apache2/php.ini
/etc/php5/fpm/php.ini
/etc/php5/cgi/php.ini
/etc/php5/cli/php.ini

А также данные значения также можно изменять и в конфигах для конкретного хоста на сервере, но пути к настройкам хоста в разных панелях управления сервером разные, для панели VESTA это:
/home/*user*/conf/web/apache2.conf
/home/*user*/conf/web/nginx.conf

где *user* - имя пользователя на сервере в котором запущен данный сайт, т.е. у вас может быть любой пользователь.

В панели управления сервером ISP Manager это может быть:
/etc/apache2/apache2.conf
/etc/apache2/conf.d/site.ru.conf

Но это еще не все места, зависит от администратора сервера, это самые основные.


Что я хотел этим сказать, чтобы  вы не задавали в Local Value, значение в Master Value будет приоритетным и ограничивать настройку Local Value максимально разреженным значением.
Например, в Local Value = 60, а в Master Value = 30, все равно через 30 сек работа скрипта будет прервана, а вот если в Local Value = 10, а в Master Value = 30 то скрипт будет прерван через 10 сек.

1.11. Максимальный размер несжатых данных в одной части архива

Системные ограничения php не позволяют делать размер одной части архива более 2 Гб, очень удобно хранить архивы в одном файле, но неудобно скачивать/закачивать такие большие файлы на сервер при медленном интернете и FTP-сервером вроде бы может быть наложено ограничение на загрузку больших файлов на сервер, возможно скачать получится, но с закачкой бэкапа на сервер возможен облом.

В этом случае рекомендую выбрать среднее значение в 700 - 1000 Мб, не сильно много будет файлов и небольшой размер.

2. Локальная резервная копия сайта при многосайтовости

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


а) Если архивировать полностью все сайты, то создается одна полная резервная копия сайта включая общую БД для всех сайтов в списке и две папки /bitrix и /upload а публичная часть остальных сайтов сохраняется в архиве в папке типа /bitrix/backup/sites/ID_сайта

Для восстановления всех сайтов разработчик должен вручную перенести папки публичной части сайтов в соответствующие папки на сервере с созданием соответствующих символьных ссылок на сайты, а полностью восстанавливается скриптом restore.php  только один главный сайт, который первый в списке.

Но это уже отдельная тема, я расскажу вам о ней позже, а выглядит в архиве это вот так



б) Если архивировать все сайты раздельно, тогда у не главных сайтов создается архив только публичной части этого сайта + полный бекап БД, а папки /bitrix и /upload будут только у главного сайта в архиве.

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


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

3. Резервное копирование сайта в облако 1С-Битрикс

Данный вид резервного копирования доступен если:

  • Сайт на активной лицензии 1С-Битркс
  • Установлен модуль Облако 1С-Битрикс (bitrixcloud)
  • Доступен на сервере php-модуль mcrypt

Если модуль облачных сервисов 1С-Битрикс не установлен, вы увидите такую надпись

Если здесь что-то не работает, можете проверить активность лицензии сайта, она должна быть активна, проверяется на странице Обновление платформы, в строке Обновления доступны вы увидите дату окончания активности лицензии, тогда и следует продлить ее.
Marketplace - Обновление платформы


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


В моем случае лицензия была активна, но не установлен модуль облачного резервного копирования, устанавливаются родные и встроенные Битрикс модули здесь по кнопке Установить
Настройки - Настройки продукта - Модули


Далее возвращаемся к созданию резервной копии и без всяких настроек создаем выбираем размещение резервной копии в облаке 1С-Битрикс и нажимаем Создать резервную копию

Далее вводим пароль для шифрования архива, обязательно его запомните или где-то запишите, если забудете, восстановить бэкап будет невозможно без пароля.
Пароль рекомендуется не менее 6 знаков длинной с использованием спецсимволов.

В облаке будет храниться только 3 последних бэкапа.
Если место в облаке ограничено, то для сохранения последней копии удалятся все предыдущие.
Если не хватает места для сохранения единственной копии, то будет выведено предупреждение.

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

При создании резервной копии в облако настройки немного изменятся

  • Шифровать данные резервной копии = ВКЛ
  • Исключить из базы данных статистику, ПИ, ЖС = ВЫКЛ
  • Максимальный размер несжатых данных в одной части архива = 100Мб
  • А также в архив будет включена резервная копия БД, ядро и публичная часть, т.е. полный бэкап будет резервироваться в облаке.
После создания резервной копии в облаке вы можете в этом убедиться перезагрузив страницу и открыв Экспертные настройки, они будут такими



Вот столько маленьких файлов будет загружаться в облако в пределах 100 Мегабайт

Сделано это специально, чтобы не забивать полностью большим архивом канал выделенный вашему сайту хостингом, а также это быстрей по времени, чем грузить один большой файл размером в Гигабайты, поменьше нагрузка на сервер, но больше времени потребуется на создание резервной копии + закачка архива в облако вашим сервером.

Обратите внимание!
а) Резервную копию сайта из облачного хранилища 1С-Битрикс можно только восстановить.

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

4. Рекомендации по снижению нагрузки на сервер при резервном копировании сайта на 1С-Битрикс

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


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

4.1. Сначала уменьшаем Максимальный размер несжатых данных в одной части архива примерно до 700 Мб.
4.2. Потом уменьшаем Длительность шага примерно на 10 сек, т.е. до 20 сек.
4.3. Потом увеличиваем время Интервала до 2-3 сек и далее при необходимости.

Остальные настройки пока не трогаем, выглядеть это будет так:

Если этого еще много и бэкап по прежнему сильно нагружает сервер, еще увеливаем интервал  и еще уменьшаем Длительность шага, вот так:


Если все еще не поняли логику, объясняю:

Длительность шага, сек. - чем меньше, тем меньшее время запущен скрипт, но чаще будет запускаться, например, за 30 сек. он может запуститься всего один раз и успеть сделать бэкап, а при 10 сек. он может сделать бэкап за три запуска, что уменьшит длительность нагрузки на процессор и общую нагрузку.

Я не рекомендую ставить больше 29 сек., потому что при 30сек. скрипт уже может умереть, это будет создавать очень большую нагрузку на сервер вплоть до падения MySQL, а также в это время посетители вашего сайта будут очень долго ждать отклика страницы, т.к. при сильной нагрузке на сервер сильно проседает его время отклика.

Интервал, сек. - интервал ожидания следующего запуска скрипта, т.е. если скрипт не успел создать бэкап при первом запуске, он подождет указанное время 5 сек. и опять запустится на 10 сек., и так пока не завершит создание резервной копии.


Если оптимизации выше еще не помогают, хостинг следует менять, но что поделать, не хочется менять и тратиться на переезд, есть еще возможность снизить нагрузку на сервер:

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

4.5. Ну и последней каплей будет отключение Проверить целостность архива после завершения
Если это не помогает, однозначно меняйте хостинг.

5. Заключение

В общем, все случаи уникальны и требуют отдельного внимания разработчика, ориентируйтесь на материал и пробуйте свои настройки.

Еще раз хочу подчеркнуть, кто не полностью прочитал статью, в последних версиях Битрикс 16 исключать из архива временные файлы и директории по маске не нужно, в нем это предусмотрено, т.е. даже вот так все будет в порядке

А в версиях младше, примерно до Битрикс 12, нужно прописывать исключения, чтобы узнать это, вам необходимо хотя бы один раз создать архив сайта без исключений и проверить наличие там папок из первой главы, если они есть, следуйте инструкциям с самого начала.

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

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

Материалы по теме

Имя *
Логин (мин. 3 символа)
E-mail *
*— обязательные для заполнения поля
Логин или e-mail
TUNING-SOFT.RU Разработка умных веб-сервисов