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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Меры борьбы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уровень	SHARE/IBM	Hitachi	Wiboonratr и Kosavisutte	Novell	Xiotech
0	План аварийного восстановления отсутствует.
1	Осуществляется резервное копирование, резервные копии вывозятся в отдельное зданиеЮ но горячая резервная площадка отсутствует. Этот метод резервирования обозначают как «Pickup Truck Access Method (PTAM).	Осуществляется резервное копирование на ленту за пределы рабочей площадки.	Возможно восстановление на момент времени.	Резервное копирование на ленту/ручное восстановление.	Уровень 4. Резервные копии, осуществляемые по расписанию на "холодную" резервную площадку
2	Осуществляется резервное копирование, имеется горячая резервная площадка на которую могут быть восстановлены данные из резервной копии. Метод известен как PTAM+hotsite.	Осуществляется резервное копирование на ленту на основную или резервную площадку.	Копии, сделанные на ленту доставляются на заранее подготовленную резервную площадку.	Традиционное сохранение/восстановление образа диска.
3	"Электронное хранилище" (electronic vaulting). По сравнению с уровнем 2 добавляется возможность регулярного копирования (и, соответственно, восстановления) данных с основной площадки. Типичное время восстановления - 24 часа.	"Электронное хранилище" - аналогично классификации SHARE/IBM.	Дисковые копии, обеспечивающие восстановление на момент времени осуществляются в несколько локаций	Гибкое (в том числе пофайловое и с выбором версии файла для восстановления) сохранение/восстановление образа диска.	Уровень 3. Относительно быстрое восстановление из резервных копий, осуществляемых асинхронно или по расписанию на "тёплую" резервную площадку.
4	Создаются копии, позволяющие осуществлять (восстановление на момент времени).	Единичная резервная копия, записываемая на диск.	Осуществляется удалённое журналирование работы системы.	Резервное копирование/восстановление на основе виртуализации.
5	Обеспечивается транзакционная целостность данных.	Возможность восстановления с использованием консолидации файлов с разных образов дисков	Параллельное создание теневой копии рабочей базы данных	Резервирование на основе серверов, работающих в кластере.	Уровень 2. Быстрое восстановление из асинхронной копии, осуществляемой на горячую резервную площадку.
6	Нулевые или малые потери данных после восстановленияю.	Наличие данных на разделяемом между основной и резервной системами диске.	Осуществляется удалённое копирование данных.
7	Высокоавтоматизированное восстановление.	Зеркалирование дисков между основной и резервной системой.	Осуществляется удалённое отказоустойчивое копирование данных.		Уровень 1. Мгновенное восстановление из синхронной копии, осуществляемой на горячую резервную площадку.
8		Полное дублирование данных.

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

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

Основная статья: (Восстановление как услуга)

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

См. также

• Резервная площадка
• (Планирование непрерывности бизнеса)
• (Continuous Data Protection)
• (Предупреждение и ликвидация чрезвычайных ситуаций)
• (Высокая доступность)
• (Удалённое резервное копирование данных)
• (Виртуальная ленточная библиотека)
• ^[англ.]

Примечания

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. "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. October 10, 2013. 26 апреля 2022. Дата обращения: 26 апреля 2022.
11. Understanding RPO and RTO  (неопр.). DRUVA (2008). Дата обращения: 13 февраля 2013. 8 мая 2013 года.
12. How to fit RPO and RTO into your backup and recovery plans  (неопр.). SearchStorage. Дата обращения: 20 мая 2019. 20 июня 2019 года.
13. Richard May.   (неопр.). Архивировано из оригинала 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. — .
17. Косяченко С.А., Микрин Е.А., Павельев С.В. Методы и средства создания катастрофоустойчивых территориально-распределенных систем обработки данных. — М.: Институт проблем управления им. В.А. Трапезникова РАН, 2008. — 78 с. — .
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. . Page 480.
30.   (неопр.). 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 (23 June 2011). "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. 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 года.