Резервное копирование магазина на 1С-Битрикс

О резервных копиях вспоминают в двух ситуациях: когда настраивают их и когда они срочно нужны. Между этими моментами обычно проходят месяцы спокойствия — а потом падает диск, срабатывает шифровальщик или неудачное обновление кладёт магазин, и выясняется, что бэкапа нет, или он неполон, или из него невозможно восстановиться. Для интернет-магазина это означает потерю заказов, каталога и клиентской базы — то есть бизнеса.

Этот материал — практическое how-to по резервному копированию магазина на 1С-Битрикс: что копировать, как выбрать между штатным модулем и серверными средствами, как хранить копии off-site, шифровать их и — главное — регулярно проверять восстановлением. Бэкап, который не проверяли, бэкапом не считается. Настройку и сопровождение этих процессов мы закрываем услугами автоматизации на 1С.

Почему бэкап — это не «когда-нибудь»

Интернет-магазин — это данные: заказы, каталог, остатки, клиенты, история. В отличие от статического сайта, эти данные постоянно меняются и стоят реальных денег. Потеря базы за день — это потерянные заказы, недовольные клиенты и разрыв с учётной системой. Потеря клиентской базы — это удар по бизнесу, от которого не все восстанавливаются.

Угрозы разнообразны и все реальны: отказ оборудования, ошибка администратора, взлом и шифровальщики, неудачное обновление, случайное удаление данных сотрудником. От большинства из них защищает ровно одно — актуальная, проверенная резервная копия, хранящаяся отдельно. Поэтому бэкап — не задача «на когда-нибудь», а базовая инфраструктурная гигиена, которую настраивают до того, как она понадобится.

Что копировать: база, файлы, upload

Первая ошибка новичков — думать, что бэкап это «копия сайта». На деле магазин состоит из трёх частей, и без любой из них восстановление невозможно.

Ключевой нюанс — согласованность. База и файлы должны сниматься так, чтобы соответствовать друг другу по состоянию: заказ в базе не должен ссылаться на файл, которого нет в копии upload. Поэтому все три части копируют в рамках одной согласованной процедуры, а не вразнобой в разное время.

RPO и RTO: сколько данных можно потерять

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

• RPO (Recovery Point Objective). Сколько данных вы готовы потерять? Если ответ «не больше часа заказов» — базу копируют часто или ведут журнал транзакций.
• RTO (Recovery Time Objective). Как быстро магазин должен вернуться в строй? Если «в течение часа» — нужны быстрые способы восстановления и репетиции.

Эти два параметра переводят абстрактное «нужны бэкапы» в конкретную схему: частоту копий, способ снятия, объём хранения. Для небольшого магазина RPO в сутки и RTO в несколько часов приемлемы. Для крупного проекта с потоком заказов RPO измеряют минутами, и тогда одними ежедневными дампами не обойтись — добавляют копию бинлогов для восстановления на точку во времени.

Штатный модуль или серверные средства

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

Для серьёзного магазина надёжнее серверные инструменты:

• База — mysqldump или xtrabackup. Первый прост и универсален, второй снимает копию больших баз без долгой блокировки.
• Файлы — tar или rsync. rsync копирует только изменения, что удобно для инкрементных бэкапов больших объёмов.
• Оркестрация скриптом. Скрипт снимает базу и файлы согласованно, архивирует, шифрует и отправляет в хранилище.
• Запуск по cron. Всё это работает по расписанию на уровне сервера, а не вручную из админки.

Выбор зависит от размера проекта: небольшому магазину хватит штатного модуля с выгрузкой во внешнее хранилище, крупному нужны серверные средства. Правильное решение под нагрузку и инфраструктуру подбирается индивидуально — об общем фундаменте мы писали в статье про хостинг и инфраструктуру BitrixVM.

Полные и инкрементные копии

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

• Полная копия. Снимок всего состояния целиком. Надёжна и проста в восстановлении, но объёмна — её делают реже.
• Инкрементная копия. Только изменения с прошлой копии. Компактна и быстра, но восстановление требует цепочки копий.
• Дифференциальная копия. Изменения с последней полной копии — компромисс между объёмом и простотой восстановления.

Типовая рабочая схема для магазина: полная копия раз в неделю плюс инкрементные ежедневно, а базу — чаще. Для файлов, которые меняются редко (фото товаров в upload), инкремент через rsync особенно эффективен: копируются только новые и изменённые файлы. Так достигается баланс между глубиной защиты, объёмом хранения и нагрузкой на сервер.

Хранение off-site и правило 3-2-1

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

Отраслевой стандарт — правило 3-2-1:

1. Три копии данных. Оригинал плюс минимум две резервные копии.
2. Два разных носителя. Копии не лежат на одном диске или в одной системе.
3. Одна копия вне площадки. Хотя бы одна копия хранится off-site — в другом дата-центре или облачном хранилище.

Практически это означает: копии автоматически выгружаются во внешнее объектное хранилище или на отдельный резервный сервер. Тогда даже полная потеря основного сервера не приводит к потере данных — вы разворачиваете магазин из off-site копии.

Шифрование и персональные данные

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

• Шифрование копий. Архивы бэкапов шифруют, особенно те, что уходят во внешнее облако.
• Ограничение доступа. Доступ к хранилищу копий — только у тех, кому он реально нужен, по отдельным ключам.
• Безопасная передача. Копии передаются в хранилище по защищённым каналам, а не открытым протоколом.
• Контроль доступа к ключам. Ключи шифрования хранят отдельно от самих копий.

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

Автоматизация по расписанию

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

• Cron на сервере. Скрипт бэкапа запускается по расписанию системным планировщиком, а не вручную.
• Ротация поколений. Старые копии автоматически удаляются по схеме хранения, чтобы не переполнять диск.
• Мониторинг и уведомления. Об успехе и особенно о сбое бэкапа приходит оповещение — «тихий» отказ хуже всего.
• Логирование. Каждый запуск фиксируется, чтобы было видно, когда снята последняя удачная копия.

Отдельно про агентов 1С-Битрикс: не стоит вешать тяжёлое копирование на них — агенты и хиты не предназначены для длительных ресурсоёмких задач и могут тормозить сайт. Тяжёлые бэкапы запускают на уровне сервера через cron, а не внутри приложения.

Проверка восстановлением

Это самая недооценённая и самая важная часть. Копия, из которой невозможно восстановиться, — не защита, а её иллюзия. Бэкап может оказаться повреждённым, неполным или несовместимым, и выясняется это в худший момент — во время реальной аварии, когда откатываться уже некуда.

1. Регулярное тестовое восстановление. Периодически разворачивайте копию на отдельном стенде, а не «надейтесь, что сработает».
2. Проверка целостности. Убедитесь, что магазин запускается, каталог на месте, заказы читаются, картинки грузятся.
3. Замер времени. Засеките, за сколько реально восстанавливаетесь — это ваш фактический RTO.
4. Фиксация инструкции. Опишите порядок восстановления, чтобы в аварии не импровизировать.

Тестовый стенд для таких проверок удобно поднимать через тот же процесс, что и рабочие окружения — об этом мы писали в материале про CI/CD и деплой на Битрикс. Проверенный по этому регламенту бэкап — единственный, на который можно положиться.

Бэкап в процессе деплоя

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

• Копия перед изменением. Автоматический снимок базы и файлов делается до применения обновления на проде.
• Быстрый откат. Если релиз неудачен, магазин возвращается к предрелизной копии за минуты.
• Проверка на стенде. Обновление сначала обкатывают на копии данных, а не сразу на бою.
• Связь с процессом. Бэкап — обязательный этап пайплайна, а не отдельная ручная операция «не забыть».

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

Частые ошибки резервного копирования

• Копия только базы или только файлов. Магазин не восстановить без всех трёх частей.
• Бэкап на том же сервере. Отказ диска или взлом уносят данные и копию вместе.
• Нет шифрования. Утечка копии = утечка персональных данных клиентов.
• Ручной запуск. О бэкапе забывают ровно перед аварией.
• Одна копия без поколений. Последний бэкап уже унаследовал проблему, откатываться некуда.
• Не проверяют восстановление. Повреждённая копия обнаруживается в момент аварии.
• Тяжёлый бэкап на агентах. Ресурсоёмкое копирование внутри приложения тормозит сайт.
• Нет бэкапа перед обновлением. Неудачный релиз ломает магазин без пути отката.

Чек-лист настройки бэкапов

1. Определены RPO и RTO. Известно, сколько данных можно потерять и за сколько восстановиться.
2. Копируются все части. База, файлы проекта и папка upload снимаются согласованно.
3. Схема копий выбрана. Полные и инкрементные копии с подходящей частотой.
4. Хранение off-site. Реализовано правило 3-2-1, копия есть вне основного сервера.
5. Копии шифруются. Архивы защищены, доступ к хранилищу и ключам ограничен.
6. Всё автоматизировано. Запуск по cron, ротация поколений, уведомления о сбоях.
7. Восстановление проверено. Регулярное тестовое разворачивание на стенде, есть инструкция.
8. Бэкап в деплое. Копия создаётся автоматически перед каждым обновлением прода.

Вывод

Резервное копирование магазина на 1С-Битрикс — это не разовая настройка, а живой процесс. Полный бэкап включает базу, файлы и upload; копии хранят off-site по правилу 3-2-1 и шифруют из-за персональных данных; частоту задают по RPO, а поколений держат несколько. Всё это автоматизируют по расписанию и встраивают в деплой как шаг перед обновлением.

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