Бэкапы, которые не спасут: как проверить, что резервные копии действительно восстанавливаются

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

Между «бэкапы настроены» и «бэкапы гарантированно восстановят данные» — огромная дистанция, которая становится видна только в тот момент, когда восстановление уже необходимо. И это худший момент для сюрпризов.

Копия рядом с оригиналом не защищает вообще ни от чего

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

Правило «3-2-1» существует именно для того, чтобы отказ одного узла не мог уничтожить всё сразу: три копии данных, на двух разных типах носителей, одна из которых физически или логически изолирована от основной инфраструктуры. Звучит просто, но на практике этот принцип соблюдает меньшинство компаний — обычно потому, что настраивали бэкап один раз, много лет назад, и с тех пор к схеме не возвращались.

Бэкап, который никогда не восстанавливали, — это гипотеза, а не факт

Резервное копирование может месяцами отрабатывать без единой ошибки в логах и при этом создавать повреждённые или неполные копии, которые обнаруживаются только в момент реального восстановления. Причины разные: место на диске незаметно закончилось на середине задания, изменилась структура базы и старый скрипт бэкапа перестал захватывать часть таблиц, лицензия на агента резервного копирования истекла тихо, без предупреждения на видном месте. Всё это не помешает системе бодро писать в лог «backup completed successfully».

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

Как часто нужно проверять

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

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