Короткий ответ: backup считается рабочим только после проверки восстановления. Нужно знать, какие данные копируются, где лежат последние копии, приходят ли уведомления об ошибках, кто отвечает за восстановление и сколько времени занимает возврат файла, базы или сервиса.
Проверка без самообмана
| Проверка | Что подтвердить | Плохой сигнал |
|---|---|---|
| Состав данных | Серверы, базы, файлы, конфигурации, системное состояние | Никто не знает, попадает ли критичный сервис в backup |
| Свежесть копий | Дата последней успешной копии по каждому набору данных | Общий зеленый статус без детализации |
| Место хранения | Локальная копия, отдельное хранилище, облако или другой контур | Копия лежит только рядом с исходными данными |
| Уведомления | Кто получает ошибки и кто обязан реагировать | Ошибки уходят в почтовый ящик, который никто не читает |
| Тест восстановления | Файл, папка, база, виртуальная машина или конфигурация возвращены | Восстановление ни разу не выполнялось |
| Сроки | Реальное время возврата и допустимая потеря данных | RTO/RPO обсуждали только в теории |
| Отчет | Что проверено, что не удалось, что исправить | После проверки нет короткого результата для руководителя |
1. Составьте список критичных данных
Проверка начинается со списка того, что бизнесу действительно нужно вернуть после сбоя: файловые ресурсы, базы 1C, виртуальные машины, настройки сетевого оборудования, почта, документы, конфигурации приложений, ключевые учетные данные и инструкции восстановления.
Важно не путать сервер с данными. Один сервер может быть восстановлен быстро, но без актуальной базы или конфигурации он не вернет рабочий процесс.
2. Проверьте последние успешные копии по каждому набору
Общий статус задания мало что доказывает. Нужна детализация: что именно копировалось, когда завершилось, были ли предупреждения, сколько заняла операция и вырос ли объем данных неожиданно.
Отдельно стоит проверить, не исключены ли из копии важные папки, базы, системное состояние или новые серверы, которые добавили после первоначальной настройки backup.
3. Убедитесь, что копия переживет основную аварию
Если копия лежит только на том же сервере или в той же файловой системе, она может исчезнуть вместе с исходными данными. Для бизнеса важнее не модная схема, а разделение рисков: отдельное хранилище, другой носитель, другой контур доступа, понятная защита от случайного удаления.
Минимальный вопрос: что будет с копией, если сломается основной диск, сервер, учетная запись администратора или офисное питание?
4. Проведите тест восстановления
Тест не обязан сразу быть полной репетицией катастрофы. Начните с малого: восстановить файл, папку, отдельную базу, конфигурацию или одну виртуальную машину в изолированное место. Главное — проверить весь путь от выбора копии до открытия восстановленных данных.
Факт восстановления нужно зафиксировать: дата, что восстанавливали, откуда, куда, сколько заняло, кто проверил результат, какие ошибки возникли.
5. Сравните результат с RTO и RPO
RPO показывает, сколько данных компания готова потерять по времени. RTO показывает, сколько времени можно восстанавливать работу. Если база копируется раз в сутки, а потеря даже двух часов критична, backup не соответствует задаче.
Для руководителя формулировка должна быть простой: при сбое файлового сервера мы можем вернуть данные за такой-то период и потерять не более такого-то интервала, если копии и инфраструктура доступны.
6. Проверьте, кто получает ошибки
Backup часто перестает работать тихо: сменился пароль, закончилось место, отключился агент, истекла лицензия, изменился путь. Уведомление должно приходить туда, где его увидят и обработают, а не просто храниться в журнале программы.
В регламенте нужен владелец реакции: кто проверяет ошибку, когда эскалирует, кому сообщает о риске и как подтверждает исправление.
Короткий отчет после проверки
- что входит в backup и что не входит;
- дата последней успешной копии по критичным данным;
- какой сценарий восстановления проверен;
- сколько заняло восстановление;
- какие данные удалось открыть или запустить;
- какие ошибки и ограничения найдены;
- какие действия нужны до следующей проверки.
Типовые ошибки
- Считать зеленый статус доказательством. Он подтверждает запуск задания, но не гарантирует пригодность данных.
- Копировать не все зависимости. База без конфигурации, лицензии или инструкции может не вернуть сервис.
- Не проверять новые системы. Сервер добавили, а в backup-политику не включили.
- Хранить копии рядом с оригиналом. Одна авария может забрать и данные, и backup.
- Не назначить владельца ошибок. Уведомление без реакции не снижает риск.
Итог: backup действительно работает, если вы восстановили выбранные данные, проверили их пригодность, измерили время возврата и понимаете, какие риски остались.