Аварийное восстановление СРК: стратегии, план и кейс

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

Понимание стратегий аварийного восстановления

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

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

Существует несколько стратегий аварийного восстановления, которые, как правило, зависят от возможности используемой вами СРК. Но какие бы ни были её возможности, вы же не будете создавать резервную копию сервера системы резервного копирования в тот же самый домен резервного копирования? (дисклеймер: а мы будем😊, но вначале — матчасть). 

Для серверов резервного копирования применяются следующие стратегии:

1. Резервное копирование каталога и конфига сервера встроенным механизмом СРК в ПО СРК или в ПО БД, в котором крутится БД СРК в отдельную шару, на ленту или вторым доменом резервного копирования (это оптимальный вариант, если всё это есть на предприятии). Так можно делать с Netbackup, Commvault.

2. Кластеризация серверов. Этот вариант хорошо подходит для высоконагруженных систем, в которых круглосуточно, а не только в нерабочее время происходит резервное копирование без возможности восстановления основного сервера альтернативными вариантами. Во всех остальных случаях использовать этот подход не рекомендуется из-за сложности поддержки, развёртывания и обслуживания. Этот способ подходит для отечественных систем резервного копирования Кибербэкап и Рубэкап.

3. Использование виртуализации +SRM, сторонних инструментов репликации ВМ в DR-сайт, облачных технологий. Восстановление с помощью загрузочного диска из репозитория, в том числе и из облака. Этот способ рабочий для Veeam.

4. Восстановление сервера с помощью загрузочного диска восстановления и бэкапа всех данных в сетевую папку. Обычно это тоже оптимальный вариант, если нет механизмов защиты, описанных выше в п.1. Способ рабочий для Кибербэкапа.

Для серверов хранения при резервном копировании применяются стратегии со встроенными средствами ПО резервного копирования. Из-за большого объёма хранимой информации нет смысла резервировать все данные альтернативными способами, необходимо резервировать только самые важные, а это невозможно адекватно выполнить сторонними средствами. Вот эти стратегии. 

1. Резервное копирование на два устройства хранения. Применяется для важных данных. Этот способ универсален для всех СРК.

2. Репликация данных с одного сервера хранения на другой. Способ также универсален для всех СРК.

3. Бэкап на ленту; в случае аварии можно сделать инвентаризацию лент. Способ универсальный для тех, кто умеет работать с лентой и инвентаризировать её. Однако он долгий, поэтому практически не применяется, особенно там, где большой объём данных. Исключения могут составить архивные данные.

4. Репликация с одного сервера хранения и одного домена СРК в первом сайте на другой сервер хранения, в другой домен резервного копирования во втором сайте. Способ подходит для NetBackup, Veeam.

5. Разделение хранения данных и самого сервера хранения по причине большого объёма хранимых данных. В этом случае можно сделать резервную копию самого сервера агентом на файловой системе всех разделов либо резервную копию виртуальной машины сервера хранения. Данные при этом можно хранить на сетевой шаре, которую также защитить средствами репликации СХД либо NAS. Либо делать бекап этого луна на ленты, если СХД может работать своими средствами с лентой. Затем виртуальную машину с бэкапами можно восстановить с помощью загрузочного диска из шары или выполнить BMS на железный сервер с помощью загрузочного диска. Этот способ подходит для СРК Кибербэкап.

Ключевым моментом всего этого действа является предварительная подготовка плана аварийного восстановления способом, описанным в документе «План аварийного восстановления системы СРК», который желательно сделать доступным для общего пользования системных администраторов СРК. Такие меры хорошо помогают минимизировать потери данных и время вынужденного простоя системы. Очевидно, что можно обойтись и без такого плана, но для этого всем администраторам СРК необходимо наличие хорошего понимания угроз и опыт эффективной реализации стратегий аварийного восстановления. Можно ли достичь хороших результатов без документирования? Современный опыт говорит, что нельзя. 

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

Практические рекомендации по разработке плана аварийного восстановления главного сервера резервного копирования

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

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

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

Шаблон плана аварийного восстановления

1. Введение

Цель документа: определить процесс восстановления критических функций резервного копирования и минимизацию потерь времени в случае восстановления СРК предприятия в аварийной ситуации. 

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

2. Определение терминов

Инцидент: событие, нарушающее нормальную работу.
Риски: потенциальные угрозы, которые могут привести к инцидентам.

3. Ответственные лица

• Список критических процессов для постановки на мониторинг (тут можно описать модель здоровья СРК или её часть, отвечающую за определение того, что сервер (а) «упал»).

• Оценка максимально допустимого времени простоя (RTO) и допустимых потерь данных (RPO).

5. Анализ рисков

В зависимости от сценария, описать линию поведения для каждого из них. Например:

• Если упал сервер в ЦОД, то берём отсюда — новый сервер, отсюда —  бэкап и восстанавливаемся пошагово так-то.

• Если произошёл пожар, и сайт полностью неработоспособен в течение времени Х, то восстанавливаемся на другой сайт (а если время Y, то ждём отмашки для начала действий от руководителя рабочей группы по восстановлению «старой» инфраструктуры).

• И т. п.

6. Процедуры восстановления

Шаг 1: Уведомление ответственных лиц об инциденте.
Шаг 2: Оценка ситуации и определение уровня инцидента.
Шаг 3: Определение ресурсов и оборудования для восстановления. 

Шаг 4 Активация плана восстановления.
Шаг 5: Восстановление критических бизнес-процессов.
Шаг 6: Постановка на контроль и мониторинг восстановленных процессов.

7. Прочие ресурсы для восстановления

• Дополнительное оборудование и ПО для восстановления.

• Критически важные данные и резервные копии.

• Места для временного размещения сотрудников.

8. Связь и уведомления

• Процедуры уведомления сотрудников, клиентов и партнёров.

• Шаблоны сообщений для различных сценариев.

9. Документирование действий

• Запись всех действий, предпринятых в ответ на инцидент (например, краткий отчёт о начатых и проделанных работах в общий чат).

• Оценка времени восстановительных мер.

10. Обучение и тренировки

• Регулярное обучение сотрудников по вопросам аварийного восстановления.

• Проведение учебных тревог и симуляций.

11. Обновление плана

Регулярный обзор и обновление ППВ (например, 1 раз в год или по мере значительных изменений в инфраструктуре).

Этот шаблон можно видоизменять в зависимости от специфики бизнеса, масштабов организации и других факторов. Очень важно, чтобы план был доступен для всех заинтересованных сторон и при изменениях в системе СРК или переопределения списка угроз регулярно пересматривался!

Эффективные стратегии восстановления данных

Есть, однако, ещё один важный момент. Прежде чем выбрать эффективную стратегию для восстановления работоспособности СРК, нужно понять, а чем же определяется эффективность стратегии восстановления? 

Эффективность стратегии определяется следующими факторами:

1. Простота реализации и поддержки, а также возможность реализовать стратегию с учётом самого минимального RTO в системе. Например, если у вас каждые 5 минут круглосуточно идёт бэкап логов БД, то очевидно, что стратегия восстановления должна будет восстановить работоспособность сервера за 5 минут (переключить на вторую ноду кластера, но кластер сложнее развёртывать и поддерживать), чтобы не нарушить SLA. Однако если эти логи в редком случае смогут подождать ещё 20 минут до восстановления сервера, то стратегия может быть другой (простое восстановление с помощью загрузочного диска из файловой шары ).

2. Регулярные резервные копии сервера СРК с учётом особенностей системы. Особенно важно их делать после завершения окна всех бэкапов, если БД СРК хранится и функционирует на самом сервере управления, чтобы не потерять уже созданные бэкапы, которые при восстановлении не будут отображены в восстановленной базе СРК.

3. Наличие плана «аварийного восстановления СРК», чтобы администратор мог оперативно начать восстановление и не вспоминал IP-адреса и прочие подробности восстановления.

4. Наличие правильно настроенной системы мониторинга, чтобы не получилось так, что система СРК валяется уже час, а «мы вот только что заметили».

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

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

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

Реализация данной стратегии достигается за счёт наличия регулярных резервных копий главного сервера СРК на файловую шару  с помощью файлового агента. В случае аварии с помощью загрузочного диска системы Кибербэкап можно будет загрузиться с диска локально и при наличии сетевого доступа найти образ сервера СРК на файловой шаре (по названию образа, который называется так же, как имя клиента СРК), а затем запустить восстановление образа сервера с виртуальной или физической машины. Ниже — процесс восстановления работы управляющего сервера СРК Кибербэкап в рамках выбранной нами стратегии восстановления работоспособности сервера управления СРК с «нуля». Для реализации данной стратегии не нужно даже контроллера домена, если можно будет пройти авторизацию на шаре по локальной учётной записи, а поэтому для удобства назовём данную стратегию «быстрый минимум».

Стратегия предполагает следующие допущения:

• Наличие места на одном из хостов виртуализации в той же подсети, что и система СРК, чтобы была сетевая связность с клиентами СРК и шарой с резервными копиями, а в случае, если БД сервера управления расположена на сервере БД, то в сетевой связности и с ним.

• Быстрая сеть, время восстановления около 20 минут.

Пример восстановления работы главного сервера в аварийных ситуациях

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

Ниже я смоделирую аварийную ситуацию на современном предприятии высокого уровня зрелости (начиная от 4 и выше), чтобы наглядно показать, как работают все эти стратегии. «Все случайные совпадения, конечно же, не случайны ©».

Звонок среди ночи… Мозг еще не успел проснуться, а рука уже шарит по кровати в поисках мобильника. Куда же он запропастился, сволочь?! Все мы работаем по ночам при необходимости — это прописано в контракте, а поэтому спать приходится с мобильником где-то рядом.

— Алло! Дежурный беспокоит, у нас отказ СХД, который затронул часть инфраструктуры ЦОД и в том числе сервер управления резервного копирования.

— Какие прогнозы, дежурный? 

— СХД-шники уже работают над этим, но, похоже, это надолго. Они открывают кейс в вендоре, потому что подозревают проблемы с прошивкой. 

— Судя по тому, что ты мне звонишь, данные с СХД достать не получается и нужно восстановление из резервной копии?

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

— Спасибо, дежурный, принял. И доброй ночи! Хотя, какая она теперь добрая…

Дзынькает телефон. Похоже, закинули-таки в чат. Начинаю спросонья изучать, кто и что пишет. Мд-а-а… ситуация-то, похоже, плачевная — что и говорить, повезло, что вендор находится на другой стороне планеты и у них сейчас рабочий день. И индус ответил быстро, но… по первичным процедурам ничего сделать не удалось, и хотя кейс уже передали на 3 линию, вендор рекомендует сохранить все данные и откатить СХД на предыдущую версию прошивки. А это значит, что скорее всего данным на СХД полностью хана — всё это удалось узнать, бегло читая чат. 

— Коллеги-администраторы, какие сервера затронул сбой? — пишу я в чат. Мне необходим список с приоритетами, чтобы знать, с чего начинать восстановление.

— Коллеги-инфраструктурщики, куда восстанавливать? Дайте имя хоста и сторейджа! — пишу снова между строк с отчётами рабочей группы. —  Пришлите в личку или в почту, пожалуйста!

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

Быстро пишу в почту виртуальщикам и дублирую в личку, в чат, чтобы мне создали виртуальную машину с локальным диском 300 ГБ, 8 процессорами и 16 ГБ ОЗУ — таковы параметры упавшего сервера управления СРК.

Конечно, я тренировался, когда писал регламент «аварийного восстановления СРК», который сейчас скачал с корпоративного портала в разделе СРК, и процедура восстановления уже неоднократно отработана. Поэтому образ загрузочного диска для СРК лежит у меня дома на своем личном NAS. Когда ты — айтишник на большом предприятии, дома у тебя обычно много забавных штук. Ведь хочется работать с удобствами. А удобства утопающего, как мы знаем дело рук самого утопающего) – работаем-то мы из дома. Скачав регламент восстановления, скачав загрузочный диск СРК в версии для Linux (так как сервер управления был на Linux), получаю имя ВМ от виртуальщиков и доступ в веб-консоль VMware.

Логинюсь. Поиском нахожу нужную ВМ, просматриваю характеристики и в разделе настроек добавляю образ загрузочного диска СРК.

— Вот же блин! Виртуальщики сделали стандартную виртуалку и не добавили мне 300 ГБ. Помню, что благодаря регулярному обслуживанию и оптимально настроенным стратегиям резервного копирования, БД-сервера и сам сервер весит меньше, так что скорее всего, впритык я уложусь и в этот обьём. Потом можно будет расширить диск прямо «на горячую». Я ведь уже всё сделал, и пока я буду обращаться к виртуальщикам в этом цейтноте с просьбой расширить диск, ВМ успеет уже восстановиться. При скорости сети 10 ГБИТ, ВМ восстанавливается буквально за 5 минут. Так что я ничего не теряю, а наоборот, если запущу восстановление прямо сейчас, то сэкономлю время. Тем более, что я уже запустил саму ВМ и загрузилось приглашение:

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

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

Закрываю и далее выбираю «восстановить»:

Затем «выбор данных»:  

 

Затем «путь к данным» и обзор. Там ввести путь к шаре:

Далее ввожу логин и пароль от шары и жму ОК.

В открывшемся окне появился список доступных для восстановления образов.

Выбираю нужный образ и устанавливаю все галочки в таблице «ТОМ» (в этой таблице показаны все разделы, которые были найдены в ВМ, и если отметить их, то отмеченные будут восстановлены) и нажимаю ОК:

Сразу обращаю внимание, что данная ВМ содержит «LVM», а это значит, что для успешного завершения восстановления надо выполнить два условия: 

1. Образ резервной копии должен быть сделан агентом на ФС, а не виртуальным агентом.

2. Перед восстановлением к ВМ нужно применить конфигурацию «LVM», нажав на соответствующий пункт в консоли:

Затем нажимаю «да», и жду применения настроек.

После применения настроек консоль выглядит вот так:

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

Далее нажимаю ОК и процесс пошел:

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

После перезагрузки загружается сервер СРК:

Ура! Захожу под локальной учётной записью и проверяю, правильный ли IP-адрес имеет сервер. Все отлично! Расширяю диск, проверяю свободное место.

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

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

Запускаю сервер СРК, захожу в консоль и сверяю политики в консоли с регламентом. 

Всё отлично, всё на месте!

Устраиваюсь поудобнее в кресле, начинаю восстанавливать ВМ в порядке приоритета. Ночка сегодня обещает быть жаркой, поэтому работаем быстро. Отдохнём потом.  Утром должны дать отгул… Утром будем спать, а сейчас —  Погнали!

На этом заканчиваю. Всем желаю спокойных ночей и трудовых побед, коллеги! Задавайте ваши вопросы в комментариях, пожалуйста.