Как проверить свежесть бэкапа Битрикс: чек-лист

Галочка "автоматическое резервное копирование" стоит, а в Списке резервных копий архив двухнедельной давности или файл на 20 байт. Ложное чувство безопасности всплывает уже при аварии. За 15–20 минут вы сверите дату, размер и место хранения последней копии на 1С-Битрикс: Управление сайтом, поймёте разницу между проверкой целостности и тестовым restore и решите, нужен ли алерт на устаревание.

"Бэкап настроен" ещё не значит "есть свежий целый архив". Сначала откройте Список резервных копий и сверьте дату с вашим порогом (часто 24–48 часов), затем размер и local/cloud, потом место вне диска сайта. Штатная проверка целостности – виртуальная распаковка, не замена тестового восстановления. Закрепите алерт на stale и аномальный размер, иначе снова узнаете о проблеме после сбоя.

Речь только про CMS "1С-Битрикс: Управление сайтом" на своём хостинге. Это не Bitrix24 CRM и не облачный портал – инструкции для них сюда не подходят.

Типичная история: ночью диск забился, cron "вроде тикает", утром после инцидента в списке – копия двухнедельной давности или висит auto_lock. Ниже – операционный чек-лист свежести, а не гайд "как впервые включить бэкап".

Поймите, почему "бэкап настроен" не равно "есть свежий архив"

Резервная копия (бэкап) – это архив файлов сайта плюс дамп базы, из которого можно поднять сайт заново. RPO (recovery point objective) – на пальцах: сколько часов данных вы готовы потерять. Если RPO = сутки, а последняя успешная копия старше двух дней, формально "бэкап есть", а по делу вы уже вне плана.

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

Сделайте: запишите порог свежести до проверки (например: критично, если старше 24–48 часов) и обычный порядок размера архива для вашего сайта. Не делайте: считать включённое расписание доказательством свежести – смотрите факт последней успешной копии.

Откройте Список резервных копий и сверьте дату

Официальная точка в админке CMS:

1. Откройте Настройки → Инструменты → Резервное копирование → Список резервных копий.
2. Выпишите для 2–3 последних копий: дату/время, размер, размещение (локально или облако 1С-Битрикс).
3. Сравните дату с порогом RPO: если старше – это FAIL по свежести, даже если "авто" включено.
4. Проверьте файловую сторону: каталог /bitrix/backup/ – локальные архивы по умолчанию лежат здесь; ищите свежие *.tar.gz или части.
5. Убедитесь, что папка /bitrix/backup/ исключена из нового архива – иначе копии начнут вкладываться друг в друга и раздувать объём.
6. Если пользуетесь облаком 1С-Битрикс: помните лимит не более 3 копий и квоты по редакции (от 2 ГБ на Старт/Стандарт до 60 ГБ на Энтерпрайз); при нехватке места новая копия не создаётся.

Схема быстрой проверки:
Порог RPO → Список РК (дата/размер/local|cloud) → /bitrix/backup/ → квота облака → вердикт PASS/FAIL → запись в журнал

Сделайте: один проход по списку и диску за 10 минут и зафиксируйте возраст копии. Не делайте: сразу жать "Создать резервную копию", пока не поняли, почему старая не появилась – иначе маскируете сбой расписания.

Пройдите чек-лист: размер, целостность, хранение вне сервера

Опция "Проверить целостность архива" в штатном инструменте – это виртуальная распаковка без записи файлов на диск. Она ловит явный брак архива, но не заменяет тестовое восстановление на изолированном стенде (без почты, платежей и webhook наружу).

Правило 3-2-1 на пальцах: три копии, два разных носителя, одна вне площадки сайта. Локальный каталог /bitrix/backup/ один – при смерти диска вы теряете и сайт, и "страховку". Имеет смысл держать копию в облаке Битрикс, S3-совместимом хранилище или в бэкапе хостинга; для VPS удобно смотреть тарифы у Beget и отдельно проверить, что бэкап панели реально уходит с диска сайта.

Сделайте: после создания копии включите проверку целостности; раз в квартал или после крупного релиза – короткий restore на стенд. Не делайте: хранить единственную копию только рядом с боевым сайтом.

Найдите типичные сбои, из-за которых бэкап "молчит"

Свежесть ломается не только "забыли включить", а тихими отказами:

• auto_lock после аварийного обрыва – автобэкап не стартует, ручной иногда проходит.
• Кончилось место на диске – новая копия не пишется, старая дата в списке "зеленеет" в голове админа.
• Облачная квота или лимит 3 копий – новая не создаётся, пока не удалите лишнее.
• Зависшие агенты / cron – расписание бэкапа не отрабатывает, хотя витрина открывается. Диагностика планировщика – отдельно в завис cron на Битрикс: что делать.
• После окончания лицензии копии в облаке 1С-Битрикс живут ограниченное время, а restore из облака требует активный ключ – не откладывайте проверку "на потом".

Сделайте: при FAIL по дате сначала ищите lock, диск и квоту, потом расписание агентов. Не делайте: путать "сайт доступен" с "бэкап свежий" – это разные контуры; разовая проверка витрины описана в как проверить работоспособность сайта, алерты о падении – в как узнать, что сайт упал.

Настройте алерт, если бэкап устарел

Ручной заход в Список РК раз в неделю забывают. Нужен сигнал "последний успешный бэкап старше N часов" и отдельно "размер аномально мал". На практике это гаджет даты последних копий с уведомлением в мессенджер, триггеры мониторинга или модуль, который смотрит бэкапы изнутри CMS.

Схема контроля:
Успешный бэкап (дата + размер) → порог stale → алерт в Telegram/email → разбор lock/диска/cron → повторная проверка списка

Общий мониторинг сайта (uptime, агенты, Инспектор) закрывает соседние риски – см. как настроить мониторинг сайта на Битрикс. Для возраста архива нужен отдельный триггер: иначе HTTP 200 будет зелёным, а RPO – красным.

Если хотите проверки бэкапов изнутри CMS и алерты без ежедневного ритуала в админке – подключите сайт в BX Pulse и задайте порог устаревания под ваш RPO.

Сделайте: один алерт на возраст и один на аномальный размер. Не делайте: полагаться только на "успешный код выхода скрипта" без проверки фактического файла в списке.

Что дальше: закрепите результат проверки

1. Запишите в журнал: дата проверки, возраст копии, размер, local/cloud, PASS или FAIL.
2. При FAIL устраните причину (lock, диск, квота, cron) и дождитесь новой успешной копии.
3. Включите целостность после создания и запланируйте тестовый restore на стенде.
4. Включите алерт на stale/size, раз в месяц сверьте, что уведомления доходят, и держите хотя бы одну копию вне сервера сайта.

Итог для владельца: после этого чек-листа вы знаете возраст последней копии, видите ложные "пустые" архивы и не путаете галочку автобэкапа с живой страховкой. Если нужен постоянный контроль изнутри Битрикс – войдите в кабинет BX Pulse или посмотрите demo.

Материал проверен. Автор: Максим Мольков, основатель BX Pulse, разработчик 1С-Битрикс.
Источники: официальная документация 1С-Битрикс по резервному копированию (docs.1c-bitrix.ru, user_help dump, learning "Список резервных копий") и практика мониторинга stale/empty архивов.