Непрерывное резервное копирование с восстановлением до точки во времени в Azure Cosmos DB

  • Статья

Область применения: Nosql Mongodb Гремлин Таблица

Функция восстановления до точки во времени в Azure Cosmos DB предназначена для использования в следующих сценариях:

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

Azure Cosmos DB выполняет резервное копирование данных в фоновом режиме, не используя дополнительную пропускную способность (ЕЗ) и не снижая производительность и доступность базы данных. Непрерывное резервное копирование выполняется в каждом регионе, где существует учетная запись. Например, учетная запись может иметь регион записи в регионе "Западная часть США" и регионы чтения в регионах "Восточная часть США" и "Восточная часть США 2". Затем для этих регионов реплик можно настроить резервное копирование в удаленные учетные записи хранения Azure в каждом соответствующем регионе. По умолчанию в каждом регионе хранится резервная копия в учетных записях локально избыточного хранилища. Если в регионе включены Зоны доступности, то резервная копия хранится в учетных записях хранилища, избыточного между зонами.

Схема: резервное копирование контейнера в нескольких регионах.

Период времени, доступный для восстановления (также известный как период хранения), является более низким значением следующих двух вариантов: 30-дневный и 7-дневный.

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

В настоящее время можно восстановить содержимое учетной записи Azure Cosmos DB (API для NoSQL или MongoDB, API для таблиц, API для Gremlin) в определенный момент времени в другую учетную запись. Эту операцию восстановления можно выполнить на портале Azure, с помощью Azure CLI (Azure CLI), Azure PowerShell или шаблонов Azure Resource Manager.

Избыточность хранилища резервных копий

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

Различные способы восстановления

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

Восстановление учетной записи в нескольких регионах (предварительная версия)

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

Примечание.

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

Что не восстанавливается для восстановления учетной записи с несколькими регионами (предварительная версия)?

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

Пример. Учитывая учетную запись с несколькими регионами с двумя регионами "Восточная часть сша" и "Западная часть", из которых восточная часть США является концентратором, рассмотрите следующую последовательность событий:

В этом сценарии, если метка времени восстановления — T3, восстанавливается только сущность1. Entity2 не было подтверждено областью концентратора T3. Только если метка > времени восстановления T4, сущность2 будет восстановлена. T1: клиент записывает документ Doc1 в восточную часть США. (Так как восточная часть США — это центральный регион, запись немедленно подтверждается)
T2: клиент записывает документ Doc2 на западную часть США. T3: Западная часть США отправляет Doc2 в Восточную часть США для подтверждения. T4: Восточная часть США получает Doc2, подтверждает документ и отправляет Doc2 обратно в западную часть США. T5: Западная часть США получает подтвержденный Doc2.

В этом сценарии, если указана метка времени восстановления— T3, будет восстановлена только doc1. Doc2 не был подтвержден концентратором T3. Только если метка > времени восстановления T4, doc2 будет восстановлена.

Примечание.

Восстановление в концентраторе поддерживается в общедоступной предварительной версии.

Что восстанавливается в новой учетной записи?

В стабильном состоянии все изменения, выполненные в исходной учетной записи (включая базы данных, контейнеры и элементы), архивируются асинхронно в течение 100 секунд. Если носитель резервной копии службы хранилища Azure отключен или недоступен, изменения сохраняются локально до тех пор, пока носитель не станет доступен. Затем изменения записываются удаленно, чтобы предотвратить потери в точности операций, которые можно восстановить.

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

Примечание.

В режиме непрерывного резервного копирования резервные копии выполняются в каждом регионе, где доступна ваша учетная запись Azure Cosmos DB. Резервные копии, созданные для каждой учетной записи региона, локально избыточны по умолчанию; если в вашей учетной записи включена функция зона доступности для этого региона, резервные копии избыточны между зонами. Восстановление всегда восстанавливает данные в новую учетную запись.

Что не восстанавливается?

Следующие конфигурации не восстанавливаются после восстановления до точки во времени:

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

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

Восстанавливаемая метка времени для динамических учетных записей

Чтобы восстановить действующие учетные записи Azure Cosmos DB, которые не были удалены, рекомендуется всегда определять последнюю восстанавливаемую метку времени для контейнера. Затем эту метку времени можно использовать для восстановления учетной записи до ее последней версии.

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

Функция восстановления на определенный момент времени поддерживает следующие сценарии. В сценариях [1]–[3] показано, как запустить восстановление, если метка времени восстановления известна заранее. Однако возможны сценарии, когда точное время случайного удаления или повреждения неизвестно. В сценариях [4] и [5] показано, как обнаружить метку времени восстановления с помощью новых API-интерфейсов веб-канала событий в восстанавливаемой базе данных или контейнерах.

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

  1. Восстановление удаленной учетной записи — все удаленные учетные записи, которые можно восстановить, видны на панели Восстановление. Например, если Учетная запись A удаляется по метке времени T3. В этом случае метки времени перед T3, расположением, именем целевой учетной записи, группы ресурсов и именем целевой учетной записи достаточно для восстановления из портала Azure, PowerShell или CLI.

    События жизненного цикла с метками времени для восстанавливаемой базы данных и контейнера.

  2. Восстановление данных учетной записи в определенном регионе — например, если Учетная запись А существует в двух регионах: Восточная часть США и Западная часть США по метке времени T3. Если требуется копия учетной записи A в Западной части США, можно выполнить восстановление на момент времени с помощью портала Azure, PowerShell или CLI, указав Запад США в качестве целевого расположения.

  3. Восстановление после случайной операции записи или удаления в контейнере с известной меткой времени восстановления — например, если известно, что содержимое контейнера 1 в базе данных 1 было случайно изменено на метке времени T3. Вы можете выполнить восстановление на момент времени с помощью портала Azure, PowerShell или CLI в другую учетную запись с меткой времени T3, чтобы восстановить требуемое состояние контейнера.

  4. Восстановление учетной записи до предыдущей точки во времени перед случайным удалением базы данных — в портале Azure можно использовать панель веб-канала событий, чтобы определить, когда база данных была удалена, и найти время восстановления. Аналогично, с помощью Azure CLI и PowerShell можно обнаружить событие удаления базы данных, пересчитав веб-канал событий базы данных, а затем выполнив команду "Восстановить" с необходимыми параметрами.

  5. Восстановление учетной записи до предыдущей точки во времени перед случайным удалением или изменением свойств контейнера. — В портале Azure можно использовать панель веб-канала событий для определения времени создания, изменения или удаления контейнера, чтобы найти время восстановления. Аналогично, с помощью Azure CLI и PowerShell можно обнаружить все события контейнера, пересчитав веб-канал событий контейнера, а затем выполнив команду "Восстановить" с необходимыми параметрами.

Разрешения

Azure Cosmos DB позволяет изолировать и ограничить разрешения на восстановление для учетной записи непрерывного резервного копирования определенной ролью или субъектом. Дополнительные сведения см. в статье Разрешения.

Цены

Учетная запись Azure Cosmos DB с непрерывной 30-дневной резервной копией взимает дополнительную ежемесячную плату для хранения резервной копии. В уровнях с непрерывным резервным копированием с 30-дневным или 7-дневным копированием взимается плата за восстановление данных. Затраты на восстановление добавляются при каждом запуске операции восстановления. Если вы настраиваете учетную запись с непрерывной резервной копией, но не восстанавливаете данные, в счет включается только стоимость хранилища резервных копий.

Следующий пример основан на цене учетной записи Azure Cosmos DB, развернутой в западной части США. Цены и расчеты могут различаться в зависимости от используемого региона. Последние сведения о ценах см. на странице цен Azure Cosmos DB.

  • Для всех учетных записей с политикой непрерывного резервного копирования с 30-дневным хранением взимается ежемесячная плата за хранилище резервных копий, которая вычисляется следующим образом:

    Размер данных * $0,20/ГБ, в ГБ в учетной записи * число регионов

  • Каждый вызов API восстановления требует однократной оплаты. Плата является функцией объема восстановленных данных:

    Размер данных * $0,15/ГБ, в ГБ.

Например, если у вас есть 1 ТБ данных в двух регионах, то:

  • Стоимость хранилища резервных копий вычисляется как (1000 * 0,20 * 2) = $400 в месяц

  • Плата на восстановление рассчитывается как (1000 * 0,15) = $150 на одно восстановление

Совет

Дополнительные сведения об измерении текущего использования данных учетной записи Azure Cosmos DB см. в статье "Обзор аналитики Azure Monitor Azure Cosmos DB". На уровне с непрерывным резервным копированием с 7-дневным хранением не взимается плата за резервное копирование данных.

Различия между уровнями непрерывного резервного копирования с 30-дневным хранением и 7-дневным хранением

  • Период хранения для одного уровня составляет 30 дней, а для другого — 7 дней.
  • За хранилище резервных копий взимается плата за 30-дневный уровень хранения. 7-дневный уровень хранения не взимается.
  • Плата за восстановление взимается на обоих уровнях.

Ключи, управляемые клиентом

См. статью Как ключи, управляемые клиентом, влияют на непрерывное резервное копирование?, где описаны следующие аспекты:

  • настройка учетной записи Azure Cosmos DB при использовании ключей, управляемых клиентом, в сочетании с непрерывным резервным копированием;
  • Как влияет на восстановление резервных копий использование ключей, управляемых клиентом?

Текущие ограничения

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

  • API Azure Cosmos DB для SQL, MongoDB, Gremlin и Таблицы, поддерживаемые для непрерывного резервного копирования. API для Cassandra сейчас не поддерживается.

  • В настоящее время Azure Synapse Link можно включить в учетных записях базы данных непрерывного резервного копирования. Но обратная ситуация еще не поддерживается, невозможно включить непрерывную резервную копию в учетных записях базы данных с поддержкой Synapse Link. Аналитическое хранилище не включается в резервные копии. Дополнительные сведения о резервном и аналитическом хранилище см. в статье "Резервное копирование аналитического хранилища".

  • Восстановленная учетная запись создается в том же регионе, в котором находится исходная учетная запись. Нельзя восстановить учетную запись в регион, в котором исходная учетная запись не существовала ранее.

  • Окно восстановления составляет всего 30 дней для непрерывного 30-дневного уровня и семи дней для непрерывного 7-дневного уровня. Эти уровни можно переключать, но фактические значения (7 или 30) не могут быть изменены. Кроме того, если вы переходите с 30-дневного уровня на 7-дневный уровень, существует вероятность потери данных в течение нескольких дней после седьмого.

  • Резервные копии не поддерживают автоматическую устойчивость к отказам на уровне региона. Другой регион должен быть явно добавлен для устойчивости учетной записи и резервной копии.

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

  • Учетные записи Azure Cosmos DB для MongoDB с непрерывным резервным копированием не поддерживают создание уникального индекса для существующей коллекции. Для такой учетной записи необходимо создать уникальные индексы вместе с их коллекцией; его можно выполнить с помощью команд расширения коллекции.

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

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

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

  • Уникальные индексы в API для MongoDB нельзя добавить или обновить при создании учетной записи в режиме непрерывного резервного копирования. Их также нельзя изменить при переключении учетной записи с периодического режима на непрерывный.

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

Следующие шаги