Восстановление после катастроф

Материал из Википедии — свободной энциклопедии
(перенаправлено с «Аварийное восстановление»)
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 25 декабря 2023 года; проверки требуют 2 правки.
Перейти к навигации Перейти к поиску

Восстановление после катастроф (в русскоязычных источниках также используется не вполне корректный термин аварийное восстановление) включает в себя набор политик, инструментов и процедур, позволяющих восстановить или продолжить работу жизненно важной технологической инфраструктуры и систем после стихийного бедствия или техногенной катастрофы[1]. Аварийное восстановление сосредоточено на информационных технологиях (ИТ) или технологических системах, поддерживающих критические бизнес-функции, в отличие от обеспечения непрерывности бизнеса, которое предполагает сохранение всех основных аспектов функционирования бизнеса, несмотря на значительные нарушения работы; поэтому его можно рассматривать как подмножество задач обеспечения непрерывности бизнеса[2][3]. Восстановление после катастроф предполагает, что основная часть первоначально работавшей информационной системы не подлежит восстановлению в течение некоторого времени, и представляет собой процесс восстановления данных и сервисов на второстепенных уцелевших площадках, противоположный процессу восстановления информационных систем на исходное место.

Непрерывность предоставления IT-услуг

[править | править код]

Планирование непрерывности ИТ-услуг (IT service continuity, ITSC)[4][5] — это подмножество планирования непрерывности бизнеса ( business continuity planning, BCP)[6], в котором основное внимание уделяется целевой точке восстановления (RPO) и целевому времени восстановления (RTO). Этот процесс включает в себя два вида планирования; Планирование аварийного восстановления ИТ и более широкое планирование устойчивости ИТ. Кроме того, он также включает в себя элементы управления ИТ-инфраструктурой и услугами, относящимися к связи, такими как (голосовая) телефония и передача данных.

Принципы резервирования площадок

[править | править код]
Основная статья: резервная площадка

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

В 2008 году Британский институт стандартов опубликовал специальный стандарт, связанный и поддерживающий стандарт непрерывности бизнеса BS 25999, под названием BS25777, специально для согласования непрерывности работы IT-систем с непрерывностью бизнеса. Этот стандарт был отозван после публикации в марте 2011 г. стандарта ISO/IEC 27031 «Методы обеспечения безопасности. Руководство по обеспечению готовности информационных и коммуникационных технологий к обеспечению непрерывности бизнеса»[7].

ITIL также определяет некоторые из этих терминов[8].

Цель по времени восстановления

[править | править код]

Цели по времени восстановления (Recovery Time Objective, RTO Этот термин также переводится как "Целевое время восстановления")[9][10] — это целевые продолжительность времени и уровень обслуживания, в рамках которых бизнес-процесс должен быть восстановлен после аварии (или сбоя), чтобы избежать неприемлемых последствий, связанных с перерывом в работе бизнеса[11].

В соответствии с методологией планирования обеспечения непрерывности бизнеса RTO устанавливается во время анализа воздействия на бизнес (Business Impact Analysis, BIA) владельцем (владельцами) процесса и включает определение временных рамок для альтернативных или ручных обходных путей восстановления.

Схематичное представление терминов RPO и RTO. В этом примере согласованные значения RPO и RTO не выдерживаются.

В литературе по этому вопросу RTO упоминается как взаимодополняющий с целевой точкой восстановления (RPO). Вместо они описывают пределы приемлемой или «допустимой» производительности ITSC. RTO и RPO измеряют производительность ITSC с точки зрения времени, потерянного из-за нормального функционирования бизнес-процессов, и данных, потерянных или не зарезервированных в течение этого периода (RPO), соответственно[11][12].

Фактическое время восстановления

[править | править код]

В обзоре Forbes отмечается[9], что фактическое время восстановления (Recovery Time Actual, RTA) на самом деле является критически важным показателем для обеспечения непрерывности бизнеса и аварийного восстановления.

Группа обеспечения непрерывности бизнеса проводит репетиции с таймингом фактически выполняемых действий, во время которых RTA определяется и корректируется при необходимости[9].

Целевая точка восстановления

[править | править код]

Целевая точка восстановления (Recovery Point Objective, RPO) — это максимальный целевой период, в течение которого транзакционные данные теряются из IT-службой из-за крупного инцидента[11].

Например, в случае, если RPO измеряется в минутах (или даже в нескольких часах), то на практике необходимо постоянно поддерживать удаленные зеркальные резервные копии, поскольку ежедневного резервного копирования на ленте за пределами площадки недостаточно[13].

Отношение к цели по времени восстановления

[править | править код]

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

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

Часто неверно истолковывается, что RPO определяется существующим режимом резервного копирования, тогда как в действительности анализ влияния на бизнес определяет RPO для каждой службы. Когда требуются удаленные данные, период, в течение которого данные могут быть потеряны, часто начинается с момента подготовки резервных копий, а не с момента их переноса за пределы площадки[12].

Точки синхронизации данных

[править | править код]

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

Как значения RTO и RPO влияют на дизайн компьютерной системы

[править | править код]

RTO и RPO должны быть сбалансированы с учетом бизнес-рисков, а также всех других основных критериев проектирования системы.

RPO привязана ко времени выгрузки резервных копий за пределы площадки. Синхронное копирование данных на внешнее зеркало позволяет преодолеть большинство непредвиденных проблем с доступностью основной площадки. Физическое перемещение лент (или других переносных носителей) за её пределы обеспечивает часть потребностей в резервном копировании при относительно низких затратах. Восстановление из таких копий может быть осуществлено на заранее выбранной площадке[16].

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

Другие характеристики процесса восстановления

[править | править код]

При более детальном планировании восстановления могут быть, также, использованы такие показатели как DOO – Degraded Operations Objective – допустимое замедление выполнения операций системой, происходящее в процессе перевода обработки данных на резервную площадку и NRO – Network Recovery Objective – минимальная полоса пропускания сети, которая подлежит восстановлению, чтобы обеспечить минимально приемлемые рабочие показатели восстанавливаемой системы[17].

История

[править | править код]

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

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

Индустрия аварийного восстановления появилась в качестве поставщика резервных компьютерных центров. Один из первых таких центров был расположен в Шри-Ланке (Sungard Availability Services, 1978)[18][19] developed to provide backup computer centers. One of the earliest such centers was located in Sri Lanka (Sungard Availability Services, 1978).[20][21].

В 1980-х и 90-х годах по мере роста внутрикорпоративного разделения времени, онлайн-ввода данных и обработки в режиме реального времени потребовалась большая доступность ИТ-систем.

Непрерывность ИТ-услуг важна для многих организаций при внедрении управления непрерывностью бизнеса (BCM) и управления информационной безопасностью (ICM), а также как часть внедрения и управления информационной безопасностью, а также управления непрерывностью бизнеса, как указано в ISO/IEC 27001 и ISO 22301 соответственно.

Рост облачных вычислений с 2010 года продолжает эту тенденцию: в настоящее время еще менее важно, где физически обслуживаются вычислительные службы, просто до тех пор, пока сама сеть достаточно надежна (отдельная проблема и не вызывает особого беспокойства, поскольку современные сети очень устойчивы). по дизайну). «Восстановление как услуга» (RaaS) — это одна из функций безопасности или преимуществ облачных вычислений, продвигаемых Cloud Security Alliance[22].

Классификация катастроф

[править | править код]

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

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

Третья категория — это антропогенные угрозы, которые включают преднамеренные действия, такие как активные атаки злоумышленников, химические или биологические атаки, кибератаки на данные или инфраструктуру и саботаж. Меры по обеспечению готовности ко всем категориям и типам стихийных бедствий относятся к пяти областям миссии: предотвращение, защита, смягчение последствий, реагирование и восстановление[23].

Важность планирования аварийного восстановления

[править | править код]

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

Статистика аварийного восстановления за 2015 год показывает, что простой в течение одного часа может стоить

  • небольшой компании до 8000 долларов,
  • организации среднего размера $74 000 и
  • крупному предприятию 700 000 долларов США[25].

Поскольку ИТ-системы становятся все более важными для бесперебойной работы компании и, возможно, экономики в целом, возрастает важность обеспечения непрерывной работы этих систем и их быстрого восстановления. Например, 43% компаний, в которых произошла крупная потеря бизнес-данных, никогда не открываются повторно, а 29% закрываются в течение двух лет. В результате к подготовке к продолжению или восстановлению систем необходимо относиться очень серьезно. Это требует значительных затрат времени и денег с целью обеспечения минимальных потерь в случае разрушительного события[26].

Меры борьбы

[править | править код]

Меры борьбы — это действия или механизмы, которые могут уменьшить или устранить различные угрозы для организаций. В план аварийного восстановления (disaster recovery plan, DRP) могут быть включены различные типы мер.

Планирование аварийного восстановления является частью более крупного процесса, известного как планирование непрерывности бизнеса, и включает планирование возобновления работы приложений, данных, оборудования, электронных коммуникаций (например, сетей) и другой ИТ-инфраструктуры. План обеспечения непрерывности бизнеса (BCP) включает в себя планирование аспектов, не связанных с ИТ, таких как ключевой персонал, объекты, кризисная коммуникация и защита репутации, и должен ссылаться на план аварийного восстановления (DRP) для восстановления/непрерывности инфраструктуры, связанной с ИТ.

Меры по управлению аварийным восстановлением ИТ можно разделить на следующие три типа:

  • Превентивные меры – средства контроля, направленные на предотвращение возникновения события.
  • Меры обнаружения – средства контроля, направленные на обнаружение или обнаружение нежелательных событий.
  • Корректирующие меры – средства контроля, направленные на исправление или восстановление системы после аварии или события[27].

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

Стратегии восстановления

[править | править код]

Прежде чем выбрать стратегию аварийного восстановления, планировщик аварийного восстановления сначала обращается к плану обеспечения непрерывности бизнеса своей организации, в котором должны быть указаны ключевые показатели целевой точки восстановления и цели по времени восстановления[28] Затем показатели бизнес-процессов сопоставляются с их системами и инфраструктурой[29].

Отсутствие надлежащего планирования может увеличить последствия стихийного катастрофы[30]. После сопоставления метрик организация пересматривает ИТ-бюджет; показатели RTO и RPO должны соответствовать доступному бюджету. Анализ затрат и результатов часто определяет, какие меры аварийного восстановления следует применять.

New York Times пишет, что добавление облачного резервного копирования к преимуществам локального и удаленного архивирования на магнитных лентах «добавляет уровень защиты данных»[31].

Часто используемые стратегии защиты данных включают:

  • резервные копии, сделанные на ленту и отправленные за пределы офиса через регулярные промежутки времени
  • резервные копии, сделанные на диске на месте и автоматически скопированные на внешний диск или сделанные непосредственно на внешний диск
  • репликация данных в удаленное место, что избавляет от необходимости восстанавливать данные (затем необходимо восстанавливать или синхронизировать только системы), часто с использованием технологии сети хранения данных (SAN).
  • решения для частного облака, которые реплицируют конфигурационные и управляющие данные (виртуальные машины, шаблоны и диски) в домены хранения, являющиеся частью настройки частного облака. Эти данные настраивают в виде XML-представления, называемого OVF (формат открытой виртуализации), и конфигурация системы может быть восстановлена в случае аварии на их основе.
  • гибридные облачные решения, которые реплицируются как на месте, так и в удаленных центрах обработки данных. Эти решения обеспечивают возможность мгновенного переключения на локальное оборудование на месте, но в случае физической аварии серверы также могут быть переведены в облачные центры обработки данных.
  • использование систем высокой доступности, в которых данные и система реплицируются за пределами площадки, обеспечивая непрерывный доступ к системам и данным даже после аварии (часто связанной с облачным хранилищем)[32].

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

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

  • локальные зеркала систем и/или данных и использование технологий защиты дисков, таких как RAID
  • сетевые фильтры — для минимизации воздействия скачков напряжения на чувствительное электронное оборудование
  • использование источника бесперебойного питания (ИБП) и/или резервного генератора для поддержания работы систем в случае сбоя питания
  • системы предотвращения/смягчения пожара, такие как сигнализация и огнетушители
  • антивирусное программное обеспечение и другие меры безопасности

Классификация планов аварийного восстановления

[править | править код]

Один из широко используемых видов классификации планов восстановления - семиуровневая классификация, разработанная в конце 1980-х годов комитетом SHARE Technical Steering Committee, проводившим эту разработку совместно с компанией IBM. Они разработали технический документ, описывающий уровни обслуживания восстановления после катастроф с использованием уровней с 0 по 6. С тех пор появился целый ряд классификаций, конкурирующих с этой и отражающих дальнейшее развитие технологий и индустрии в целом. Разные классификации концентрируются на разных аспектах или технических особенностях процесса восстановления. Так, классификация Wiboobratr и Kosavisutee ориентирована, в основном, на решения DRaaS. Ниже приводится сравнительная таблица таких классификаций[33].

Уровень SHARE/IBM[34][35][36] Hitachi[37] Wiboonratr и Kosavisutte[38] Novell[39] Xiotech[40]
0 План аварийного восстановления отсутствует.
1 Осуществляется резервное копирование, резервные копии вывозятся в отдельное зданиеЮ но горячая резервная площадка отсутствует. Этот метод резервирования обозначают как «Pickup Truck Access Method (PTAM)[17]. Осуществляется резервное копирование на ленту за пределы рабочей площадки. Возможно восстановление на момент времени. Резервное копирование на ленту/ручное восстановление. Уровень 4.

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

2 Осуществляется резервное копирование, имеется горячая резервная площадка на которую могут быть восстановлены данные из резервной копии[17]. Метод известен как PTAM+hotsite. Осуществляется резервное копирование на ленту на основную или резервную площадку. Копии, сделанные на ленту доставляются на заранее подготовленную резервную площадку. Традиционное сохранение/восстановление образа диска.
3 "Электронное хранилище" (electronic vaulting). По сравнению с уровнем 2 добавляется возможность регулярного копирования (и, соответственно, восстановления) данных с основной площадки. Типичное время восстановления - 24 часа[34]. "Электронное хранилище" - аналогично классификации SHARE/IBM. Дисковые копии, обеспечивающие восстановление на момент времени осуществляются в несколько локаций Гибкое (в том числе пофайловое и с выбором версии файла для восстановления) сохранение/восстановление образа диска. Уровень 3.

Относительно быстрое восстановление из резервных копий, осуществляемых асинхронно или по расписанию на "тёплую" резервную площадку.

4 Создаются копии, позволяющие осуществлять восстановление на момент времени. Единичная резервная копия, записываемая на диск. Осуществляется удалённое журналирование работы системы. Резервное копирование/восстановление на основе виртуализации.
5 Обеспечивается транзакционная целостность данных. Возможность восстановления с использованием консолидации файлов с разных образов дисков Параллельное создание теневой копии рабочей базы данных Резервирование на основе серверов, работающих в кластере. Уровень 2.

Быстрое восстановление из асинхронной копии, осуществляемой на горячую резервную площадку.

6 Нулевые или малые потери данных после восстановленияю. Наличие данных на разделяемом между основной и резервной системами диске. Осуществляется удалённое копирование данных.
7 Высокоавтоматизированное восстановление. Зеркалирование дисков между основной и резервной системой. Осуществляется удалённое отказоустойчивое копирование данных. Уровень 1.

Мгновенное восстановление из синхронной копии, осуществляемой на горячую резервную площадку.

8 Полное дублирование данных.

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

Восстановление как услуга

[править | править код]
Основная статья: Восстановление как услуга

Аварийное восстановление как услуга (DRaaS) — это соглашение с третьей стороной, поставщиком услуг и/или оборудования.[41]. Обычно предлагается поставщиками услуг как часть их портфеля услуг. Ряд крупных поставщиков оборудования предлагают в качестве части такой услуги модульные датацентры, позволяющие максимально быстро развернуть необходимые для аварийного восстановления мощности оборудования.

См. также

[править | править код]

Примечания

[править | править код]
  1. ↑ Systems and Operations Continuity: Disaster Recovery. Архивная копия от 25 августа 2012 на Wayback Machine Georgetown University. University Information Services. Retrieved 3 August 2012.
  2. ↑ Disaster Recovery and Business Continuity, version 2011. Архивировано 11 января 2013 года. IBM. Retrieved 3 August 2012.
  3. ↑ [1] Архивная копия от 25 августа 2020 на Wayback Machine 'What is Business Continuity Management', DRI International, 2017
  4. ↑ Information systems continuity process. ACM.com (ACM Digital Library) (март 2017).
  5. ↑ "2017 IT Service Continuity Directory" (PDF). Disaster Recovery Journal. Архивировано (PDF) 30 ноября 2018. Дата обращения: 24 апреля 2022.
  6. ↑ Defending The Data Strata. ForbesMiddleEast.com (24 декабря 2013).
  7. ↑ ISO 22301 to be published Mid May - BS 25999-2 to be withdrawn (англ.). Business Continuity Forum (3 мая 2012). Дата обращения: 20 ноября 2021. Архивировано 20 ноября 2021 года.
  8. ↑ ITIL glossary and abbreviations. Дата обращения: 26 апреля 2022. Архивировано 6 мая 2021 года.
  9. ↑ 1 2 3 "Like The NFL Draft, Is The Clock The Enemy Of Your Recovery Time". Forbes. April 30, 2015. Архивировано 26 апреля 2022. Дата обращения: 26 апреля 2022.
  10. ↑ "Three Reasons You Can't Meet Your Disaster Recovery Time". Forbes. 2013-10-10. Архивировано 26 апреля 2022. Дата обращения: 26 апреля 2022.
  11. ↑ 1 2 3 Understanding RPO and RTO. DRUVA (2008). Дата обращения: 13 февраля 2013. Архивировано 8 мая 2013 года.
  12. ↑ 1 2 How to fit RPO and RTO into your backup and recovery plans. SearchStorage. Дата обращения: 20 мая 2019. Архивировано 20 июня 2019 года.
  13. ↑ Richard May. Finding RPO and RTO. Архивировано из оригинала 3 марта 2016 года.
  14. ↑ Data transfer and synchronization between mobile systems (14 мая 2013). Дата обращения: 4 мая 2022. Архивировано 25 января 2022 года.
  15. ↑ Amendment #5 to S-1. SEC.gov. — «real-time ... provide redundancy and back-up to ...» Дата обращения: 4 мая 2022. Архивировано 10 марта 2013 года.
  16. ↑ William Caelli. Information Security for Managers / William Caelli, Denis Longley. — 1989. — P. 177. — ISBN 1349101370.
  17. ↑ 1 2 3 Косяченко С.А., Микрин Е.А., Павельев С.В. Методы и средства создания катастрофоустойчивых территориально-распределенных систем обработки данных. — М.: Институт проблем управления им. В.А. Трапезникова РАН, 2008. — 78 с. — ISBN 5-201-15020-9.
  18. ↑ "Catastrophe? It Can't Possibly Happen Here". The New York Times. 1995-01-29. Архивировано 5 мая 2022. Дата обращения: 5 мая 2022. .. patient records
  19. ↑ Commercial Property/Disaster Recovery. NYTimes.com (9 октября 1994). — «...the disaster-recovery industry has grown to». Дата обращения: 5 мая 2022. Архивировано 5 мая 2022 года.
  20. ↑ Charlie Taylor (2015-06-30). "US tech firm Sungard announces 50 jobs for Dublin". The Irish Times. Sungard .. founded 1978
  21. ↑ Cassandra Mascarenhas. SunGard to be a vital presence in the banking industry. Wijeya Newspapers Ltd. (12 ноября 2010). — «SunGard ... Sri Lanka's future.» Дата обращения: 5 мая 2022. Архивировано 25 января 2022 года.
  22. ↑ SecaaS Category 9 // BCDR Implementation Guidance Архивная копия от 8 января 2018 на Wayback Machine CSA, retrieved 14 July 2014.
  23. ↑ Threat and Hazard Identification and Risk Assessment (THIRA) and Stakeholder Preparedness Review (SPR): Guide Comprehensive Preparedness Guide (CPG) 201, 3rd Edition. US Department of Homeland Security (май 2018). Дата обращения: 6 мая 2022. Архивировано 31 октября 2020 года.
  24. ↑ Post-Disaster Recovery Planning Forum: How-To Guide, Prepared by Partnership for Disaster Resilience (недоступная ссылка — история). University of Oregon's Community Service Center, (C) 2007, www.OregonShowcase.org.
  25. ↑ The Importance of Disaster Recovery. Дата обращения: 6 мая 2022. Архивировано 7 апреля 2022 года.
  26. ↑ IT Disaster Recovery Plan. FEMA (25 октября 2012). Дата обращения: 6 мая 2022. Архивировано 6 февраля 2021 года.
  27. ↑ Mahendra Sagara Fernando. IT disaster recovery system to ensure the business continuity of an organization // 2017 National Information Technology Conference (NITC). — 2017-09. — С. 46–48. — doi:10.1109/NITC.2017.8285648. Архивировано 7 мая 2022 года.
  28. ↑ Use of the Professional Practices framework to develop,implement,maintain a business continuity program can reduce the likelihood of significant gaps. DRI International (16 августа 2021). Дата обращения: 2 сентября 2021. Архивировано 12 апреля 2020 года.
  29. ↑ Gregory, Peter. CISA Certified Information Systems Auditor All-in-One Exam Guide, 2009. ISBN 978-0-07-148755-9. Page 480.
  30. ↑ Five Mistakes That Can Kill a Disaster Recovery Plan. Dell.com. Дата обращения: 22 июня 2012. Архивировано из оригинала 16 января 2013 года.
  31. ↑ J. D. Biersdorfer (2018-04-05). "Monitoring the Health of a Backup Drive". The New York Times. Архивировано 7 мая 2022. Дата обращения: 7 мая 2022.
  32. ↑ Brandon, John (2011-06-23). "How to Use the Cloud as a Disaster Recovery Strategy". Inc. Дата обращения: 11 мая 2013.
  33. ↑ Omar H. Alhami, Yashwant K. Malaiya. Are the Classical Disaster Recovery Tiers Still Applicable Today? // 2014 IEEE International Symposium on Software Reliability Engineering Workshops. — 2014-11. — С. 144–145. — doi:10.1109/ISSREW.2014.68. Архивировано 4 мая 2022 года.
  34. ↑ 1 2 Traci Kent. The Seven Tiers of BCP (амер. англ.). go.dewpoint.com. Дата обращения: 9 мая 2022. Архивировано 23 сентября 2020 года.
  35. ↑ Robert Kern, Victor Peltz. Disaster Recovery Levels // IBM Systems Magazine. — 2003. — Ноябрь.
  36. ↑ C. Brooks, M. Bedernjak, I. Juran, J. Merryman. Disaster Recovery Strategies with Tivoli Storage Management, IBM/Redbooks. — November, 2002. Архивировано 3 марта 2016 года.
  37. ↑ Roselinda R. Schulman. Disaster Recovery Issues and Solutions, A White Paper / Hitachi Data Systems. — September 2004.
  38. ↑ Montri Wiboonratr, Kitti Kosavisutte. Optimal strategic decision for disaster recovery // International Journal of Management Science and Engineering Management : journal. — 2009. — Т. 4, № 4. — С. 260-269.
  39. ↑ Consolidated Disaster Recovery / Novell. — March 2009. Архивировано 19 октября 2013 года.
  40. ↑ Tiered Data Protection and Recovery / Xiotech Corporation. — May 2006.
  41. ↑ Disaster Recovery as a Service (DRaaS). Дата обращения: 8 мая 2022. Архивировано 13 января 2022 года.
Источник — https://ru.wikipedia.org/w/index.php?title=Восстановление_после_катастроф&oldid=139086896