Практические шаги по созданию системы резервного копирования

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

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

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

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

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

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

Перефразируя поговорку, все люди делятся на тех, кто еще не делает бекап, и на тех, кто его уже делает. Иначе говоря, решение по резервному копированию жизненно необходимо — надеюсь, с этим никто спорить не будет. Как же выбрать подходящую систему резервного копирования (СРК), максимально отвечающую вашим потребностям? Вендоры заманивают красивыми рекламными лозунгами. Безусловно, каждый производитель по-своему хорош, у каждого есть свои передовые разработки, однако используемые ими собственные системы метрик затрудняют сравнение их продуктов с конкурирующими.

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

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

Получается, что выбор вендора СРК, которого посоветовал знакомый CIO, коллега или интегратор, проводивший обследование, не является оптимальным? Вариант же заказа проектирования у двух или трех независимых интеграторов для получения несколько решений от разных производителей не стоит даже рассматривать, так как после таких обследований денег на внедрение уже не останется.

Разброс по сценариям резервного копирования

КАК САМОСТОЯТЕЛЬНО ПРОВЕСТИ ОБСЛЕДОВАНИЕ И ВЫБРАТЬ ВЕНДОРА СРК

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

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

Таблица 1. Классификация сервисов компании

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

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

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

Таблица 2. График резервного копирования

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

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

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

А НУЖНА ЛИ СРК? КАКИЕ РИСКИ ОНА ПРЕДОТВРАЩАЕТ?

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

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

Таким образом, в реестр добавляем информацию об объеме и характере защищаемых данных (виртуальные машины, серверы Windows, базы данных SQL, почтовый сервер и т. д.), скорости сетевых подключений и их доступности (см. табл. 3).

Таблица 3. Источники защищаемых данных

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

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

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

МЕТОДИКА КОПИРОВАНИЯ ДАННЫХ

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

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

Таким образом, на данном этапе у вас будет создан реестр всех сервисов компании, произведена их классификация по требованиям со стороны бизнеса и составлено представление о целевой архитектуре системы. Этот реестр можно считать техническими требованиями к СРК, причем, как вы, вероятно, догадались, в них уже включена информация об RPO и RTO, объеме и характеристиках защищаемых данных, окнах резервирования и топологии системы (см. табл. 4). Фактически, если вы сделали оценочный анализ различных решений, о чем говорилось выше, у вас будет заготовлено несколько альтернативных сценариев реализации проекта СРК, не зависящих от аппаратного и программного обеспечения.

Таблица 4. Технические требования к СРК

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

Если вы считаете, что сделали уже достаточно, берите свои требования и отправляйте на оценку в отделы подготовки продаж различных вендоров или интеграторов. Многие компании готовы бороться за потенциального покупателя, обеспечивают достаточную финансовую поддержку офисам предпродаж и могут бесплатно выполнить расчет. Любой заказчик, относящийся к корпоративному сегменту (Enterprise), может смело обращаться к лидерам из квадранта Gartner и запрашивать предварительную оценку стоимости сценариев СРК. Для небольших компаний, вероятно, не потребуется дополнительного аппаратного обеспечения и подойдет свободно распространяемое ПО, имеющее достаточно долгую историю эксплуатации и позитивные отклики.

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

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

Таблица 5. Выбор сценария и решения СРК

ПОСЛЕСЛОВИЕ

При обследовании нужно уделить внимание вопросам связи СРК с другими системами, например системами мониторинга, а также спрогнозировать рост объемов резервного копирования, потребность в масштабируемости системы и предусмотреть меры безопасности при организации хранения данных. Не забудьте раз в год выполнять аудит копируемых данных на соответствие требованиям бизнеса.

Сергей Чекмасов — начальник службы эксплуатации программно-аппаратного комплекса Карельского РДУ, филиала ОАО «СО ЕЭС». С ним можно связаться через: http://www.linkedin.com/in/chekmasoff.