Восстановление данных после сбоя
Первая стадия планирования: Составление предварительного анализа рисков
Планирование восстановления данных после сбоя превратилось в боевой клич во многих организациях в результате значительных природных катаклизмов, катастроф, произошедших по вине человека, а также все более строгих правил и законов, предписывающих защищать и сохранять данные - самый незаменимый актив компании, уступающий место, пожалуй, только квалифицированному персоналу.
В данной статье с практической точки зрения будет представлено всестороннее описание компонентов планирования восстановления данных. Для тех, кто ранее не работал над планированием проекта, данный материал поможет развеять мифы и сфокусироваться на том, что необходимо сделать для разработки эффективных возможностей восстановления.
Методологии планирования восстановления данных зачастую считаются "брэндом" тех или иных консалтинговых компаний и представляются неким сложным и извилистым процессом, известным только нескольким привилегированным практикам. Однако, на самом деле, методология планирования восстановления данных - это простое применение здравого смысла, за которым следует прагматический план проекта, подобный методологии разработки жизненного цикла систем.
Как показано на диаграмме, первоначальный проект планирования восстановления данных включает в себя 10 задач, которые можно разделить на три подмножества или стадии. Первую стадию можно назвать "анализ". Как проиллюстрировано на следующей диаграмме и описано ниже, задачи данной стадии включают: начало проекта, сбор данных и составление предварительного анализа рисков. Последующие стадии - это "постановка задач" - создаются возможности для действительного восстановления данных после сбоя, и "выполнение" - осуществляется выбор стратегий для восстановления данных и их тестирование, тесты обеспечивают обратную связь для улучшения плана восстановления данных. Рассмотрим первую стадию планирования.
Проект планирования восстановления данных обычно начинается с непосредственной его инициации. Это широкое понятие включает в себя сбор команды для проекта (можно включить в нее собственных и привлеченных со стороны экспертов по данной тематике), а также формуливку целей плана, бюджета и иные вопросы. Сразу необходимо обратить внимание на стандартизацию инструментов программного обеспечения, которые будут использовать члены команды для сбора и компонования данных. Множество шаблонов для восстановления данных доступно в печатном формате или в виде программного обеспечения, их можно использовать для стандартизации сбора данных. Но и такие обычные программные средства как электронная почта, обработка текста и электронные таблицы, либо управляемые элементы базы данных отлично работают. Основная задача - добиться того, чтобы все члены команды подавали документы в одном и том же формате, что облегчит последующее объединение и анализ данных.
Сбор данных, следующая задача, включает в себя сбор информации о внутренних приложениях и инфраструктуре, а также сбор информации о рисках и подверженности внешним возействиям, полученной их различных медиа источников. Кроме того, в рамках данной задачи осуществляется сбор информации об избежании сбоев в работе и методах восстановления данных, используемых другими компаниями. Данные распределяются по категориям и собираются в "информационном складе" или центральном справочном репозитарии, в котором сотрудники, работающие над последующими стадиями планирования, могут легко найти нужную информацию.
Задача сбора данных нацелена на определение бизнес процессов, а также приложений и инфраструктуры, используемой для их поддержки. Также необходимо собрать информацию о том, сколько будет стоить компании простой системы, влияющий на все бизнес процессы, через 24, 48 и 72 часа соответственно. Поговорите с менеджерами отделов или бизнес подразделений, чтобы получить информацию о потерях, как в денежном эквиваленте, так и в виде нематериальных затрат (потеря доверия потребителей и прочее).
Следующая задача - анализ рисков. Анализ рисков включает в себя назначение приоритетов для восстановления данных среди бизнес процессов, а также приложений и инфраструктуры, используемой для их поддержки. Частично, это попытка предсказать потери компании от перерыва в работе приложений. На основе таких факторов, как начисленные денежные потери от сбоя, данная оценка назначается для кажого бизнес процесса, а также связанных с ним приложений и инфраструктуры.
Сценарий "выявления потерь", направляющий разработку плана, также формулируется в рамках данной задачи. Идеальным решением было бы выбрать для плана сценарий полной потери основного оборудования, объединив денежные потери с нематериальными, и просчитав издержки, понесенные после 24, 48 и 72 часов после катастрофы. Это создает весьма убедительную картину при обсуждении финансирования плана, что важно, если учесть, что впоследствии менеджеры могут сократить планируемый бюджет. В конечном счете, создаваемый вами план должен отвечать наихудшему сценарию, но он также должен обладать модульной структурой, чтобы гибко реагировать на менее серьезные случаи сбоев.
По окончании первой стадии, планировщики обращаются к самым азам плана - стратегиям по построению отказоустойчивости и избежанию сбоев в существующих средах, а также логистике восстановления данных, приложений, сетей и рабочих сред конечных пользователей в случае сбоя. Философия, лежащая в основе построения стратегий, проста - "устранить те возможности возникновения сбоя, которые можно устранить и минимизировать влияние тех возможностей возникновения сбоя, устранить которые нельзя".
Восстановление данных после сбоя. Вторая стадия планирования: Постановка задач
Большинство задач этой фазы (см. диаграмму ниже) включают в себя разработку стратегий и логистики восстановления после сбоя инфраструктуры и данных, необходимых для критически важных приложений. Каждая из задач требует рассмотрения множества альтернативных вариантов, что помогает построить наиболее эффективную стратегию в рамках ограничений бюджета.
В случае, если стратегия предполагает значительные затраты, вероятно вам придется оправдать эту стоимость перед вышестоящим руководством. Поэтому, по возможности, ищите такие стратегии, которые обеспечивают двустороннюю выгоду: стратегии, которые не только решают вопросы по восстановлению после катастроф, но и приносят пользу для повседневной деятельности компании.
Например, консолидация хранилищ в сеть Fibre Channel (fabric) для совместного использования ленточной библиотеки обеспечивает улучшенную защиту данных по сравнению с существующей системой. Однако это дорогое приобретение. Изучите какую дополнительную выгоду можно извлечь из этой новой топологии, например консолидация серверов и снижение затрат на покупку лицензионного программного обеспечения, либо продление срока службы существующих ленточных устройств и т.д. Чем сильнее ваше бизнес предложение, тем больше вероятность получить одобрение на финансирование плана от руководства.
Зачастую люди задаются вопросом - какую из поставленных задач считать наиболее приоритетной при условии, что план восстановления данных зависит от ограничений бюджета. Ответ на этот вопрос двоякий: выбор систем, позволяющих избежать катастрофы и разработка стратегий восстановления данных.
Задача выбора систем по избежанию катастроф фокусируется на разработке технологий, помогающих определить условия или события, которые могут привести к катастрофе и последующей их нейтрализации. Системы по избежанию катастроф (включая программное обеспечение по управлению, контроль безопасности, датчики пожарной сигнализации и т.д.) не только помогают предотвратить сбои, но могут также спасти жизнь персоналу компании.
Планирование восстановления данных - еще одна важнейшая задача. В отличие от сетей, систем и рабочих пространств пользователей, которые используют стратегии на основе избыточности или замены, защита данных ограничена только одной стратегией - избыточностью. Чтобы защитить информацию от потери или разрушения, данные необходимо дублировать.
Способ дублирования данных обычно находится в спектре между резервированием диск-лента и миррорингом диск-диск. В этот спектр попадает все возрастающее число вариантов выбора, представленных отраслью хранения данных в качестве комплексов решений. Диаграмма, представленная ниже, демонстрирует спектр современных решений по защите данных. Решения организованы по целевому критерию (время-на-резервирование против времени-на-восстановление).
В данном многообразии решений отражается весь спектр продуктов, представленных отраслью хранения данных и отвечающих на проблемы времени и стоимости защиты данных.
Существует множество характеристик программных продуктов, предназначенных для снижения времени на резервное копирование, к ним можно отнести поддержку добавочного резервного копирования, "горячее" резервное копирование, inode snapshots, и средства резервирования диск-диск, имитирующие ленту. Однако существуют и другие технологии, предназначенные для снижения стоимости зеркалирования данных с диска на диск. В качестве примера можно привести дублирование диск-диск, факторинг от Avamar: многоцелевое и сетевое кэширование, основанное на программном и аппаратном обеспечении
Таким образом можно говорить о множестве альтернатив, удовлетворяющих многим средам и бюджетам, а также о множестве вариантов выбора при планировании.
Насколько важен факторинг (разложение на составляющие) в защите данных при планировании восстановления данных? При планировании восттановления вам придется достаточно часто сталкиваться с показателем "время-к-даным". Этот показатель определяет период времени после катастрофы, необходимый для восстановления доступа к данным, используемым критически важными приложениями. Время-деньги, и время-данные является синонимом издержек восстановления после сбоя.
Если компания обладает лишь ограниченными финансовыми ресурсами для планирования восстановления данных, средства лучше потратить на комбинацию решений по избежанию катастроф и защите данных.
Однако, не стоит минимизировать важность планирования для восстановления приложений (и хост платформ), сетей и данных конечных пользователей. Чем больше способов защиты вы можете спланировать заранее для этих важных направлений восстановления данных, тем лучше.
Однако, как убедились во многих компаниях, даже если тщательно разработанные схемы восстановления сетей, систем и рабочих пространств пользователей падают жертвой незапланированных событий или сбоев, восстановление этих элементов можно провести достаточно быстро. Но данные невозможно заменить, если они не были заранее продублированы.
После того, как все стратегии были сформулированы и задокументированы, наступает последняя - третья - стадия проекта планирования, она включает в себя:
- Создание команд по восстановлению и их обучение;
- Тестирование плана;
- Реализацию процесса управления изменениями.
Восстановление данных после сбоя. Третья стадия планирования: Выполнение
На данный момент львиная доля работы по определению требований и стратегий для восстановления данных завершена. Уже, возможно, подписаны контракты с поставщиком, либо экипирован необходимым компьютерным и сетевым оборудованием и хранилищами собственный центр резервных данных и рабочее пространство пользователей, что поможет обеспечить правильное выключение систем. И, что еще более важно, важные данные компании продублированы и проверены.
Однако, несмотря на всю сделанную тяжелую работу, задачи, которые еще предстоит выполнить, - одни из наиболее важных в проекте планирования. С одной стороны, они гарантируют, что план будет активирован и выполнен тогда, когда это необходимо. С другой, они обеспечивают постоянное улучшение плана и синхронизацию возможностей восстановления данных с требованиями компании.
Стадия выполнения включает составление документации для плана, или, по крайней мере, блок схемы процесса принятия решений, которые покажут бизнес- или техническому менеджеру все необходимые шаги, которые необходимо мгновенно предпринять в случае аварии или критического положения. Выбросьте из головы идею, что где-то существует пригодный шаблон плана, по образу которого можно смоделировать свой собственный. Каждый хороший план уникален. Наилучший план - лаконичный и обеспечивающий гораздо менее детальные описания задач, чем вы предполагаете. Это потому, что в случае критической ситуации, к плану, составленному на бумаге практически никогда не обращаются. Более того, план - это не сценарий восстановления данных после аварии, потому что аварии, как правило, сложнее и непредсказуемее, чем вы полагаете при написании плана.
Тогда зачем вообще усложнять себе жизнь написанием плана на бумаге или составлением электронного плана? Хороший вопрос, ответом на который служит следующее: план, который вы написали, служит в меньшей степени сценарием для восстановления данных и в большей степени учебным пособием и руководством для тестирования.
После разработки возможностей восстановления данных, следует тщательно задокументировать что должно произойти, когда вам необходимо оповестить всех тех, кто будет принимать участие в восстановлении данных, об их ролях и обязанностях. Не существует никаких указаний насчет того, сколько должно быть команд и сколько человек должно входить в каждую из них. Здравый смысл - лучшее руководство в данном случае. Хороший вариант - спросить менеджеров отделов или бизнес подразделений кого, по их мнению, необходимо привлечь к работе по восстановлению данных: выбрать ответственное лицо и дублера. IT отдел обязательно должен выбрать значительное число сотрудников.
Обучение состоит из представления стратегий и процедур. Обучайте команды тому, что им необходимо делать в случае аварии, однако необходимо также тщательно описать обстановку, чтобы члены команды понимали, как на их работу будет влиять и как их работа повлияет на работу других команд. Внимательно выслушивайте замечания, так как они помогут вам определить те требования, на которые вы возможно не обратили внимания.
Команды также участвуют в тестировании, что является таким же учебным упражнением, как и репетиция активации плана. Существует множество способов тестирования и по этой теме консультантами по планированию восстановления данных написано огромное количество книг. Предпочтительным является неразрушающее тестирование, т.е. тесты, которые не влияют и не мешают повседневной работе компании. Тестирование путем отключения сервера от питания или от хранилища может иметь печальные последствия для вашей карьеры.
Одной из возможных стратегий является критический анализ. Команды собираются вместе, и им предлагается сценарий. Затем команды определяют, что им понадобится сделать, и рассуждают о возможных препятствиях, с которыми они могут столкнуться и что понадобится для их преодоления в плане ресурсов и времени. Задокументируйте весь процесс.
Еще одной стратегией может быть использование времени, которое отведено вам для тестирования, если вы заключили контракт с поставщиком hot site или средств восстановления после аварий. Постарайтесь восстановить данные, системы и сетевые операции и убедитесь, что у вас есть все необходимые ресурсы и отведенного вам времени достаточно. Результат этого текста также должен быть задокументирован, поскольку он напрямую демонстрирует эффективность плана и возможные слабые места из-за недостаточной синхронизации с текущими изменениями в бизнес деятельности или IT инфраструктуре.
Помните, что нет такой вещи, как гордость авторства от составления плана по восстановлению после сбоя, как нет и такой вещи, как провалившиеся тесты. Планировщики должны следить за тем, чтобы план был актуален, что означает проведение регулярных тестов и создание системы управления изменениями. Последнее может быть просто системой оповещения через электронную почту: в случае, если члены команды покидают компанию или меняют место работы, если создаются новые бизнес подразделения или существующие подразделения изменяют деятельность, и, безусловно, в случае изменений в IT инфраструктуре, планировщик получает электронное уведомление.
Тестирование, обучение и управление изменениями - именно здесь на практике можно применить знания о планировании восстановления данных. В дополнение к значимости этой деятельности, о чем было рассказано выше, они также обеспечивают своеобразное повторение в уме необходимых действий, что очень поможет персоналу действовать рационально перед лицом такой великой иррациональности, как катастрофа. Как писал Шекспир: "Коль мы готовы духом - все готово."