Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Azure Backup — это встроенная служба #REF!, которая безопасно защищает облачные и локальные рабочие нагрузки. Azure Backup может беспрепятственно масштабировать свою защиту на несколько рабочих нагрузок и обеспечить встроенную интеграцию с нагрузками #REF!, включая виртуальные машины (ВМ), SAP HANA на #REF! ВМ, SQL на #REF! ВМ, Файлы Azure, объекты BLOB, #REF!, диски, тома Elastic SAN, AKS и многое другое. Вам не нужно управлять автоматизацией или инфраструктурой. Нет необходимости писать скрипты или подготавливать хранилище.
При использовании #REF! надежность является совместной ответственностью. Корпорация Майкрософт предоставляет ряд возможностей для поддержки устойчивости и восстановления. Вы несете ответственность за понимание того, как работают эти возможности во всех используемых вами службах, а также за выбор возможностей, необходимых для достижения бизнес-целей и целей бесперебойной работы.
В этой статье описывается, как Azure Backup может быть устойчивым к различным потенциальным сбоям и проблемам, включая временные сбоя, сбоя зоны доступности и сбоя регионов. Он также выделяет некоторые ключевые сведения о соглашении об уровне обслуживания Azure Backup (SLA).
Замечание
В этом документе описывается, как сама служба Azure Backup является или может стать устойчивой к различным проблемам и вызовам. В нем не объясняется, как использовать Azure Backup для защиты виртуальных машин, данных или других ресурсов. Дополнительные сведения об использовании Azure Backup см. в статье Что такое служба Azure Backup?.
Рекомендации по развертыванию в рабочей среде для обеспечения надежности
Для резервного копирования производственных нагрузок рекомендуется настроить хранилище следующим образом:
- Используйте хранилище избыточности между зонами (ZRS) в качестве минимального уровня избыточности для резервных копий. Зонально избыточное хранилище реплицирует резервные копии в нескольких зонах доступности, чтобы можно было восстановить их в случае сбоя зоны доступности.
- При использовании геоизбыточного хранилища (GRS) для репликации резервных копий в парный регион #REF! необходимо также включить восстановление между регионами для поддерживаемых источников данных. Восстановление между регионами означает, что резервные копии можно восстановить в парном регионе в любое время.
Остальные разделы этой статьи содержат дополнительные сведения об этих конфигурациях.
Замечание
Эти рекомендации по избыточности хранилища применяются к месту репликации резервных копий, а не на службу Azure Backup или ресурсы, которые вы резервируете. Защита резервных копий и избыточность хранилища являются взаимодополняющими — резервные копии защищают от потери данных, а избыточность защищает от сбоев инфраструктуры.
Для списка других рекомендаций для Azure Backup, включая те, которые ориентированы на надежность, см. статью Резервное копирование облачных и локальных рабочих нагрузок в облако.
Обзор архитектуры надежности
В этом разделе описываются некоторые важные аспекты работы службы, наиболее релевантные с точки зрения надежности. В этом разделе представлена логическая архитектура, включающая некоторые ресурсы и функции, которые развертываются и используются. Он также обсуждает аппаратную архитектуру, которая содержит сведения о том, как работает служба изнутри.
Логическая архитектура
Azure Backup может создавать резервные копии и восстанавливать различные источники данных. Резервное копирование настраивается по-разному в зависимости от источника данных, с которым вы работаете. К общим источникам данных относятся:
- #REF! виртуальные машины
- Различные базы данных
- учетные записи Blob в #REF!
- Кластеры AKS
- Локальные серверы через агент служб восстановления Microsoft Azure (MARS)
Azure Backup хранит резервные копии данных в vaults. Хранилище — это сущность интернет-хранилища в #REF!, которая используется для хранения данных, таких как резервные копии, точки восстановления и политики резервного копирования. Существует два типа хранилищ: хранилища служб восстановления и хранилища резервных копий. Вы можете использовать один или оба типа хранилища в зависимости от того, что необходимо защитить. Список источников данных, поддерживаемых каждым типом хранилища, см. в разделе "Что такое различные хранилища, поддерживаемые для резервного копирования и восстановления?".
Задания представляют действие резервного копирования или восстановления данных. Задания резервного копирования включают запланированные операции и операции по запросу, которые копируют ваши данные из источника в хранилище. Задания восстановления включают операции, которые восстанавливают данные из хранилища резервных копий в целевое расположение. Каждое задание имеет уникальный идентификатор и отслеживание состояния, что позволяет отслеживать ход выполнения и устранять все проблемы, возникающие во время операций резервного копирования и восстановления. Вы также создаете политики резервного копирования , связанные с заданиями. Политики указывают конфигурацию, например расписание резервного копирования и срок хранения данных.
Хранилища хранят политики резервного копирования и конфигурацию, а также хранят метаданные о заданиях, что позволяет отслеживать и устранять неполадки.
Физическая архитектура
Базовая инфраструктура служб Azure Backup управляется корпорацией Майкрософт. Эта инфраструктура отвечает за управление и эксплуатацию службы, включая активацию и мониторинг заданий.
Azure Backup служба сохраняет резервные копии в хранилище. Хранилища создаются на основе служба хранилища Azure. Хранилища автоматически реплицируют данные резервного копирования, а надежность и устойчивость резервного копирования зависят от избыточности хранилища:
Локально избыточное хранилище (LRS) реплицирует данные в одну или несколько зон доступности #REF!, расположенных в выбранном вами основном регионе. Хотя нет возможности выбрать предпочтительную зону доступности, #REF! может перемещать или расширять учетные записи LRS между зонами, чтобы повысить балансировку нагрузки. Нет никаких гарантий, что ваши данные будут распространяться по зонам. Дополнительные сведения о зонах доступности см. в разделе Что такое зоны доступности?.
Хранилище с межзоновой избыточностью (ZRS) и хранилище с географической избыточностью (GRS) обеспечивают дополнительную степень защиты. В этой статье подробно описаны эти параметры.
Замечание
Некоторые источники данных поддерживают резервные копии операционного уровня, которые хранят данные в другом месте, а не в хранилище. Например, резервное копирование дисков #REF! и резервные копии AKS поддерживают резервное копирование операционного уровня, которые хранятся в моментальных снимках дисков. В этой статье не рассматриваются хранилище резервных копий операционного уровня, но информация о службе Azure Backup остается применимой.
Устойчивость к временным сбоям
Временные ошибки являются короткими, периодическими сбоями в компонентах. Они часто происходят в распределенной среде, такой как облачная платформа, и являются обычной частью операций. Временные ошибки исправляют себя через короткий период времени. Важно, чтобы приложения могли обрабатывать временные ошибки, обычно повторяя затронутые запросы.
Все облачные приложения должны следовать #REF! рекомендации по обработке временных ошибок при обмене данными с любыми размещенными в облаке API, базами данных и другими компонентами. Дополнительные сведения см. в Рекомендациях по обработке временных сбоев.
При использовании Azure Backup рабочие процессы резервного копирования и восстановления устойчивы к периодическим сбоям. Служба автоматически повторяет попытку при возникновении временных сбоев сети или временных прерываний службы. Вы не настраиваете логику повторных попыток. При возникновении повторяющихся ошибок обратитесь к документации по устранению неполадок.
Устойчивость к сбоям зоны доступности
Зоны Availability физически разделяют группы центров обработки данных в #REF! регионе. При сбое одной зоны службы могут переключиться на одну из оставшихся зон.
Azure Backup отдельно управляет конфигурацией зоны доступности службы и данных.
Service: Сама служба Azure Backup автоматически устойчива к зонам в поддерживаемых регионах без каких-либо действий. Однако эта встроенная устойчивость зоны не применяется к резервным копиям данных.
Избыточность хранилища резервных копий: Выберите уровень избыточности, который требуется для данных резервного копирования, настроив хранилище служб восстановления или хранилище резервных копий. Если выбрать зонально-избыточное хранилище (ZRS), копии данных резервного копирования автоматически хранятся в нескольких зонах доступности региона #REF!, который вы используете.
Если вы не используете ZRS, данные резервного копирования считаются незональными и могут храниться в любой зоне. Если у любой зоны в регионе возникла проблема, данные незонального резервного копирования могут быть недоступны.
Требования
Поддержка региона: Служба автоматически устойчива к зонам во всех регионах с зонами доступности. Хранилища ZRS поддерживаются в тех же регионах.
Только новые хранилища: Настройте ZRS в хранилище перед первой резервной копией.
Себестоимость
При включении зонально-избыточного хранения (ZRS) для ваших резервных копий, стоимость отличатся от локально-избыточного хранения (LRS) из-за дополнительных накладных расходов на репликацию и хранение. Дополнительные сведения см. в разделе цены на Azure Backup.
Настройка поддержки зоны доступности
Создайте новое хранилище, использующее ZRS: При создании хранилища необходимо также настроить избыточность хранилища. Шаги, которые вы выполняете, отличаются в зависимости от типа хранилища. Дополнительные сведения можно найти здесь
- Создание и удаление хранилищ резервных копий
- Создание и настройка хранилища служб восстановления
Настройте ZRS в существующих хранилищах: Для хранилищ резервных копий настройте избыточность хранилища при создании хранилища. После создания хранилища резервных копий параметр заблокирован и не может быть изменен.
Для хранилищ служб восстановления необходимо настроить избыточность хранилища перед защитой любых рабочих нагрузок. После защиты рабочей нагрузки параметр заблокирован и не может быть изменен.
Вы можете создать новое хранилище, настроенное для использования ZRS, и переназначить рабочие нагрузки в новое хранилище. Однако для этого подхода необходим простой. Дополнительные сведения см. в статье "Создание и настройка хранилища служб восстановления— изменение параметров по умолчанию](/azure/backup/backup-create-recovery-services-vault#modify-default-settings). Вы также несете ответственность за удаление всех существующих точек восстановления и других данных вручную, так как политики хранения старого хранилища больше не применяются. Дополнительные сведения об удалении хранилища см. в статье "Удаление хранилища резервных копий " или "Удаление хранилища служб восстановления".
Поведение, когда все зоны работоспособны
Если хранилища используют зонально-избыточное хранилище и все зоны доступности работают, ожидайте следующее:
Операция между зонами: Задания резервного копирования выполняются в инфраструктуре, реплицируемой между зонами. #REF! управляет заданиями из инфраструктуры в любой зоне.
Репликация данных между зонами: ZRS реплицирует резервные копии данных между зонами. Репликация выполняется синхронно, что означает, что перед завершением каждой операции записи несколько зон признают каждую операцию записи.
Поведение во время сбоя зоны
Если хранилища настроены на использование зонально-избыточного хранилища и происходит сбой в зоне доступности, ожидается следующее:
Обнаружение и реагирование: Для самой службы Azure Backup корпорация Майкрософт несет ответственность за обнаружение сбоя в зоне доступности и реагирование. Вам не нужно ничего делать, чтобы инициировать переключение зоны.
Это важно
Для любых данных или ресурсов, недоступных из-за сбоя зоны, вы несете ответственность за обнаружение сбоя и выполнение любых действий восстановления, включая восстановление резервных копий в работоспособной зоне.
- Уведомление: Microsoft не уведомляет вас автоматически об отключении зоны. Однако вы можете использовать #REF! Работоспособность ресурсов для отслеживания работоспособности отдельного ресурса и настроить оповещения Работоспособность ресурсов для уведомления о проблемах. Вы также можете использовать Работоспособность служб Azure для понимания общего состояния службы, включая любые сбои зоны, и настроить оповещения Service Health для уведомления о проблемах.
Активные запросы: Поведение активных заданий зависит от того, какая зона вышла из строя.
- Для любых источников данных в неработающей зоне доступности они, вероятно, будут недоступны из-за сбоя этой зоны. Активные задания могут быть приостановлены или завершиться ошибкой.
- Для всех источников данных в работоспособных зонах доступности, выполняющих активные задания, небольшое время простоя, как правило, несколько секунд, может произойти, пока платформа переключается на использование работоспособных зон доступности для службы Azure Backup.
Ожидаемая потеря данных: Объем потери данных, который можно ожидать, также называется целевой точкой восстановления (RPO). RPO для данных резервного копирования зависит от нескольких факторов, включая расписание резервного копирования. Как правило, в случае сбоя зоны не ожидается потери резервных данных, так как все данные реплицируются синхронно по зонам.
Ожидаемое время простоя: Количество времени простоя, которое можно ожидать, также называется целевой задачей времени восстановления (RTO). RTO отличается для каждого из следующих сценариев:
- Для источников данных в зоне доступности, которая испытала сбой, источники данных могут быть недоступны до восстановления зоны. Задания резервного копирования могут не выполняться до тех пор, пока источник данных не будет доступен снова. RTO не определен.
- Для любых источников данных в здоровых зонах доступности небольшое время простоя, как правило, несколько секунд, может произойти, пока платформа переключается на использование работоспособных зон доступности для службы Azure Backup.
Перераспределение: Все последующие выполнения заданий автоматически используют инфраструктуру в работоспособных зонах, пока доступны источники данных.
Вы несете ответственность за восстановление резервного копирования в инфраструктуру в зоне healhty, а также за перенастройку всех подсистем балансировки нагрузки, клиентов и других систем для перенаправления трафика в здоровую инфраструктуру в новой зоне.
Восстановление зоны
Когда зона доступности восстанавливается, Azure Backup автоматически восстанавливает операции в зоне доступности и перенаправляет трафик между зонами в обычном режиме. Задания продолжают выполняться и данные остаются доступными.
Тестирование на сбои в зоне
Платформа Azure Backup управляет маршрутизацией трафика, репликацией данных, процедурой аварийного восстановления и восстановлением после отказа. Эта функция полностью управляется, поэтому не требуется инициировать или проверять процессы сбоя зоны доступности.
Устойчивость к сбоям на уровне региона
Azure Backup поддерживает геоизбыточное копирование и резервное копирование в случае отказа через геоизбыточное хранилище (GRS) и восстановление через регионы.
Это важно
GRS для Azure Backup работает только в парных регионах #REF!.
Географически избыточное хранилище и кросс-региональное восстановление
Для обеспечения региональной избыточности для данных резервного копирования Azure Backup позволяет реплицировать резервные копии в парный регион #REF! с помощью геоизбыточного хранилища (GRS). GRS защищает резервные копии от региональных сбоев.
Регион, в который вы развертываете свое хранилище, называется основным регионом. Источники данных должны находиться в основном регионе. Вы не можете сконфигурировать резервные копии в хранилище, расположенное в другом регионе.
Парный регион также называется дополнительным регионом.
Схема, показывающая, как данные реплицируются с помощью GRS.
Два синих поля представляют основной регион и дополнительный регион. Они содержат серый прямоугольник, представляющий центр обработки данных. Темно-фиолетовая коробка внутри коробки центра обработки данных представляет LRS. Он содержит светло-фиолетовый прямоугольник, включающий учетную запись хранения и три значка, помеченные как копия 1, копия 2 и копия 3. Пунктирная линия, представляющая GRS, охватывает поля LRS в обоих регионах. Стрелка, помеченная георепликацией, указывает из учетной записи хранения в основном регионе в учетную запись хранения во вторичном регионе.
Если вы не настроите GRS, сбой в регионе хранилища может по-прежнему позволить вам получить доступ к хранилищу и просматривать элементы резервного копирования. Однако без региональной избыточности базовые данные резервного копирования остаются недоступными для операций восстановления.
Межрегиональное восстановление
При настройке GRS в хранилище корпорация Майкрософт создает резервные копии в парном регионе после объявления сбоя в основном регионе. Если ваш источник данных поддерживает включение восстановления данных между регионами, можно восстановить из точек восстановления вторичного региона, даже если в основном регионе не возникает сбой. Восстановление между регионами также позволяет проводить учения для оценки вашей готовности к региональным сбоям. Включение восстановления между регионами обновляет хранилище резервных копий с GRS до геоизбыточного хранилища с доступом только для чтения (RA-GRS).
Требования
Поддержка регионов: GRS для Azure Backup работает только в спаренных регионах #REF!.
Только новые хранилища: GRS необходимо настроить в хранилище до того, как будет выполнена первая резервная копия.
Соображения
- Восстановление между регионами: После включения перекрестного восстановления может потребоваться до 48 часов, чтобы элементы резервного копирования были доступны в дополнительном регионе.
Себестоимость
Хранилища GRS требуют дополнительных затрат на репликацию данных между регионами и хранение в резервном регионе. Плата за передачу данных между #REF! регионами взимается на основе стандартных скоростей пропускной способности между регионами. Восстановление между регионами тарифицируется по другой ставке, поскольку Microsoft обновляет ваше хранилище с GRS до RA-GRS. Дополнительные сведения см. в разделе цены на Azure Backup.
Настройка поддержки нескольких регионов
Создайте новое хранилище, использующее GRS и CRR: При создании хранилища необходимо также настроить избыточность хранилища. Выбрав GRS, вы можете опционально включить CRR в резервное хранилище. Шаги, которые вы выполняете, отличаются в зависимости от типа хранилища. Дополнительные сведения можно найти здесь
- Создание и удаление хранилищ резервных копий
- Создание и настройка хранилища служб восстановления
Настройте GRS и CRR в существующих хранилищах: Для хранилищ резервных копий при создании хранилища необходимо настроить избыточность хранилища.
Для хранилищ служб восстановления необходимо настроить избыточность хранилища перед защитой любых рабочих нагрузок. После защиты рабочей нагрузки параметр заблокирован и не может быть изменен.
Вы можете включить CRR в существующих сейфах GRS. Вы не можете отключить CRR после включения.
Поведение, когда все регионы работоспособны
В этом разделе описывается, чего ожидать, когда сейфы настроены на использование геоизбыточного хранилища и все регионы работают.
Операция между регионами: Резервные копии всегда выполняются в основном регионе, который является регионом, в котором развертываются хранилище и источник данных.
Репликация данных между регионами: Если хранилище настроено на использование GRS, резервные копии сначала фиксируются в основном регионе с помощью локально избыточного хранилища (LRS). После успешного завершения в основном регионе данные асинхронно реплицируются в дополнительный регион, где он хранится с помощью LRS. Для репликации резервных данных из основного региона в дополнительный регион может потребоваться до 12 часов.
Поведение во время сбоя региона
В этом разделе описывается, чего ожидать, когда хранилища настроены на использование геоизбыточного хранения и при возникновении сбоя в основном регионе.
Обнаружение и ответ: Для источников данных, поддерживающих восстановление между регионами и если в хранилище включено восстановление между регионами, можно инициировать собственное восстановление между регионами в парном регионе в любое время, в том числе во время сбоя региона или катастрофы. Вы несете ответственность за обнаружение сбоя и выполнение любых действий восстановления, включая восстановление резервных копий в работоспособном регионе.
Для всех других сценариев данные, реплицируемые в дополнительный регион, доступны для восстановления в дополнительном регионе только в том случае, если #REF! объявляет аварию в основном регионе. Корпорация Майкрософт несет ответственность за объявление такой аварии. Время, необходимое для объявления аварии, зависит от серьезности инцидента и времени, необходимого для оценки ситуации. Скорее всего, он будет выполнен только после длительного периода времени.
Уведомление. Корпорация Майкрософт не уведомляет вас об отключении региона. Тем не менее
Вы можете использовать #REF! Работоспособность ресурсов для отслеживания работоспособности отдельного ресурса и настроить оповещения Работоспособность ресурсов для уведомления о проблемах.
Вы можете использовать Работоспособность служб Azure для понимания общего состояния службы, включая сбои в любом регионе, и настроить оповещения Service Health для уведомления о проблемах.
Ожидаемая потеря данных: RPO для данных резервного копирования зависит от нескольких факторов, включая расписание резервного копирования. Как правило, для сбоя региона следует ожидать до 36 часов потери данных, так как RPO в основном регионе составляет 24 часа, и для репликации резервных данных из первичного в дополнительный регион может потребоваться до 12 часов.
Ожидаемое время простоя: RTO отличается для каждого из следующих сценариев:
- Источники данных и другие ресурсы в неудачном регионе могут быть недоступны до тех пор, пока регион не восстановится, поэтому RTO не определен.
- Azure Backup не сможет выполнять операции резервного копирования или восстановления в неработоспособном регионе до восстановления региона, поэтому RTO не определен.
- Если вы используете восстановление между регионами, RTO для начала восстановления резервных копий, которые уже были реплицированы в парный регион, равен нулю. Если вы не используете восстановление между регионами, RTO зависит от того, сколько времени требуется для того, чтобы корпорация Майкрософт объявила об аварии в неудачном регионе.
Задания резервного копирования не могут выполняться, пока основной регион находится в автономном режиме. Вы можете восстановить данные в хранилище, но не добавлять новые данные.
Перераспределение: Задания резервного копирования не могут выполняться, пока основной регион находится в автономном режиме. Вы можете восстановить данные в хранилище, но не добавлять новые данные.
Вы несете ответственность за восстановление резервного копирования в инфраструктуру в парном регионе и перенастройку всех подсистем балансировки нагрузки, клиентов и других систем для перенаправления трафика в здоровую инфраструктуру в парном регионе.
Восстановление региона
При восстановлении основного региона Azure Backup автоматически восстанавливает операции в регионе. Возобновление заданий и данные остаются доступными.
Тестирование сбоев в регионе
Для выполнения операции восстановления в сопряженном регионе можно использовать функцию межрегионального восстановления. Этот подход можно использовать для проверки процесса восстановления данных и других процедур восстановления.
Устойчивость к потере данных резервного копирования
Azure Backup предоставляет две функции восстановления ключей, чтобы предотвратить случайное или вредоносное удаление данных резервной копии:
Мягкое удаление позволяет восстанавливать удаленные объекты и хранилища в течение настраиваемого периода. По умолчанию этот период составляет 14 дней, но его можно настроить. Подумайте о мягком удалении, как о корзине для бумаг для ваших резервных копий и архивов. Дополнительные сведения см. в разделе Безопасность по умолчанию с мягким удалением для Azure Backup.
Неизменяемые хранилища помогают защитить данные резервного копирования, блокируя любые операции, которые могут привести к потере точек восстановления. Вы можете заблокировать неизменяемую настройку хранилища, чтобы сделать её необратимой. Вы также можете использовать хранилище WORM (однократной записи и многократного чтения) для резервных копий, чтобы предотвратить отключение неизменяемости и, следовательно, удаление резервных копий злоумышленниками. Дополнительные сведения см. в разделе Незыблемое хранилище для Azure Backup.
Соглашение об уровне обслуживания
Соглашение об уровне обслуживания (SLA) для служб #REF! описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе SLAs для онлайн-сервисов.
Соглашение об уровне обслуживания Azure Backup охватывает доступность службы как для операций резервного копирования, так и для восстановления. Для покрытия соглашением об уровне обслуживания необходимо повторить выполнение заданий резервного копирования или восстановления не реже, чем каждые тридцати минут.