Тестовое восстановление из резервной копии: протокол проверки на один сервис

Собственник производственной компании на 60 человек, через неделю после отказа файлового сервера: «Мне два года говорили, что копии делаются каждую ночь и всё зелёное. Они и делались. Только когда мы попробовали из них подняться, 1С запустилась, а обмен с ЭДО — нет: настройки обмена лежали не в базе. Двое суток искали человека, который помнит, как это было настроено».

Копия, которую ни разу не восстанавливали, — это не копия. Это надежда. Оправдается она или нет, вы узнаете в день, когда выбора уже не будет.

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

Коротко. Тестовое восстановление — это проверка одной конкретной копии: берём копию за известную дату, разворачиваем в отдельной среде, которая не может задеть рабочие системы, выполняем содержательную проверку («открыли накладную от 14 августа и сверили сумму с оригиналом», а не «сервис поднялся»), замеряем время в описанных условиях и записываем результат в протокол, который подписывает ответственный со стороны бизнеса. Итог теста — не «бэкапы исправны», а «вот это восстановлено за такое-то время, вот это не проверялось».

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

Что именно ломается в копии, которую не проверяли

Ломается что-то конкретное и почти всегда не там, где ждали.

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

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

База восстанавливается, приложение не стартует. Данные целы, но нет лицензии, не подходит версия платформы, не хватает файла настроек, который жил рядом с базой, нет сертификата для обмена. Бизнес стоит так же, как если бы данных не было вовсе.

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

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

Бэкап у хостинг-провайдера — это резервная копия компании?

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

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

Политики конкретных хостингов мы не проверяли и утверждать за них не станем. Вместо этого — пять вопросов письмом в поддержку провайдера:

1. Глубина хранения: сколько точек восстановления и за какой период доступно по тарифу?
2. Периодичность: когда и как часто снимается копия?
3. Где копия хранится физически: тот же сервер, то же хранилище, другая площадка?
4. Как я её получаю: из панели или заявкой, в каком формате?
5. Сколько занимает выдача по регламенту и что происходит с копиями при неоплате?

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

Снапшот и реплика — не резервная копия

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

Резервная копия отличается от обоих одним: она отделена от источника во времени и по доступу. Именно её и проверяют восстановлением.

Что согласовать до начала теста

Тест без заранее записанных критериев заканчивается статусом «вроде получилось». До того как инженер что-то запустил, фиксируются пять вещей: объект (один сервис или набор файлов, не «вся инфраструктура»), копия (дата, время, часовой пояс, тип и источник), среда (куда восстанавливаем и чем она изолирована), содержательная проверка (какой документ откроем и с чем сверим) и целевые показатели — допустимое время восстановления и допустимая потеря данных.

За аббревиатурами RTO и RPO прячется вопрос к собственнику, а не к инженеру.

RTO — сколько простоя бизнес готов принять. Не «сколько занимает восстановление», а «через сколько часов без 1С мы теряем деньги и клиентов».

RPO — сколько потерянных данных бизнес готов принять. Копия снимается в 23:00, авария случилась в 17:00 — вы теряете рабочий день ввода. Приемлемо это или нет, решает бизнес: ответ определяет частоту копирования и её стоимость.

Обе цифры согласуются до теста — тогда результат читается однозначно: уложились или нет.

Изолированная среда, ключи и лицензии

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

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

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

Что считать «восстановлено успешно» по типам данных

Формулировка «сервис поднялся» не проверяет ничего. Для каждого типа данных критерий свой и содержательный.

Успех на одном уровне не переносится на другие: восстановленный файл не доказывает, что восстановится база, а запустившаяся база — что поднимется сервер со всеми зависимостями. В протоколе это пишется прямо.

Как замерить время и что этот замер означает

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

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

Восстановление 40 гигабайт на готовом стенде по локальной сети и те же 40 гигабайт из облака на сервер, который ещё надо купить и настроить, — два разных числа. Переносить первое на второе нельзя.

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

Протокол тестового восстановления: что в нём должно быть

Протокол — рабочий результат процедуры: по нему через полгода видно, что именно было проверено. Состав:

1. Объект и копия — что восстанавливали; дата и время создания копии с часовым поясом, тип, источник, идентификатор в средстве резервного копирования.
2. Среда и участники — куда восстанавливали, чем изолировано и кто подтвердил изоляцию до запуска; инженер и присутствующий со стороны бизнеса.
3. Время — начало и окончание по каждому этапу плюс условия замера.
4. Содержательные проверки — не «сервис поднялся», а «открыт документ №… от 14.08.2026, сумма сверена с оригиналом».
5. Расхождения и ограничения — что не совпало, что не проверялось, на каком шаге остановились.
6. Статус — «прошёл в указанном объёме», «прошёл с замечаниями» или «не прошёл». Формулировки «бэкапы исправны» в протоколе нет.
7. Действия по замечаниям (что, кто, к какому сроку), удаление тестового экземпляра, дата следующей проверки и подпись принимающего со стороны бизнеса.

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

Учебный пример заполненного протокола

Ниже — учебный пример с условными значениями. Это не клиентский случай и не обещание сроков «Визард-АйТи».

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

Кто проводит и кто принимает результат

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

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

Как часто повторять: наша рекомендация

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

• Критичные системы — раз в квартал. Те, без которых компания останавливается в тот же день: учётная база, почта, файловый архив с договорами, ключевой сервер.
• Остальное — раз в полгода. Вспомогательные сервисы, архивы, конфигурации оборудования.
• Внеочередной тест — после существенного изменения ИТ-инфраструктуры. Перенос базы, смена средства резервного копирования, новый сервер или гипервизор, переезд в облако.
• Обязательный тест — после смены ИТ-подрядчика. Пока новая команда не восстановила копию своими руками, приёмка не закончена. Порядок передачи — в материале про смену ИТ-подрядчика и передачу дел.

Для сравнения: свод практик CIS Controls в контроле 11 предусматривает тестирование восстановления выборки данных с квартальной или более частой периодичностью — это внешний ориентир, а не обязанность российской компании.

Каждый тест проверяет один сервис. За год набирается покрытие критичного контура и, что важнее, история: видно, сокращается время восстановления или растёт.

Что дальше

• Не уверены, что копии есть у всего. Соберите реестр ИТ-активов компании: в нём видно, у каких систем копии настроены, а у каких нет. Начинайте тесты с сервиса, без которого компания встанет завтра: один сервис в неделю — рабочий темп.
• Думаете про архитектуру копий. Сколько копий и где хранить — в разборе стратегии 3-2-1-1-0.
• Уже случился инцидент. Порядок действий при взломе сайта, включая выбор точки восстановления, — в материале сайт взломали: что делать.

Если проверку удобнее провести не самим: Визард-АйТи проводит тестовое восстановление одного критичного сервиса — согласуем объект и критерии, развернём копию в изолированной среде, передадим заполненный протокол с замечаниями и планом действий. Для первого разговора достаточно назвать сервис и то, чем снимаются копии.

Процедуры и рекомендации, приведённые в статье, актуальны на 5 сентября 2026 года.