Резервные копии есть, а восстановиться нельзя: как это выясняется

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

Ниже четыре ситуации, которые мы встречаем чаще всего, и способ проверить себя, не дожидаясь худшего дня.

Копии делаются, но не туда

Самый частый случай: резервная копия лежит на том же сервере, что и сама база. Иногда даже на том же физическом диске, просто в другой папке. Такая копия спасает от единственного сценария — когда кто-то случайно удалил файл. От отказа диска, шифровальщика или пожара в серверной она не спасает вообще.

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

Копируются файлы, а не база

Файлы базы данных 1С или SQL можно скопировать «как есть», пока сервер работает. Копия при этом получится, но развернуть её не выйдет: база была в момент копирования в несогласованном состоянии, часть транзакций записалась, часть нет.

Выясняется это ровно тогда, когда копию пытаются восстановить. До этого момента задание отрабатывает без единой ошибки, отчёт зелёный, все спокойны.

Для баз нужны либо штатные средства выгрузки самой СУБД, либо резервное копирование с поддержкой согласованных снимков. Простое копирование папки для этого не годится.

Задание падает, и никто об этом не знает

Копирование настроили полгода назад, оно отработало пару раз, потом на диске кончилось место — и с тех пор задание падает каждую ночь. Уведомления либо не настраивались, либо уходят на почту уволившегося администратора, либо давно улетают в спам и никем не читаются.

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

Копия есть, но развернуть её некуда

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

Скорость восстановления определяется не только копией. Она определяется тем, есть ли у вас описание инфраструктуры, доступы к лицензиям и понимание, в каком порядке поднимать сервисы.

• Куда именно восстанавливать, если текущий сервер недоступен
• Где лежат лицензионные ключи и дистрибутивы
• Сколько времени займёт восстановление и кто его делает
• Какие сервисы поднимаются в первую очередь, а какие подождут

Как проверить свои копии за один вечер

Полноценные учения проводить необязательно. Достаточно трёх действий, и они уже покажут реальную картину.

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

Проверьте, где физически лежит копия. Если на том же сервере или в постоянно подключённой сетевой папке — это не резервная копия, а вторая копия рядом с оригиналом.

Восстановите что-нибудь. Одну базу, одну виртуальную машину, один каталог с документами — на тестовое место. Это единственная проверка, которая даёт настоящий ответ. Всё остальное — предположения.

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

Разобраться в этом — наша работа: настраиваем резервное копирование так, чтобы копия лежала за пределами офисного контура, а восстановление проверялось по расписанию, а не в день аварии.