Автоматическая проверка бэкапов

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

Для малого бизнеса резервное копирование часто воспринимают как галочку: настроили один раз и забыли. Но полезен не сам факт задания, а способность восстановить рабочие данные в понятный срок. Поэтому проверять надо не только «запустился ли скрипт», а появился ли пригодный для восстановления результат.

Почему зеленый статус обманывает

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

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

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

Что проверять автоматически

Минимальный набор проверок можно сделать без сложной платформы.

Первое - возраст последней копии. Для каждого критичного объекта задается допустимый порог: база 1С, файловая папка, конфигурация телефонии, сайт, почтовый архив. Если свежей копии нет дольше этого порога, нужен алерт. Важно смотреть именно на возраст пригодной копии, а не на дату запуска задания.

Второе - размер и динамика. Если база обычно занимает заметный объем, а свежий архив внезапно стал почти пустым, это повод проверить. Не надо придумывать точные проценты без статистики, достаточно правила «слишком маленький файл подозрителен» и ручной разбор.

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

Четвертое - тестовое восстановление. Для 1С это может быть поднятие копии в отдельном каталоге или тестовой базе без доступа сотрудников. Для файлов - выборочное восстановление нескольких документов. Для сайта - разворачивание в техническом окружении. Подробнее о базовой стратегии мы писали в статье про резервное копирование без своего ИТ.

Алерты должны быть полезными

Плохой алерт звучит так: «Backup job failed». Хороший отвечает на три вопроса: что сломалось, насколько срочно, кто отвечает. Например: «Нет свежей копии базы 1С филиала на Ленинском с ночи понедельника. Последняя пригодная копия старше допустимого окна. Ответственный: подрядчик и директор площадки».

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

Канал тоже должен быть рабочим. Где-то достаточно Telegram-группы с подрядчиком и владельцем процесса, где-то нужен сервис мониторинга. Главное, чтобы уведомление не приходило только на почту уволенного администратора. Для критичных сервисов это можно встроить в общий мониторинг инфраструктуры.

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

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

Например, после обновления 1С, смены сервера, изменения пути к базе или переезда в облако тест восстановления нужен обязательно. То же самое после смены подрядчика: новый ответственный должен не верить старой схеме на слово, а пройти путь восстановления руками.

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

Документация на случай аварии

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

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

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

Где помогает подрядчик

Передать проверку бэкапов на ИТ-аутсорсинг можно, но в договоренности должны быть конкретные действия. Не «следим за бэкапами», а «контролируем свежесть копий, получаем алерты, раз в согласованный период делаем тест восстановления, отправляем короткий отчет».

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

Вместо заключения

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

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