Непрерывное резервное копирование с восстановлением до точки во времени в 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 секунд. Если носитель резервной копии службы хранилища 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-дневный уровень хранения не взимается.
- Плата за восстановление взимается на обоих уровнях.
Срок жизни
- Процесс восстановления по умолчанию восстанавливает все свойства контейнера, включая конфигурацию TTL по умолчанию, это может привести к удалению данных, если восстановление выполняется без способа отключить TTL. Чтобы предотвратить удаление, передайте параметр, чтобы отключить TTL в PowerShell (-DisableTtl $true) или cli (--disable-ttl True) при восстановлении.
Ключи, управляемые клиентом
Узнайте , как управляемые клиентом ключи влияют на непрерывные резервные копии:
- настройка учетной записи Azure Cosmos DB при использовании ключей, управляемых клиентом, в сочетании с непрерывным резервным копированием;
- Как влияет на восстановление резервных копий использование ключей, управляемых клиентом?
Текущие ограничения
Сейчас функция восстановления на определенный момент времени имеет следующие ограничения.
API Azure Cosmos DB для SQL, MongoDB, Gremlin и Таблицы, поддерживаемые для непрерывного резервного копирования. API для Cassandra сейчас не поддерживается.
Multi region write
учетные записи не поддерживаются.Synapse Link для учетных записей баз данных с использованием режима непрерывного резервного копирования — это общедоступная версия. Обратная ситуация, режим непрерывного резервного копирования для учетных записей с поддержкой Synapse Link, находится в общедоступной предварительной версии. В настоящее время клиенты, которые отключили Synapse Link из контейнеров, не могут перенестися в непрерывное резервное копирование. Аналитическое хранилище не включается в резервные копии. Дополнительные сведения о резервном и аналитическом хранилище см. в статье "Резервное копирование аналитического хранилища".
Восстановленная учетная запись создается в том же регионе, в котором находится исходная учетная запись. Нельзя восстановить учетную запись в регион, в котором исходная учетная запись не существовала ранее.
Окно восстановления составляет всего 30 дней для непрерывного 30-дневного уровня и семи дней для непрерывного 7-дневного уровня. Эти уровни можно переключать, но фактические значения (
7
или30
) не могут быть изменены. Кроме того, если вы переходите с 30-дневного уровня на 7-дневный уровень, существует вероятность потери данных в течение нескольких дней после седьмого.Резервные копии не поддерживают автоматическую устойчивость к отказам на уровне региона. Другой регион должен быть явно добавлен для устойчивости учетной записи и резервной копии.
При выполнении восстановления не изменяйте и не удаляйте политики управления удостоверениями и доступом (IAM), предоставляющие разрешения для учетной записи на изменение любой виртуальной сети и конфигурации брандмауэра.
Учетные записи Azure Cosmos DB для MongoDB с непрерывным резервным копированием не поддерживают создание уникального индекса для существующей коллекции. Для такой учетной записи необходимо создать уникальные индексы вместе с их коллекцией; его можно выполнить с помощью команд расширения коллекции.
После восстановления для некоторых коллекций может запуститься перестройка согласованного индекса. Состояние операции перестроения можно проверить с помощью свойства IndexTransformationProgress.
Уникальные индексы в API для MongoDB нельзя добавлять, обновлять или удалять при создании учетной записи режима непрерывного резервного копирования. Их также нельзя изменить при переключении учетной записи с периодического режима на непрерывный.
Восстановление в непрерывном режиме может не восстановить параметр пропускной способности, который действовал при создании точки восстановления.
Следующие шаги
- Включите непрерывное резервное копирование с помощью портала Azure, PowerShell, CLI или Azure Resource Manager.
- Получите последнюю метку времени с поддержкой восстановления для учетных записей SQL и MongoDB.
- Восстановите учетную запись непрерывного резервного копирования с помощью портала Azure, PowerShell, интерфейса командной строки или Azure Resource Manager.
- Переход на учетную запись с периодического резервного копирования на непрерывное.
- Управление разрешениями для восстановления данных в режиме непрерывного резервного копирования
- Модель ресурсов режима непрерывного резервного копирования