Планируемое восстановление критичных сервисов
Случись серьёзный сбой — непонятно, что поднимать первым и сколько компания простоит. Резервное копирование отвечает лишь на половину вопроса: копии есть, а порядка возврата к работе нет. Определяем, без каких сервисов бизнес встаёт, сколько данных и времени допустимо потерять, собираем порядок восстановления и до настоящей аварии проверяем на согласованных системах, что резервные копии действительно разворачиваются в работающие сервисы.
Первый звонок инженера — около 30 минут в рабочее время. Разбираем вашу ситуацию, без презентации.
- Сначала критичные функции и допустимые потери, потом техника
- Порядок восстановления проверяется тестом, а не остаётся документом
- Целевые сроки становятся обязательством, только когда записаны в договоре
- Восстановление с повреждённого носителя в лаборатории — не наша работа
Когда план есть только в общих чертах
Копии делаются, но восстановление никто не пробовал.
Что поднимать первым — вопрос открытый. Сколько это займёт, никто не считал. А если человек, который «всё знает», окажется в отпуске, план перестанет существовать вовсе.
Риски штрафов и инцидентов
Шифровальщик, отказ оборудования или ошибка: защита данных не заканчивается копиями — важно заранее знать, что делать и в каком порядке.
Смотреть сценарийПотеря базы 1С останавливает учёт
Учётная база восстанавливается первой: считаем, сколько работы допустимо потерять и за какое время поднять.
Смотреть сценарийИТ без сильного отдела
При аварии некому решать по ходу: порядок действий и ответственные записаны заранее.
Смотреть сценарийИТ для растущей компании
Систем стало больше, а план остался от старой инфраструктуры: пересобираем приоритеты.
Смотреть сценарийКак идёт работа
Начинаем с бизнеса, а не с техники: какие функции критичны и что происходит с компанией через час и через неделю простоя.
Затем считаем допустимые потери, разбираем зависимости и собираем порядок восстановления. Дальше — тест на согласованных системах: он показывает реальное время и находит то, о чём не написано ни в одной инструкции.
- 01
Называем критичные функции
Что должно вернуться первым и как растут потери по мере того, как простой затягивается.
- 02
Считаем допустимые потери для бизнеса
Сколько работы можно потерять и сколько времени бизнес выдержит без каждого сервиса.
- 03
Разбираем зависимости
Что нужно поднять раньше и без чего сервис не заработает даже при целых данных.
- 04
Собираем порядок действий
Кто начинает восстановление, где лежат копии и доступы, кого и когда предупредить — с опорой на действующий регламент резервного копирования.
- 05
Проверяем тестом
Поднимаем сервис из копии, засекаем время, находим узкие места и правим план.
Что входит в работу
Определение критичных функций и допустимых потерь, разбор зависимостей, порядок восстановления с ответственными, тест на согласованных системах и честный перечень того, что мешает уложиться в желаемые сроки.
Само копирование данных — состав и расписание — описано на странице резервного копирования, а восстановление с физически повреждённых носителей мы не выполняем.
Что остаётся у компании
Перечень критичных сервисов с приоритетами и допустимыми потерями, схема зависимостей, порядок действий при сбое с ответственными и контактами, результаты теста с фактическим временем и список узких мест.
Что меняется, когда план проверен
Ответ на вопрос «сколько мы простоим» становится числом, а не предположением: резервное копирование из фоновой задачи превращается в проверенную возможность вернуться к работе.
Ясно, что поднимать первым и кто это делает. И самое важное — известно заранее, где план не выдерживает: обычно это обнаруживается на тесте, а не в шесть утра во время настоящей аварии.
Сейчас
С услугой
Резервные копии делаются, но никто не пробовал из них восстановиться.
Проводим тест на согласованных системах и засекаем время. Наличие копии и возможность восстановиться — разные вещи, и разница выясняется до аварии.
На вопрос «сколько мы простоим» ответа нет ни у кого.
После теста ответ становится числом с условиями: столько-то часов при таком объёме данных и таком оборудовании. Это уже можно обсуждать с бизнесом.
Поднимать начинают то, что проще, а не то, что нужнее компании.
Порядок задаёт бизнес: сначала то, без чего останавливаются деньги и срываются обязательства. Зависимости учтены, чтобы не поднимать приложение раньше базы.
План существует в голове одного специалиста.
Записываем порядок действий с ответственными, контактами и местом хранения копий и доступов. Отпуск или увольнение перестают быть риском.
Желаемые сроки восстановления никто не проверял на реальность.
Тест показывает, достижимы ли они. Если нет — называем, что этому мешает: объём данных, скорость канала, отсутствие запасного оборудования.
После аварии выясняется, что копии заражены вместе с рабочими системами.
Проверяем, изолированы ли копии и переживут ли они заражение сети. Это отдельный вопрос, и он решается до сбоя, а не после.
Посчитаем, сколько займёт восстановление на самом деле. Расскажите, без какой системы работа встанет в первую очередь.
Границы работы
Что можно обещать, а что — нет
Целевые сроки восстановления и допустимые потери остаются целями, пока не записаны как обязательство конкретного проекта или соглашения об уровне сервиса.
Что фиксируем в договоре
- Обязательства по срокам и допустимой потере данных фиксируются в конкретном проекте или SLA.
- Постоянная реакция и регулярные проверки появляются в договоре сопровождения.
Что согласуем отдельно
- Универсальный срок восстановления для любой аварии — он зависит от объёма данных, оборудования и характера аварии.
- Восстановление с физически повреждённых носителей в лаборатории.
План подтверждается тестом, а не подписью
Целевые сроки становятся обязательством только в договоре
Узкие места называем, даже если их исправление стоит денег
Отсутствие потерь данных у клиентов на сопровождении за 2025 год — результат за период, а не обещание на будущее.
Разбор под капотом
Разбор: почему план без теста не работает
На тесте выясняются вещи, которых нет ни в одном документе: система резервного копирования делает копию, но не включает в неё нужную базу; восстановление упирается в скорость канала и занимает не два часа, а десять; для подъёма нужен пароль, который знал уволившийся администратор; лицензия привязана к железу, которого больше нет; приложение не стартует без домена, а домен восстанавливается последним. Всё это лучше узнать в спокойный вторник. Поэтому тест — не формальность, а главная часть работы: после него план либо подтверждается фактическим временем, либо переписывается, а узкие места превращаются в понятные задачи с ценой.
«Пока восстановление не пробовали, известно только одно: копии создаются. Это не то же самое, что возможность вернуться к работе»
Само резервное копирование — состав, расписание и хранение — вынесено на отдельную страницу услуги.
Перейти к связанной услугеКто участвует
Инженер по резервному копированию отвечает за копии, тест и фактические замеры.
Архитектор инфраструктуры разбирает зависимости и порядок подъёма. Со стороны компании нужен человек, который может назвать критичные функции и допустимые потери, — это решение бизнеса, а не ИТ. Работы ведёт собственная команда: 20 штатных инженеров, без фриланса и ИТ-субподряда.
Инженер по резервному копированию
Отвечает за копии, проведение теста и фактические замеры времени восстановления.
Архитектор инфраструктуры
Разбирает зависимости, порядок подъёма систем и требования к запасным ресурсам.
Профильные инженеры
Подключаются к 1С, базам данных и почте — там, где восстановление имеет свою специфику.
Руководитель сервиса
Согласует окна теста, участников со стороны компании и приёмку результата.
«Единственный способ узнать время восстановления — восстановить. Всё остальное — оценка на глаз»
Стоимость
От чего зависит цена восстановления данных
Стоимость и объём проекта согласуем до начала работ. Ежемесячной платы за сам проект нет. На цену влияют число критичных сервисов и их зависимостей, объём данных, площадка и глубина теста, необходимость регулярного повтора. Подготовим предварительное предложение в течение 48 часов после того, как получим достаточно данных о вашей ИТ-инфраструктуре и задачах.
Как считаем стоимость
Стоимость считаем после разговора о критичных сервисахСтоимость и границы проекта согласуем до начала работ. В цену входят план и тест в согласованном объёме. Регулярный повтор теста оформляем как отдельное сопровождение с ежемесячным платежом.
Материалы о восстановлении данных
Статья с вопросами администратору поможет собрать сведения о системах, копиях и зависимостях до начала работы.
Связанные материалы блога
Вопросы о восстановлении и плане на случай аварии
Собрали частые вопросы про копирование и восстановление: что поднимается в первую очередь, какие зависимости критичны, как согласуются допустимые потери и сроки, что входит в порядок действий, как проходит тест и каких сроков нельзя обещать заранее.
Что восстанавливается в первую очередь?
То, без чего компания теряет деньги и нарушает обязательства: обычно учётная система, почта, файлы отдела продаж, склад или касса. Порядок определяет бизнес, а не техника: мы задаём вопрос «что произойдёт через час, день и неделю без этого сервиса» и выстраиваем очередь по ответам.
Какие зависимости критичны?
Домен и учётные записи, сеть и адресация, база данных под приложением, лицензии, привязанные к оборудованию, внешние сервисы и обмены. Часто именно они, а не сами данные, определяют, сколько займёт подъём: приложение не стартует, пока не поднят домен, а домен восстанавливают в последнюю очередь.
Как согласуются допустимая потеря данных и срок возврата?
Такие пороги устанавливает бизнес. Мы задаём два вопроса по каждому сервису: сколько работы можно потерять — час, день, неделю — и сколько времени компания выдержит без него. Из ответов складываются требования к копиям и к схеме восстановления. Дальше проверяем, достижимо ли это на текущей инфраструктуре, и, если нет, называем цену разрыва.
Что входит в порядок действий?
Кто принимает решение о начале восстановления, кто выполняет работы, где взять копии, доступы и лицензии, в каком порядке поднимаются системы, как проверяется результат, кого и когда предупреждают — сотрудников, клиентов, руководство. Всё это в письменном виде и доступно не только одному человеку.
Как проходит тест?
На согласованных системах и в согласованное окно — обычно на отдельной площадке, чтобы не задеть рабочую. Поднимаем сервис из копии, проверяем, что он работает и данные на месте, засекаем фактическое время. Всё, что пошло не так, записываем: обычно на первом тесте находится минимум одна неприятная неожиданность. По итогам план правится.
Каких сроков нельзя обещать заранее?
Универсальных. Время восстановления зависит от объёма данных, скорости хранилища и канала, наличия запасного оборудования и того, что именно случилось: отказ одного сервера и шифровальщик по всей сети — разные истории. Мы называем срок только после теста и с условиями, при которых он верен.
Восстанавливаются ли данные с вышедшего из строя диска?
Нет, это работа специализированных лабораторий. Наша задача — сделать так, чтобы такая необходимость не возникала: рабочая схема копирования, изолированные копии и проверенное восстановление. Если носитель уже повреждён, а копий нет, честнее сразу отправить в лабораторию, чем экспериментировать.
Как часто повторять тест?
Не реже раза в год и обязательно после существенных изменений: новых систем, переезда, смены схемы копирования. Инфраструктура меняется быстрее документов, и план, не проверявшийся два года, обычно уже неверен. Регулярный повтор можно включить в договор сопровождения.
От чего зависят срок и цена?
На срок и цену влияют число критичных сервисов и их зависимостей, объём данных, площадка и глубина теста, необходимость регулярного повтора. Стоимость и объём проекта согласуем до начала работ. Подготовим предварительное предложение в течение 48 часов после того, как получим достаточно данных о вашей ИТ-инфраструктуре и задачах.
Смежные услуги направления
План опирается на работающее резервное копирование, наблюдение за системами и записанные сроки реакции — без них он остаётся бумагой.
Посчитаем, за сколько вернётся критичный сервис
Опишите критичную систему, допустимую потерю данных, желаемый срок возврата и известные зависимости. Скажем, что реально достижимо.