Регламент резервного копирования и восстановления

В регламенте стоят ежедневные инкрементные копии, еженедельные полные и ежемесячные архивные. Восстановление проверяют раз в 18 месяцев. Такой порядок приведён в приложении № 13 к требованиям по защите информации.

За полтора года успевают смениться версии СУБД, драйверы, лицензии, пароли и права доступа. Копии продолжают появляться по расписанию, но поднять из них рабочую систему уже нельзя. Проверка файла этого не покажет.

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

Начните с RTO и RPO, а не с расписания копирования #

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

Первый тест начинается с копии

Для каждой системы запишите два показателя:

RTO — сколько времени система может не работать;
RPO — какой объём последних данных компания готова потерять.

В материале Total IT о тестировании восстановления приведены такие примеры: RPO для 1С — не более 15 минут, для файлового сервера — не более часа; RTO для архивного хранилища — до 24 часов. Это примеры, а не нормативы. Ваши значения утверждает владелец системы вместе с руководителем, который принимает риск.

Начальная матрица может выглядеть так:

Система	Владелец	RTO	RPO	Зависимости	Приоритет
1С	Финансовый директор	2 часа	15 минут	SQL Server, лицензирование, Active Directory	1
Файловый сервер	Руководитель ИТ	4 часа	1 час	Active Directory, сеть	2
Архив документов	Главный бухгалтер	24 часа	24 часа	Хранилище, служба каталогов	3

Цели определяют схему копирования. По методике Total IT, RPO в 15 минут требует инкрементных копий с таким же интервалом и резервирования журналов СУБД. RPO в 24 часа допускает ночную полную копию. RPO, равный нулю, требует непрерывной репликации и автоматического переключения: одним резервным копированием такую цель не закрыть.

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

Процедура восстановления должна начинаться с конкретной копии #

Фраза «восстановить базу из резервной копии» перекладывает решения на дежурного администратора. Ему ещё придётся найти нужный набор, вспомнить пароль шифрования, подобрать версию СУБД и понять, можно ли запускать восстановленную машину рядом с продуктивной.

Для каждой системы регламент должен содержать:

Нужную точку восстановления и правило её выбора.
Путь к копии и срок её хранения.
Учётную запись с правами на чтение.
Местонахождение ключа шифрования.
Версии операционной системы, СУБД и прикладного ПО.
Порядок восстановления зависимостей.
Тестовую площадку и требуемые ресурсы.
Команды проверки целостности.
Способ запуска и прикладной проверки сервиса.
Порядок возврата системы в работу.

Практическое руководство ANDPRO требует разворачивать реальную копию отдельно от продуктивной среды. Образ виртуальной машины запускают на тестовом хосте в изолированной сети. Иначе восстановленный сервер может получить продуктивный адрес и связаться с рабочими системами.

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

Успешная проверка файла резервной копии ещё не доказывает, что сервис восстановится. RESTORE VERIFYONLY проверяет резервный набор, заголовки страниц и контрольные суммы, но не проверяет структуру данных внутри набора. ANDPRO приводит это ограничение со ссылкой на документацию Microsoft. Полный тест SQL Server требует развернуть базу, проверить её средствами СУБД и открыть через приложение.

Один администратор не должен быть единственным носителем процедуры #

Если только один сотрудник знает пароль от хранилища и порядок запуска сервисов, компания зависит от его доступности в день аварии.

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

владелец документа следит за актуальностью и согласованием регламента;
технические исполнители создают копии, проводят восстановление и устраняют найденные недостатки;
владелец системы проверяет данные и работу приложения;
руководитель утверждает RTO, RPO, бюджет и принятые риски.

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

В официальном шаблоне из приложения № 13 политику резервного копирования утверждает руководитель отдела ИТ. В структуре политики SecureSlate отдельно перечислены владелец документа, технические исполнители, порядок исключений, контроль исполнения и период пересмотра. Там же указаны реквизиты, которые запрашивают при аудите: версия, дата и утверждающий.

Для каждого исключения запишите срок действия и компенсирующую меру. Например: тестовая площадка для старой ERP недоступна до 30 ноября; до этой даты ежемесячно восстанавливаем базу на временной ВМ и вручную проверяем десять контрольных операций. Фраза «проверить позже» не задаёт ни срока, ни ответственного.

Проверяйте копии на четырёх уровнях #

Проверка одного файла подтверждает лишь то, что его удалось прочитать. Работоспособность базы, виртуальной машины и площадки она не доказывает.

ANDPRO предлагает четыре уровня проверки с нарастающей глубиной.

Уровень	Что делаем	Что подтверждаем	Стартовая частота
Файл или папка	Восстанавливаем отдельно, сверяем содержимое и версию	Копия читается, нужный файл попал в набор	Ежемесячно
База данных	Разворачиваем на тестовом сервере, проверяем СУБД и приложение	База цела и открывается прикладной системой	Ежеквартально для критичных БД
Система или ВМ	Поднимаем образ в изолированной сети вместе с зависимостями	ОС загружается, сервисы работают	Ежеквартально или раз в полгода
Площадка	Поднимаем критичный набор систем из внешней копии	Компания проходит катастрофический сценарий	Ежегодно и после существенных изменений

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

Проверки не заменяют друг друга. Файл может читаться, а база — не проходить контроль целостности. База может открываться средствами СУБД, а 1С — не запускаться из-за лицензии. ВМ может загрузиться, но не найти Active Directory или сервер лицензирования.

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

Протокол отделяет выполненный тест от поставленной галочки #

Протокол показывает, выполнила ли инфраструктура обещание, которое ИТ дал бизнесу.

После каждого теста запишите:

Поле	Что указывать
Система	Название и владелец
Уровень теста	Файл, БД, система или площадка
Точка восстановления	Дата и время восстановленной копии
Начало и конец	Полный интервал работ
Фактический RTO	Сколько заняло восстановление
Фактический RPO	Сколько данных потеряно относительно момента теста
Проверка целостности	Команда и результат
Прикладная проверка	Что открыл владелец системы
Расхождения	Драйверы, права, лицензии, зависимости
Исправление	Ответственный и срок
Решение	Принято или не принято

ANDPRO считает тест успешным при одновременном выполнении пяти условий: данные читаются, целостность подтверждена, сервис работает с зависимостями, фактические RTO и RPO не хуже целевых, результат записан.

Если 1С поднялась за 3 часа при целевом RTO в 2 часа, копия исправна, а цель восстановления не выполнена. Дальше есть два честных решения: сократить время восстановления или согласовать новый RTO с владельцем системы. Заменить измерение формулировкой «восстановление прошло успешно» нельзя.

Бюджет теста считайте отдельно от бюджета хранения #

Тестовое восстановление занимает вычислительные ресурсы и рабочее время. Эти расходы стоит показать до утверждения регламента.

Допустим, ежеквартальный тест 1С выполняют два администратора по четыре часа. Внутренняя стоимость часа — 2 000 ₽. Один тест стоит:

2 человека × 4 часа × 2 000 ₽ = 16 000 ₽

Четыре теста в год обойдутся в 64 000 ₽ без учёта тестового хоста. Если Ваши ставки или длительность отличаются, подставьте их в ту же формулу.

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

Каркас регламента, который можно заполнить сегодня #

Структура SecureSlate включает назначение и область действия политики, роли, правила, исключения, контроль исполнения и период пересмотра. Для технического регламента заполните шесть разделов:

Назначение и область действия. Какие системы, данные и сотрудники входят в регламент.
Роли и ответственность. Кто создаёт копии, кто восстанавливает, кто проверяет сервис и кто принимает риск.
Правила копирования и восстановления. Типы копий, расписание, хранение, шифрование, RTO, RPO и порядок запуска систем.
Исключения. Срок действия, согласующий и компенсирующая мера для каждого отклонения.
Контроль исполнения. Календарь проверок, четыре уровня тестов, фактические RTO и RPO, найденные расхождения.
Пересмотр документа. Дата, версия, утверждающий и события, после которых регламент проверяют заново.

Правило приёмки одно: копия существует лишь технически, пока Вы не развернули её отдельно, не проверили целостность, не запустили сервис и не сравнили фактическое время и свежесть данных с RTO и RPO.