Разумные подходы к защите и восстановлению данных

Главными атрибутами оценки эффективности решений для защиты и восстановления данных являются окно резервного копирования, целевая точка восстановления (Recovery Point Objective, RPO) и целевое время восстановления (Recovery Time Objective, RTO). Эти параметры характеризуют время, выделяемое для операций резервного копирования, интервал между двумя такими операциями и продолжительность процедуры восстановления, выполняемой в случае ошибки, сбоя или аварии.

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

По оценкам Эндрю Лернера, вице-президента аналитической компании Gartner по исследованиям, средняя стоимость простоя в различных отраслях составляет 5600 долларов в минуту, или более 300 тыс. долларов в час. Недоступность критически важных данных обходится крупным организациям в миллионы долларов в час.

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

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

• каждому конкретному набору данных, в зависимости от его ценности для организации, предоставлялись минимальные уровни сервиса (окно резервного копирования, RPO, RTO), абсолютно необходимые для ведения бизнеса;
• организация несла минимально возможные затраты.

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

В этой статье мы изучим скрытые затраты и взаимосвязь затрат и политик при выборе современных вариантов защиты и восстановления данных.

КАКОВА СТОИМОСТЬ ОКНА РЕЗЕРВНОГО КОПИРОВАНИЯ?

В условиях увеличения числа серверов, систем хранения, сетевых платформ и приложений, а также территориально распределенного размещения ресурсов ИТ-инфраструктура становится очень сложной. Развитие технологий в сочетании с ежегодным ростом объемов данных на 40–50% и еще более жесткими требованиями к уровню сервиса со стороны заинтересованных лиц чрезвычайно осложнило задачу защиты данных. На рис. 1 показаны возможные ситуации, которые необходимо учитывать при составлении плана защиты и восстановления данных.

Рис. 1. Администраторы резервного копирования сталкиваются с массой инфраструктурных сложностей

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

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

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

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

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

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

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

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

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

С помощью предлагаемых Hitachi решений окно резервного копирования можно минимизировать или даже исключить. Такие результаты достигаются за счет полностью интегрированных технологий непрерывной защиты данных (Continuous Data Protection, CDP) на уровне блоков и согласованных с приложениями моментальных снимков, которые делаются с помощью специальных аппаратных средств. В результате устраняется необходимость сканирования файловой системы для поиска инкрементных изменений и сокращается продолжительность копирования данных — до нескольких секунд.

ПОСТОЯННОЕ ИНКРЕМЕНТНОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ

Средства создания моментальных снимков и CDP обрабатывают только новые и измененные данные. Использование инкрементной модели на постоянной основе исключает потребность в периодическом полном резервном копировании (или синтетическом полном резервном копировании), присущую большинству других решений. В зависимости от скорости изменения данных и продолжительности их хранения такой подход позволяет уменьшить объем хранимых резервных копий более чем на 90%.

Предположим, обычное предприятие, работает пять дней в неделю и 50 недель в году. Им накоплено 100 Тбайт данных, средняя скорость изменения которых составляет 10% (10 Тбайт) в день и 50% (50 Тбайт) в неделю. Резервные копии для оперативного восстановления хранятся 12 недель, а данные, требующие более длительного хранения, архивируются.

Это крайний случай, который иллюстрирует отличия традиционной и постоянной инкрементной модели. В типичной среде общий объем измененных данных обычно составляет 50% в год (50 Тбайт), что эквивалентно 1% в неделю (1 Тбайт) и 0,2% в день (200 Гбайт).

При комбинации полного и инкрементного резервного копирования, а также в используемой Hitachi Data Instance Director (HDID) модели постоянного инкрементного копирования объем ежедневной копии составляет 10 Тбайт (см. рис. 2). Однако, в первом случае в выходные резервируются 100 Тбайт, тогда как во втором никаких копий не создается.

Рис. 2. Отличия традиционной модели от модели постоянного инкрементного резервного копирования

С учетом создания первоначальной полной резервной копии (100 Тбайт) общий объем резервных копий за 12 недель составит:

• полное и инкрементное резервное копирование: 1900 Тбайт (1,9 Пбайт);
• постоянное инкрементное резервное копирование: 700 Тбайт (0,7 Пбайт).

Благодаря дедупликации данных постоянное инкрементное резервное копирование позволяет сократить требуемую емкость хранения на 63% без дополнительных финансовых затрат и снижения производительности системы. Во сколько обойдутся приобретение, управление и поддержка хранилища с резервными копиями объемом 1,2 Пбайт? По сути, это 2,4 Пбайт дополнительного пространства, так как мы хотим реплицировать хранилище с резервными копиями в центр послеаварийного восстановления. Если данные с копиями хранятся дольше трех месяцев, экономия окажется еще больше.

В типичной же среде, где за год меняется 50% данных, для хранения традиционных резервных копий в течение 12 недель понадобится 1,3 Пбайт, а для хранения постоянных инкрементных копий — всего 112 Тбайт. Таким образом, экономия достигнет 91%. Приведенное уменьшение объемов еще раз подтверждает, что при традиционном резервном копировании почти все сохраняемые данные избыточны.

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

КАК RPO ВЛИЯЕТ НА RTO?

Целевая точка восстановления (RPO) указывает на приемлемую для предприятия периодичность создания резервных копий и, таким образом, определяет момент времени, в который возможно восстановление данных. Если RPO равняется 24 ч, значит, одной операции резервного копирования в день вполне достаточно. Кроме того, данный показатель характеризует:

• частоту выполнения операций резервного копирования;
• объем новых данных, которые предприятие рискует потерять.

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

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

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

Рис. 3. Как сбалансировать RPO и RTO?

Представим, что у вас очень большая база данных, резервную копию которой можно создать только за длинные выходные. Чтобы уменьшить RPO до 24 ч, каждую ночь необходимо делать резервные копии журналов базы данных или журналов повторного выполнения. В результате можно восстановить последнюю полную копию базы данных, а затем повторно выполнить все транзакции, сохраненные в журналах базы данных или журналах повторного выполнения.

Число и размеры файлов, которые требуется восстановить и использовать наряду с файлами базы данных, могут расти очень быстро, особенно если вы имеете дело с масштабной кластерной средой наподобие Oracle Real Application Clusters (RAC). Итак, будет ли время, затрачиваемое на восстановление последней полной резервной копии и всех журналов, соответствовать отведенному для крупной системы баз данных RTO? Ответ, очевидно, отрицательный, если только RTO не измеряется неделями и месяцами. Такая методология защиты базы данных может быть использована для создания приемлемых целевых точек восстановления, но она не подходит для соблюдения приемлемого целевого времени восстановления.

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

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

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

• Моментальные снимки и технологии репликации на базе хранилища, которые:

— исключают из системы управления базами данных операции по защите данных;

— устраняют необходимость в окне резервного копирования и связанные с ним простои;

— позволяют выполнять операции резервного копирования гораздо чаще, сокращая объемы новых данных, подверженные риску потери, на 90% и более.

• Моментальные снимки и программное обеспечение репликации для приложений и баз данных, которые:

— переводят базы данных и приложения в готовое к резервному копированию (отключенное) состояние;

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

— обеспечивают быстрое и полностью согласованное восстановление операционной деятельности в течение нескольких минут, а не недель;

• Сервисы оценки и внедрения, которые определяют и конфигурируют оптимальное решение для уникальной среды предприятия.

RPO — ВОЗМОЖНАЯ СКРЫТАЯ СТОИМОСТЬ RTO

Что относится к RTO? В зависимости от конкретного определения сюда могут войти некоторые или даже все из следующих составляющих:

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

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

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

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

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

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

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

РЕШЕНИЕ ОЧЕВИДНО

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

• значительно уменьшить окно резервного копирования, которое ограничивает частоту операций копирования (RPO);
• существенно увеличить частоту операций копирования, чтобы как можно меньше данных подвергалось риску потери, после которой их приходится вводить заново;
• ускорить выполнение операций восстановления — как локальных (восстановление операционной деятельности), так и удаленных (послеаварийное восстановление).

А для этого надо выбирать правильные решения.

Рич Вайнинг, cтарший менеджер по маркетингу продуктов