Аудит резервного копирования должен отвечать не на вопрос, есть ли backup, а на вопрос, можно ли восстановить нужные данные в нужный срок. Наличие заданий, зеленых статусов и занятого хранилища ничего не доказывает, если неизвестно, что именно копируется, где лежат копии, кто получает ошибки и когда восстановление последний раз проверяли.
Что входит в границы аудита
Сначала фиксируют список сервисов и данных: файловые ресурсы, базы, виртуальные машины, конфигурации, почта, учетные системы, документы пользователей, настройки сетевого оборудования. Для каждого объекта нужны владелец, критичность, допустимая потеря данных и допустимое время восстановления. Без этой карты невозможно понять, какие копии обязательны, а какие только занимают место.
Отдельно отмечают то, что не входит в текущую схему. Частая проблема - сервер копируется целиком, но конфигурация приложения, внешний каталог файлов или база на другом узле остаются вне задания. В отчете это должно быть видно как риск, а не как мелкое замечание.
Проверка покрытия
| Что проверить | Зачем это нужно | Признак проблемы |
|---|---|---|
| Список источников | Понять, все ли критичные данные попали в backup | важный сервис не привязан ни к одному заданию |
| Тип копии | Оценить восстановление: файл, база, VM, образ, конфигурация | есть только образ сервера, но нет понятной проверки данных |
| Исключения | Не потерять каталоги, которые исключили ради скорости | исключения не согласованы с владельцем данных |
| Новые сервисы | Увидеть, как backup подключается после изменений | новые системы появляются раньше, чем задания backup |
| Документация | Проверить, сможет ли другой инженер восстановить сервис | порядок восстановления хранится в памяти одного человека |
Расписание и хранение
Расписание должно соответствовать изменяемости данных. Для одних файлов достаточно ежедневной копии, для базы с активной работой может требоваться другая частота и отдельная логика. Аудит не обязан придумывать идеальную схему вместо проектирования, но должен показать несоответствия: данные меняются чаще, чем копируются; копии хранятся меньше бизнес-требований; разные задания имеют конфликтующие сроки хранения.
Хранилище оценивают по независимости и проверяемости. Важно понять, где находятся копии, что будет при отказе основного сервера, кто имеет доступ к удалению, как контролируется свободное место и есть ли копия вне основной площадки или основного контура управления. Если backup лежит рядом с исходными данными и управляется теми же учетными записями, риск выше, даже если задания формально выполняются.
Уведомления и реакция
Backup без реакции на ошибки быстро превращается в декорацию. В аудите нужно проверить, куда приходят уведомления, кто их читает, как фиксируется устранение и что считается просроченной ошибкой. Одно письмо на общий ящик недостаточно, если никто не отвечает за результат.
Полезный признак зрелости - история инцидентов backup: когда задания падали, почему, сколько времени проблема оставалась открытой, выполнялась ли повторная проверка после исправления. Если такой истории нет, нельзя доказать, что контроль работает регулярно.
Тесты восстановления
Тест восстановления должен быть безопасным и ограниченным по объему, но он обязан доходить до результата, который можно проверить. Для файлового ресурса это может быть восстановленный набор файлов с правами и датами. Для базы - запуск в изолированной среде и прикладная проверка. Для виртуальной машины - загрузка копии без конфликта с production и подтверждение роли сервиса.
В аудите фиксируют не только факт теста, но и доказательства: дата, объект, версия копии, кто выполнял, сколько заняло времени, какие ошибки найдены, что исправлено после теста. Если последний тест был давно или проводился только на простом файле, это не подтверждает восстановимость критичной системы.
Роли и ответственность
Для каждого критичного сервиса должны быть понятны три роли: владелец данных, технический ответственный за backup и человек, который принимает результат восстановления. Если роль владельца не определена, IT может копировать не то, что важно бизнесу, или хранить копии не тот срок.
При внешнем IT-аудите важно не требовать секреты в отчете. Достаточно ссылок на безопасное хранилище, описания ролей и подтверждения, что доступы существуют и проверены. Пароли, ключи и чувствительные конфигурации не должны попадать в документы аудита.
Как выглядит хороший итог аудита
Итоговый документ должен разделять факты, риски и действия. Факт: такая-то система копируется таким-то способом. Риск: нет проверки восстановления базы, срок хранения не покрывает требование, ошибки видит только один человек. Действие: назначить владельца, добавить контроль, провести тест, изменить расписание, вынести копию в независимое хранилище.
Для руководителя полезна короткая сводка по критичности: что можно восстановить уверенно, что требует проверки, где восстановление под вопросом. Для инженера нужен список конкретных пробелов. Для подрядчика - согласованный план исправлений и повторной проверки.
Если аудит выявляет много пробелов, это не провал сам по себе. Опаснее ситуация, когда backup считается готовым без доказательств. Аудит нужен как раз для того, чтобы отделить реальную восстановимость от зеленых индикаторов.
Связанный сервис - IT-аудит: он помогает проверить backup вместе с серверами, сетью, доступами, мониторингом и документацией, чтобы риски не рассматривались отдельно от всей инфраструктуры.
Итог: аудит backup должен проверять покрытие данных, расписания, хранение, уведомления, тесты восстановления, роли и доказательства. Только после этого можно говорить не о наличии резервных копий, а о способности компании восстановить работу.