Поделиться через

Планирование аварийного восстановления службы хранилища Azure и переход на резервное хранилище

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

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

Выберите правильный вариант резервирования

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

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

По сравнению с межзональным резервным хранением (ZRS) сохраняется копия учетной записи хранилища и реплицируется в каждой из трех отдельных зон доступности в одном регионе. Дополнительные сведения о зонах доступности см. в разделе "Зоны доступности Azure".

Геоизбыточное хранилище и переключение при отказе

Геоизбыточное хранилище (GRS), геозонально-избыточное хранилище (GZRS) и хранилище с доступом для чтения в геозонально-избыточном режиме (RA-GZRS) — это примеры географически избыточных вариантов хранилищ. При настройке использования геоизбыточного хранилища (GRS, GZRS и RA-GZRS) Azure копирует данные асинхронно в дополнительный географический регион. Эти регионы находятся сотни или даже тысячи миль от него. Этот уровень избыточности позволяет восстановить данные, если в основном регионе произошел сбой.

В отличие от LRS и ZRS, геоизбыточное хранилище также обеспечивает поддержку восстановления при сбое на вторичный регион, если в основном регионе произошла утрата. Во время переключения при отказе записи DNS (системы доменных имен) для конечных точек службы учетной записи хранилища автоматически обновляются таким образом, чтобы конечные точки вторичного региона стали новыми основными конечными точками. После завершения незапланированного переключения на резервный сервер клиенты могут начать запись данных в новые основные конечные точки.

Геоизбыточное хранилище для чтения (RA-GRS) и геозонально-избыточное хранилище для чтения (RA-GZRS) также предоставляют геоизбыточное хранилище, но предлагают дополнительное преимущество доступа для чтения к вторичной конечной точке. Эти варианты идеально подходят для приложений, предназначенных для приложений с высоким уровнем доступности, критически важных для бизнеса. Если основная конечная точка испытывает сбой, приложения, настроенные для доступа на чтение к дополнительному региону, могут продолжать работать. Корпорация Майкрософт рекомендует RA-GZRS для обеспечения максимальной доступности и устойчивости учетных записей хранения.

Дополнительные сведения о избыточности службы хранилища Azure см. в статье о избыточности службы хранилища Azure.

План аварийного переключения

В учетных записях хранения Azure поддерживаются три типа аварийного переключения:

1 Отказоустойчивость, управляемая корпорацией Майкрософт, не может быть инициирована для отдельных учетных записей хранения, подписок или арендаторов. Дополнительные сведения см. в статье Отработка отказа под управлением корпорации Майкрософт.
2 Используйте управляемые клиентом варианты отработки отказа для разработки, тестирования и внедрения планов восстановления после аварий. Не полагайтесь на отработку отказа, управляемую корпорацией Microsoft, которая будет использоваться только в чрезвычайных обстоятельствах.

Каждый тип переключения на резерв имеет уникальный набор применений, ожидаемые потери данных и поддержку учетных записей с включенным иерархическим пространством имен (Azure Data Lake Storage). В этой таблице перечислены аспекты каждого типа отработки отказа:

Тип Область переключения при отказе Сценарий использования Ожидаемая потеря данных Поддержка иерархического пространства имен (HNS)
Управляемая клиентом отработка отказа (предварительная версия) учетная запись хранения Доступны конечные точки службы хранилища для основных и вторичных регионов, и вы хотите провести тестирование аварийного восстановления.

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

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

Вы получили уведомление Azure, в котором корпорация Майкрософт советует произвести переключение на резерв для учетных записей хранения, которые потенциально могут быть затронуты сбоем.		 Да Да
Управляемое корпорацией Майкрософт Весь регион Основной регион становится недоступным из-за значительной аварии, но дополнительный регион доступен. Да Да

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

Результат переключения в случае отказа на... Управляемая клиентом отработка отказа (предварительная версия) Управляемое клиентом (незапланированное) переключение на резервный ресурс
... вторичный регион Дополнительный регион становится новым первичным Дополнительный регион становится новым первичным
... исходный основной регион Исходный основной регион становится новым вторичным Копия данных в исходном основном регионе удаляется
... Конфигурация резервной системы учетной записи Учетная запись для хранения преобразована в GRS Учетная запись хранения преобразуется в LRS
... конфигурация геоизбыточности Георезервирование сохраняется Геоизбыточность утрачена

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

Исходный текст
конфигурация		 После
переключение на резерв		 После повторного включения
геоизбыточность		 После
отказоустойчивое восстановление		 После повторного включения
геоизбыточность
Плановая процедура отказа с управлением клиентом
ГРС ГРС н/д 1 ГРС н/д 1
GZRS ГРС н/д 1 GZRS н/д 1
Управляемая клиентом (незапланированная) отказоустойчивость
ГРС Система регистрации и отслеживания (LRS) ГРС Система регистрации и отслеживания (LRS) ГРС
GZRS Система регистрации и отслеживания (LRS) ГРС ZRS GZRS

1 Геоизбыточность сохраняется во время запланированного переключения и не требует ручной перенастройки.

Управляемая клиентом отработка отказа (предварительная версия)

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

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

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

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

Это важно

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

Управляемое клиентом (незапланированное) переключение на резервный ресурс

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

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

Отказоустойчивость под управлением Microsoft

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

Это важно

Используйте управляемые клиентом опции аварийного переключения для разработки, тестирования и реализации планов аварийного восстановления. Не полагайтесь на отказоустойчивость, управляемую Microsoft, которая может использоваться только в случае чрезвычайных обстоятельств. Переключение при отказе, под управлением корпорации Майкрософт, может быть инициировано для всего физического подразделения, например региона или центра обработки данных. Его нельзя инициировать для отдельных учетных записей хранения, подписок или клиентов. Если вам нужна возможность выборочной отработки отказа отдельных учетных записей хранения, используйте управляемую клиентом отработку отказа.

Прогнозирование потери данных и несоответствий

Осторожность

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

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

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

Новый основной регион настроен для локальной избыточности (LRS) после аварийного восстановления.

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

Время последней синхронизации

Свойство Last Sync Time указывает последнее время записи данных из основного региона в дополнительный регион. Для учетных записей, имеющих иерархическое пространство имен, то же свойство Времени последней синхронизации также применяется к метаданным, управляемым иерархическим пространством имен, включая списки управления доступом (ACL). Все данные и метаданные, записанные до последнего времени синхронизации, доступны на вторичной стороне. В отличие от этого, данные и метаданные, записанные после последнего времени синхронизации, могут еще не быть скопированы в резервный и потенциально могут быть потеряны. Во время сбоя используйте это свойство для оценки объема потери данных при переключении учетной записи.

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

Дополнительные сведения о проверке свойства Время последней синхронизации см. в статье Проверка свойства "Время последней синхронизации" для учетной записи хранения.

Согласованность файлов для Azure Data Lake Storage

Репликация учетных записей хранения с включенным иерархическим пространством имен (Azure Data Lake Storage) происходит на уровне файла. Так как репликация происходит на этом уровне, сбой в основном регионе может препятствовать успешной репликации некоторых файлов в контейнере или каталоге в дополнительный регион. Согласованность всех файлов в контейнере или каталоге после переключения на резервную учетную запись хранения не гарантируется.

Несоответствия данных потока изменений и данных BLOB (бинарных больших объектов)

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

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

Дополнительные сведения о веб-канале изменений см. в разделе "Как работает веб-канал изменений".

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

Несоответствия восстановления по состоянию на определенный момент времени

Переключение на резервное решение, управляемое клиентом, поддерживается для учетных записей хранения уровня "Стандартный" версии 2, которые включают блокирующие BLOB-объекты. Однако при выполнении аварийного переключения под управлением клиента в учетной записи хранения сбрасывается самая ранняя возможная точка восстановления для неё. Данные для точечного восстановления блочных BLOB-объектов согласованы только до времени завершения переключения в случае отказа. В результате можно восстановить только блоки BLOB до определённого момента во времени, не раньше времени завершения переключения на резервный сервер. Время завершения переключения вы можете проверить на вкладке «Избыточность» учетной записи хранения данных на портале Azure.

Время и стоимость переключения при отказе

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

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

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

Вы можете повторно включить геоизбыточное хранилище (GRS) или доступ для чтения к геоизбыточному хранилищу (RA-GRS) для учетной записи, но повторная репликация данных в новый дополнительный регион подлежит оплате. Кроме того, перед перенастройкой учетной записи для геоизбыточности необходимо восстановить архивированные BLOB-объекты на сетевой уровень. Эта регенерация также влечет за собой дополнительные расходы. Дополнительные сведения о ценах см. в следующем разделе:

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

  • Число и размер объектов в учетной записи хранения. Репликация множества небольших объектов может занять больше времени, чем репликация меньше и больше объектов.
  • Доступные ресурсы для фоновой репликации, такие как ЦП, память, диск и пропускная способность WAN. Динамический трафик имеет приоритет над георепликацией.
  • Количество снимков на один блоб, если применимо.
  • Стратегия секционирования данных, если учетная запись хранения содержит таблицы. Процесс репликации не может масштабироваться сверх количества используемых ключей разделов.

Поддерживаемые типы учетных записей хранения

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

Тип переключения ГРС/RA-GRS GZRS или RA-GZRS
Управляемая клиентом отработка отказа (предварительная версия) Учетные записи общего назначения версии 2
Учетные записи общего назначения версии 1
Устаревшие учетные записи хранения BLOB-объектов		 Учетные записи общего назначения версии 2
Управляемая клиентом (незапланированная) отказоустойчивость Учетные записи общего назначения версии 2
Учетные записи общего назначения версии 1
Устаревшие учетные записи хранения BLOB-объектов		 Учетные записи общего назначения версии 2
Отказоустойчивость под управлением Майкрософт Все типы учетных записей Учетные записи общего назначения версии 2

Классические учетные записи хранения

Это важно

Отказоустойчивость, управляемая клиентом, поддерживается только для учетных записей хранения, развернутых с использованием модели развертывания Azure Resource Manager (ARM). Модель развертывания Azure Service Manager (ASM), которая также называется классической моделью, не поддерживается. Чтобы сделать классические учетные записи хранилища подходящими для аварийного переключения управляемых клиентом учетных записей, сначала их необходимо перенести в модель ARM. Учетная запись хранения должна быть доступна для выполнения обновления, поэтому основной регион в настоящее время не может находиться в состоянии сбоя.

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

Неподдерживаемые функции и службы

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

  • Синхронизация файлов Azure не поддерживает отказоустойчивость, управляемую клиентом. Учетные записи хранения, используемые в качестве облачных конечных точек для синхронизации файлов Azure, не должны перебрасываться на резервное копирование. Переключение на резервный ресурс нарушает синхронизацию файлов и может привести к непредвиденной потере данных новых файлов, размещенных на нескольких уровнях. Дополнительные сведения см. в рекомендациях по аварийному восстановлению с помощью службы "Синхронизация файлов Azure ".
  • Резервное переключение учетной записи хранения, содержащей блоковые BLOB-объекты класса Premium, невозможно. Учетные записи хранения, поддерживающие премиум блок-объекты, в настоящее время не поддерживают геоизбыточность.
  • Переключение при отказе, управляемое клиентом, не поддерживается для источниковой или целевой учетной записи в политике репликации объектов.
  • Сетевая файловая система (NFS) 3.0 (NFSv3) не поддерживается для отказоустойчивости учетных записей хранилища. Нельзя создать учетную запись хранения, настроенную для геоизбыточности с включенным NFSv3.

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

Плановое переключение на резервную систему Внеплановое переключение
Azure Data Lake Storage Поддерживается (предварительная версия) Поддерживается
Лента изменений Не поддерживается Поддерживается
Репликация объектов Не поддерживается Не поддерживается
SFTP Поддерживается (предварительная версия) Поддерживается
NFSv3 GRS не поддерживается GRS не поддерживается
Действия хранилища Поддерживается1 Поддерживается1
Восстановление на определенный момент времени (PITR) Не поддерживается Поддерживается

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

Переключение на резервный канал не предназначено для миграции аккаунтов.

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

Учетные записи хранения, содержащие архивированные BLOB-объекты

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

Поставщик ресурсов хранилища

Корпорация Microsoft предоставляет два интерфейса API для работы с ресурсами службы хранилища Azure. Эти API образуют базу для всех действий, которые можно выполнять с хранилищем Azure. API REST Azure Storage позволяет работать с данными в аккаунте хранилища, включая данные BLOB, очередей, файлов и таблиц. REST API поставщика ресурсов службы хранилища Azure позволяет управлять учетной записью хранения и связанными ресурсами.

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

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

Виртуальные машины Azure

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

Неуправляемые диски Azure

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

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

  1. Прежде чем начать, запишите имена всех неуправляемых дисков, их логические номера единиц (LUN) и виртуальную машину, к которой они подключены. Это позволит упростить повторное подключение дисков после переключения в случае отказа.
  2. Выключите виртуальную машину.
  3. Удалите виртуальную машину, но сохраните файлы виртуального жесткого диска (VHD) для неуправляемых дисков. Запишите время удаления виртуальной машины.
  4. Подождите, пока не будет обновлено время последней синхронизации , и убедитесь, что оно позже, чем время удаления виртуальной машины. Этот шаг гарантирует, что вторичная конечная точка полностью обновляется с помощью VHD-файлов при отработке отказа и правильно работает виртуальная машина в новом основном регионе.
  5. Запустите переключение учетной записи на резерв.
  6. Дождитесь завершения отработки отказа учетной записи, а дополнительный регион станет новым основным регионом.
  7. Создайте виртуальную машину в новом основном регионе и повторно подключите жесткие диски.
  8. Запустите новую виртуальную машину.

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

Копирование данных как запасной вариант при отказе системы

Как уже говорилось ранее, вы можете поддерживать высокий уровень доступности, настроив приложения для использования учетной записи хранения, настроенной для доступа на чтение к дополнительному региону. Однако, если вы предпочитаете не переключаться на резервное копирование данных во время сбоя в основном регионе, можно вручную перенести ваши данные в качестве альтернативы. Такие средства, как AzCopy и Azure PowerShell , позволяют копировать данные из учетной записи хранения в затронутом регионе в другую учетную запись хранения в небезопасном регионе. После завершения операции копирования можно перенастроить приложения для использования учетной записи хранения в неподверженном регионе для доступности чтения и записи.

Проектирование высокого уровня доступности

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

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

  • Дисков:Используйте Azure Backup для резервного копирования дисков виртуальных машин, используемых виртуальными машинами Azure. Кроме того, рекомендуется использовать Azure Site Recovery для защиты виртуальных машин от региональной аварии.
  • Блочные BLOB-объекты: Включите мягкое удаление для защиты от удаления и перезаписи на уровне объекта или для копирования блочных BLOB-объектов в другую учетную запись хранения в другой регион с помощью AzCopy, Azure PowerShell или библиотеки перемещения данных Azure.
  • Файлы:Используйте Azure Backup для резервного копирования общих папок. Также включите мягкое удаление для защиты от случайных удалений обмена файлами. Для геоизбыточности, если GRS недоступен, используйте AzCopy или Azure PowerShell для копирования файлов в другую учетную запись хранения в другом регионе.
  • Таблицы: Используйте AzCopy для экспорта данных таблицы в другую учетную запись хранения в другом регионе.

Отслеживание отключений

Клиенты могут подписаться на панель мониторинга работоспособности служб Azure , чтобы отслеживать работоспособность и состояние службы хранилища Azure и других служб Azure.

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

См. также