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

Статья
06/09/2023

Область применения: 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 секунд. Если носитель резервной копии службы хранилища Azure отключен или недоступен, изменения сохраняются локально до тех пор, пока носитель не станет доступен. Затем изменения записываются удаленно, чтобы предотвратить потери в точности операций, которые можно восстановить.

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

Примечание.

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

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

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

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

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

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

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

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

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

Восстановление удаленной учетной записи — все удаленные учетные записи, которые можно восстановить, видны на панели Восстановление. Например, если Учетная запись A удаляется по метке времени T3. В этом случае метки времени перед T3, расположением, именем целевой учетной записи, группы ресурсов и именем целевой учетной записи достаточно для восстановления из портала Azure, PowerShell или CLI.
Восстановление данных учетной записи в определенном регионе — например, если Учетная запись А существует в двух регионах: Восточная часть США и Западная часть США по метке времени T3. Если требуется копия учетной записи A в Западной части США, можно выполнить восстановление на момент времени с помощью портала Azure, PowerShell или CLI, указав Запад США в качестве целевого расположения.
Восстановление после случайной операции записи или удаления в контейнере с известной меткой времени восстановления — например, если известно, что содержимое контейнера 1 в базе данных 1 было случайно изменено на метке времени T3. Вы можете выполнить восстановление на момент времени с помощью портала Azure, PowerShell или CLI в другую учетную запись с меткой времени T3, чтобы восстановить требуемое состояние контейнера.
Восстановление учетной записи до предыдущей точки во времени перед случайным удалением базы данных — в портале Azure можно использовать панель веб-канала событий, чтобы определить, когда база данных была удалена, и найти время восстановления. Аналогично, с помощью Azure CLI и PowerShell можно обнаружить событие удаления базы данных, пересчитав веб-канал событий базы данных, а затем выполнив команду "Восстановить" с необходимыми параметрами.
Восстановление учетной записи до предыдущей точки во времени перед случайным удалением или изменением свойств контейнера. — В портале 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 и Table, поддерживаемые для непрерывного резервного копирования. 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 в контейнер.
Уникальные индексы в API для MongoDB нельзя добавить или обновить при создании учетной записи в режиме непрерывного резервного копирования. Их также нельзя изменить при переключении учетной записи с периодического режима на непрерывный.
Восстановление в непрерывном режиме может не восстановить параметр пропускной способности, который действовал при создании точки восстановления.

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

Включите непрерывное резервное копирование с помощью портала Azure, PowerShell, CLI или Azure Resource Manager.
Получите последнюю метку времени с поддержкой восстановления для учетных записей SQL и MongoDB.
Восстановите учетную запись непрерывного резервного копирования с помощью портала Azure, PowerShell, интерфейса командной строки или Azure Resource Manager.
Переход на учетную запись с периодического резервного копирования на непрерывное.
Управление разрешениями для восстановления данных в режиме непрерывного резервного копирования
Модель ресурсов режима непрерывного резервного копирования