Бэкапы сайта на Битрикс: практический чек-лист

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

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

RPO и RTO простыми словами

RPO — допустимая потеря данных по времени. Если RPO равен одному часу, резервирование должно позволить восстановить данные не старше часа.

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

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

Что включать в бэкап Битрикс

База данных

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

Файлы проекта

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

Каталог /upload/

Здесь обычно находятся изображения, документы и файлы, загруженные через административную часть. Потеря /upload/ может сделать базу формально целой, но оставить страницы без контента.

Конфигурация окружения

Нужны версии PHP и базы, конфиги веб-сервера, задания cron, переменные окружения, список расширений, правила firewall и схема контейнеров. Секреты хранят отдельно и шифруют.

Связанные данные

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

Почему архив на том же сервере не защищает

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

Практичная основа — правило 3-2-1:

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

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

Как выбрать расписание

Частота зависит от характера данных. Например, код меняется только при выпуске версии, /upload/ — при загрузке файлов, а заказы и заявки могут появляться каждую минуту.

• база магазина — частые дампы или журналирование между полными копиями;
• файлы и /upload/ — ежедневная инкрементальная синхронизация;
• полная копия — по расписанию и перед опасными работами;
• конфигурация — после каждого изменения окружения;
• долгосрочные копии — отдельно по недельной и месячной ротации.

Нельзя бесконечно хранить все архивы. Заранее задайте ротацию: например, несколько ежедневных, недельных и месячных точек.

Шифрование и доступ

В копиях находятся персональные данные, пароли и коммерческая информация. Архивы следует шифровать, ограничивать доступ и передавать по защищённому каналу. Ключ восстановления нельзя хранить только на сервере, который резервируется.

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

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

Сообщение «скрипт завершился» не доказывает, что получился полноценный архив. Контролируйте:

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

Резкое уменьшение размера архива — повод для тревоги, даже если задание формально прошло успешно.

Как проводить тестовое восстановление

1. выбрать конкретную резервную точку;
2. развернуть чистое изолированное окружение;
3. восстановить базу, код и /upload/;
4. подключить конфигурацию без отправки реальных писем и заявок;
5. проверить авторизацию, страницы, поиск, формы и критические интеграции;
6. зафиксировать время и обнаруженные ручные шаги;
7. обновить инструкцию и устранить причины ошибок.

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

Короткий чек-лист

• определены RPO и RTO;
• копируются база, код, /upload/ и конфигурация;
• есть внешняя и желательно неизменяемая копия;
• настроены шифрование, права и ротация;
• ошибки резервирования отправляют уведомление;
• есть пошаговая инструкция восстановления;
• последнее тестовое восстановление завершилось успешно.

Главный вывод: хороший бэкап — это проверенный процесс возврата проекта в работу, а не набор старых архивов. Если у сайта нет внешних копий и понятной инструкции, начните с аудита и настройки резервного копирования Битрикс.