Сегодня практически невозможно добиться устойчивости бизнеса, не обеспечив резервного копирования и восстановления данных, соответствующих его реальным потребностям, поскольку грамотно выстроенное управление этими процессами позволяет не только существенно снижать риски потери данных, но и обеспечивать приемлемое время восстановления после сбоев ИТ-систем и опирающихся на них бизнес-процессов. Но как определить, какие характеристики резервного копирования и восстановления приемлемы для бизнеса? И как выстроить эти процессы, чтобы они выполнялись эффективно и по возможности с небольшими затратами?
«И потери бизнеса от сбоев, и расходы на организацию резервного копирования и восстановления можно подсчитать в деньгах. Зная эти величины, гораздо легче определить и приемлемое время восстановления, и прочие характеристики», — считает Антон Левиков, ИТ-директор ГК «Новард».
Приступая к выстраиванию эффективных процессов резервного копирования и восстановления данных, Левиков рекомендует в первую очередь определить владельца данных — того, кому эти данные нужны для работы, и назначить из числа сотрудников ИТ-департамента ответственного за их хранение, восстановление и доступ к ним. Следующим шагом должно стать достижение договоренности между владельцем данных и ответственным об уровне обслуживания. В рамках этой договоренности нужно определить нормативы времени восстановления и сроков безвозвратной потери изменений, соответствующие ценности информации для бизнес-процессов и операций, в которых она используется. Будет правильно зафиксировать эту договоренность в виде отдельного регламента или внутри общего регламента, включив в эти документы и способы предоставления владельцу данных отчетности о соблюдении договоренностей, и санкции за их несоблюдение.
По мнению Алексея Панкратова, технического консультанта компании Symantec, для организации резервного копирования данных на предприятии необходимо прежде всего определить те системы и хранилища, которые требуется защищать, а также требования ко времени резервного копирования и восстановления: «Нужно выяснить, что требуется защищать в случае аварии — все данные на сервере или только те, что относятся к важным подсистемам (например, базы данных)».
«Начинать следует с классификации данных и выработки основных показателей их резервного копирования и восстановления. Результатом может являться многостраничный документ для крупной организации с множеством приложений либо один листок с коротким списком вида «почта, «1C», файловый сервер» и пр. Зафиксированные в этом документе показатели должны пройти утверждение в структурах бизнеса. После этого можно начать обсуждать способы достижения таких показателей, — отмечает Павел Карнаух, технический директор направления систем резервного копирования и восстановления данных компании EMC в России и СНГ. — К сожалению, администраторы приложений или, например, администраторы виртуальной инфраструктуры нередко начинают самостоятельно строить системы защиты, зачастую с использованием различных аппаратно-программных средств и без учета централизованной политики защиты данных. В идеальном случае за планирование и реализацию регламентов должна отвечать выделенная группа системных администраторов при поддержке «владельцев» приложений».
Валерий Рыбин, системный архитектор отдела ЦОД компании «Открытые Технологии», уверен что поскольку деятельность практически любой организации зависит от прикладных систем, то для начала необходимо определиться со степенью их критичности для бизнеса и оценить, сколько информации допустимо потерять в результате аварии и каким должно быть среднее время восстановления системы.
«Самым важным элементом системы резервного копирования являются четкие регламенты резервирования и восстановления информации, разработанные для каждого типа критичности систем. В этих документах должно быть зафиксировано, как, когда, куда и что мы резервируем или восстанавливаем», — добавляет Рыбин. Составление и согласование таких регламентов — наиболее трудоемкий процесс, хотя он не так уж и сложен. Другим немаловажным политико-техническим процессом является классификация имеющегося в компании программного обеспечения по типам SLA — эта классификация очень помогает выбрать правильную архитектуру системы резервного копирования и подготовить для нее точные регламенты. Еще одним немаловажным процессом является проверка резервных копий на восстанавливаемость.
Защита копий от инсайдера
Известно немало примеров инсайдерских утечек, в которых фигурируют украденные ленты и диски резервного копирования. Чтобы предотвратить утечки конфиденциальной и персональной информации, разумно разграничить доступ к резервным копиям данных. Как это организовать?
Павел Карнаух рекомендует использовать комплекс организационных мер, включив в него регулярный аудит журналов восстановления, регламентацию доступа к физическим носителям резервных копий, отказ от их перевозки в пользу репликации данных. «Современные системы также дают возможность разграничить доступ администраторов к данным путем деления информационных систем на домены, — добавляет он. — В ряде случаев полезно шифровать данные».
Валерий Рыбин видит несколько путей для разграничения доступа к резервным копиям. Во-первых, можно разделить средства резервного копирования для разных систем или сегментов сети с различным уровнем конфиденциальности. В этом случае при грамотно внедренных организационных мерах и мерах физической безопасности резервных копий доступ к резервным данным получит только авторизованный персонал. Недостатком такого метода является его высокая стоимость, что вызвано фактическим дублированием средств резервного копирования. Второй путь — использование возможностей ПО резервного копирования для логического разнесения резервных копий по различным устройствам и разграничения доступа к ним. Правда, все равно остается администратор, имеющий доступ ко всем резервным копиям. Возникающие при этом угрозы ИБ должны быть компенсированы соответствующими организационными мерами. Средства шифрования информации при резервном копировании также можно использовать, но с оглядкой на ограничения, накладываемые российским законодательством.
Адекватное восстановление
«Есть своего рода правило: чем дольше копируем, тем быстрее восстанавливаем, — отмечает Панкратов. — Имея полную актуальную резервную копию данных на быстрых носителях, можно обеспечить наискорейшее восстановление за один этап. Если есть только старая полная копия вместе с набором инкрементальных копий на ленточных носителях, то восстановление займет значительное время и пройдет в несколько этапов (сначала восстанавливаем полную копию, а поверх уже по очереди все инкрементальные). При необходимости работы только с данными приложений время возобновления их функционирования после сбоев можно заметно сократить путем применения технологий гранулярного восстановления. К примеру, иногда достаточно восстановить не весь сервер Microsoft Exchange, а лишь данные одного почтового ящика или даже одного письма».
Правильно оценить, насколько выбранная архитектура и параметры системы резервного копирования и восстановления соответствуют реальным потребностям бизнеса, и убедиться в ее работоспособности позволят полномасштабные испытания, при которых эмулируются настоящие аварии с отказом как отдельного сервера, так и групп серверов, подчеркивает Рыбин: «Лишь такие непростые испытания могут доказать на практике, что ваша система резервного копирования реально работает. В результате этих испытаний вы сможете определить те сроки, которые необходимы для восстановления работоспособности вашего программного обеспечения».
«На практике бизнес обычно склонен переоценивать свои потребности в надежности хранения информации, — говорит Левиков. — Как правило, ключевой для бизнеса вопрос — работоспособность фронт-офиса, поскольку при взаимодействии с клиентом дороги каждая секунда и каждый байт. Потребности бизнеса в отношении восстановления данных бэк-офисных приложений могут быть и «помягче»».
Дешево или сердито?
Можно ли оптимизировать затраты на процедуры резервного копирования и восстановления с учетом оценки рисков и потребностей бизнеса в тех или иных данных? Да, можно — с помощью тщательного планирования, уверен Карнаух: «Нет необходимости обеспечивать избыточную защиту данных сверх того, что требует бизнес. Но и обратная ситуация недопустима. Правильная классификация данных и утвержденные показатели защиты дают ИТ-руководителю инструмент для мотивированного запроса финансирования. С другой стороны, и у бизнеса появляется возможность требовать выполнения формализованных SLA и адекватной отдачи от инвестиций».
Как отмечает Панкратов, в ходе оптимизации затрат на резервное копирование приходится, как правило, исходить из двух вариантов технологий: дорого, но быстро (диски SSD, SAS, fiber channel) или дешево, но медленно (ленты). В связи с этим нередко используется комбинация разных хранилищ: самые свежие копии хранятся на дисках и по мере устаревания перекладываются на ленты. Для значительного сокращения требуемых объемов хранимых данных также используется технология дедупликации, которая выделяет из данных только уникальные блоки и сохраняет именно их. Тем самым сокращаются объемы хранимых данных на 90% и более для данных виртуальных машин и на 40–60% для данных физических серверов (цифры могут очень сильно варьироваться в зависимости от характера и объема данных).
«Фактически утилизация места при использовании технологий дедупликации будет равна величине изменений, произошедших на сервере, — добавляет Рыбин. — Еще один положительный момент такого подхода — сокращение времени восстановления за счет того, что нет необходимости применять инкрементальные резервные копии».
Сократить объем обслуживаемого оборудования и повысить надежность в целом помогает виртуализация, считает Рыбин. Кроме того, виртуальную машину можно использовать в качестве резерва для основного сервера, работающего в условиях высокой нагрузки, а также для проверки восстанавливаемости резервной копии: некоторые продукты систем резервного копирования могут легко восстанавливать резервные копии физических машин на виртуальные, а виртуальных — на физические.
Как видим, эффективность и стоимость резервного копирования в значительной степени зависят от организованности этого процесса. Диалог с бизнесом помогает найти оптимальный вариант в отношении затрат и рисков. Четко выстроенные организационные меры помогают удерживать эти риски на приемлемом уровне.