Задача резервного копирования – на Битриксе нет ничего проще, все автоматически резервируется по расписанию, бекапы отправляются в облако, а архивы защищены паролем. Но с ростом проекта штатный функционал уже не тянет – таблицы базы блокируются на 5-10 минут при подготовке дампа, место заканчивается со скоростью звука, при подготовке архивов сайт подвисает или вообще отключается. А минимальная частота бекапов – 1 раз в сутки. Это реальная проблема, когда за час 100 заказов в магазине.
Мы провели анализ требований клиента, изучили существующие решения и определили следующие ключевые аспекты проекта:
- Обеспечение сохранности данных: необходимо было создать систему резервного копирования, которая бы обеспечивала сохранность всех данных сайта (файлы, базы данных) в случае сбоя или аварии.
- Быстрое восстановление: система должна была обеспечивать быстрое восстановление данных после сбоя, чтобы минимизировать время простоя сайта.
- Удобство управления: клиент (да и мы тоже) хотел иметь возможность легко управлять системой резервного копирования и получать уведомления о сбоях.
Для реализации проекта мы выбрали следующие инструменты:
- Restic: утилита для резервирования файлов сайта. Restic позволяет создавать инкрементальные резервные копии файлов, что позволяет значительно сократить объём хранимых данных и ускорить процесс восстановления.
- Xtrabackup: утилита для резервного копирования баз данных MySQL. Xtrabackup обеспечивает быстрое и надёжное резервирование баз данных, а также позволяет выполнять их восстановление с минимальными потерями данных. Кроме того, таблицы не блокируются при бекапе и есть поддержка инкрементальных копий.
- S3-хранилище: для хранения резервных копий мы использовали облачное хранилище S3, которое обеспечивает высокую доступность и надёжность данных. Кроме того, возможно версионирование объектов, их блокировка и репликация в другой бакет. Это полностью исключает доступ к данным при компрометации сайта.
- Telegram: для отправки уведомлений о статусе резервного копирования мы использовали Telegram, который предоставляет удобный и быстрый способ получения информации о состоянии системы.
Процесс настройки системы резервного копирования включал в себя следующие шаги:
- Установка и настройка Restic на сервере CentOS. Мы создали скрипт-обертку для управления restic, который автоматически создаёт резервные копии всех файлов сайта с заданным интервалом – 3 часа нам показалось вполне достаточным. Запускается как системный сервис и упрощает управление резервными копиями.
- Настройка Xtrabackup для резервного копирования базы данных MySQL. Перед резервированием сайта мы настроили создание дампов базы данных. Полный дамп в начале суток, затем инкрементальные от него. Так как фактически копируются файлы базы данных, restic без проблем их забирает и дедуплицирует.
- Подключение S3-хранилища и настройка доступа к нему. Restic имеет встроенную поддержку S3, поэтому только настроили доступ к хранилищу через API.
- Создание канала в Telegram и подключение к нему системы резервного копирования. После завершения резервирования мы проверяем статус резервной копии и в случае сбоя отправляем сообщение в Telegram. Кроме того, запускается периодическая проверка целостности снепшотов и корректности создания бекапа базы, при сбоях так же отправляется уведомление.
В результате мы создали надёжную и эффективную систему резервного копирования, которая обеспечивает сохранность данных сайта и быстрое восстановление в случае аварии. Клиент получил возможность контролировать состояние системы и оперативно получать информацию о сбоях. Система работает автономно и не требует вмешательства, но в случае необходимости статус системы можно посмотреть в консоли – базовую информацию отдает сам restic, а мы дополнительно расширили ее статистикой из системного лога.
Восстановление сводится к вводу одной команды – снепшоты монтируются к диску сервера и затем можно восстановить любые данные копированием в место назначения. С базой данных немного сложнее – там 2 команды.Самое интересное:
сайт объемом 80 GB, а его 10 резервных копий занимают в хранилище 47 GB. Ранее 10 резервных копий, созданных штатным инструментом 1С-Битрикс занимали почти 1TB места.
Это достигается за счет выбора наиболее эффективного метода сжатия и дедупликации данных. Кроме того, резервное копирование теперь не требует наличия на сервере большого количества дискового пространства и не оказывает существенного влияния на процессор и оперативную память. Копии создаются абсолютно незаметно для пользователей сайта и не влияют на его работу.
