Skip to content

Files

Latest commit

seesharprunseesharprun
Change author williamdassafmsft -> seesharprun
Jun 5, 2022
adf4644 · Jun 5, 2022

History

History
155 lines (91 loc) · 15.5 KB

continuous-backup-restore-introduction.md

File metadata and controls

155 lines (91 loc) · 15.5 KB
title description author ms.service ms.topic ms.date ms.author ms.reviewer ms.custom
Continuous backup with point in time restore feature in Azure Cosmos DB
Azure Cosmos DB's point-in-time restore feature helps to recover data from an accidental write, delete operation, or to restore data into any region. Learn about pricing and current limitations.
kanshiG
cosmos-db
conceptual
04/06/2022
govindk
mjbrown
references_regions, cosmos-db-video

Continuous backup with point-in-time restore in Azure Cosmos DB

[!INCLUDEappliesto-all-apis-except-cassandra]

Azure Cosmos DB's point-in-time restore feature helps in multiple scenarios such as the following:

  • To recover from an accidental write or delete operation within a container.
  • To restore a deleted account, database, or a container.
  • To restore into any region (where backups existed) at the restore point in time.

[!VIDEO https://aka.ms/docs.continuous-backup-restore]

Azure Cosmos DB performs data backup in the background without consuming any extra provisioned throughput (RUs) or affecting the performance and availability of your database. Continuous backups are taken in every region where the account exists. The following image shows how a container with write region in West US, read regions in East and East US 2 is backed up to a remote Azure Blob Storage account in the respective regions. By default, each region stores the backup in Locally Redundant storage accounts. If the region has Availability zones enabled then the backup is stored in Zone-Redundant storage accounts.

:::image type="content" source="./media/continuous-backup-restore-introduction/continuous-backup-restore-blob-storage.png" alt-text="Azure Cosmos DB data backup to the Azure Blob Storage." lightbox="./media/continuous-backup-restore-introduction/continuous-backup-restore-blob-storage.png" border="false":::

The available time window for restore (also known as retention period) is the lower value of the following two: 30 days back in past from now or up to the resource creation time. The point in time for restore can be any timestamp within the retention period. In strong consistency mode, backup taken in the write region is more up to date when compared to the read regions. Read regions can lag behind due to network or other transient issues. While doing restore, you can get latest restorable timestamp for a given resource in that region to ensure that the resource has taken backups up to the given timestamp and can restore in that region.

Currently, you can restore the Azure Cosmos DB account for SQL API or MongoDB contents point in time to another account via the Azure portal, the Azure CLI (az CLI), Azure PowerShell, or Azure Resource Manager templates. Table API or Gremlin APIs are in preview and supported through Azure CLI (az CLI) and Azure PowerShell.

Backup storage redundancy

By default, Azure Cosmos DB stores continuous mode backup data in locally redundant storage blobs. For the regions that have zone redundancy configured, the backup is stored in zone-redundant storage blobs. In continuous backup mode, you can't update the backup storage redundancy.

What is restored?

In a steady state, all mutations performed on the source account (which includes databases, containers, and items) are backed up asynchronously within 100 seconds. If the backup media (that is Azure storage) is down or unavailable, the mutations are persisted locally until the media is available back and then they are flushed out to prevent any loss in fidelity of operations that can be restored.

You can choose to restore any combination of provisioned throughput containers, shared throughput database, or the entire account. The restore action restores all data and its index properties into a new account. The restore process ensures that all the data restored in an account, database, or a container is guaranteed to be consistent up to the restore time specified. The duration of restore will depend on the amount of data that needs to be restored.

Note

With the continuous backup mode, the backups are taken in every region where your Azure Cosmos DB account is available. Backups taken for each region account are Locally redundant by default and Zone redundant if your account has availability zone feature enabled for that region. The restore action always restores data into a new account.

What is not restored?

The following configurations aren't restored after the point-in-time recovery:

  • Firewall, VNET, private endpoint settings.
  • Consistency settings. By default, the account is restored with session consistency.  
  • Regions.
  • Stored procedures, triggers, UDFs.

You can add these configurations to the restored account after the restore is completed.

Restorable timestamp for live accounts

To restore Azure Cosmos DB live accounts that are not deleted, it is a best practice to always identify the latest restorable timestamp for the container. You can then use this timestamp to restore the account to its latest version.

Restore scenarios

The following are some of the key scenarios that are addressed by the point-in-time-restore feature. Scenarios [1] through [3] demonstrate how to trigger a restore if the restore timestamp is known beforehand. However, there could be scenarios where you don't know the exact time of accidental deletion or corruption. Scenarios [4] and [5] demonstrate how to discover the restore timestamp using the new event feed APIs on the restorable database or containers.

:::image type="content" source="./media/continuous-backup-restore-introduction/restorable-account-scenario.png" alt-text="Life-cycle events with timestamps for a restorable account." lightbox="./media/continuous-backup-restore-introduction/restorable-account-scenario.png" border="false":::

  1. Restore deleted account - All the deleted accounts that you can restore are visible from the Restore pane. For example, if Account A is deleted at timestamp T3. In this case the timestamp just before T3, location, target account name, resource group, and target account name is sufficient to restore from Azure portal, PowerShell, or CLI.

    :::image type="content" source="./media/continuous-backup-restore-introduction/restorable-container-database-scenario.png" alt-text="Life-cycle events with timestamps for a restorable database and container." lightbox="./media/continuous-backup-restore-introduction/restorable-container-database-scenario.png" border="false":::

  2. Restore data of an account in a particular region - For example, if Account A exists in two regions East US and West US at timestamp T3. If you need a copy of account A in West US, you can do a point in time restore from Azure portal, PowerShell, or CLI with West US as the target location.

  3. Recover from an accidental write or delete operation within a container with a known restore timestamp - For example, if you know that the contents of Container 1 within Database 1 were modified accidentally at timestamp T3. You can do a point in time restore from Azure portal, PowerShell, or CLI into another account at timestamp T3 to recover the desired state of container.

  4. Restore an account to a previous point in time before the accidental delete of the database - In the Azure portal, you can use the event feed pane to determine when a database was deleted and find the restore time. Similarly, with Azure CLI and PowerShell, you can discover the database deletion event by enumerating the database events feed and then trigger the restore command with the required parameters.

  5. Restore an account to a previous point in time before the accidental delete or modification of the container properties. - In Azure portal, you can use the event feed pane to determine when a container was created, modified, or deleted to find the restore time. Similarly, with Azure CLI and PowerShell, you can discover all the container events by enumerating the container events feed and then trigger the restore command with required parameters.

Permissions

Azure Cosmos DB allows you to isolate and restrict the restore permissions for continuous backup account to a specific role or a principal. The owner of the account can trigger a restore and assign a role to other principals to perform the restore operation. To learn more, see the Permissions article.

Pricing

Azure Cosmos DB accounts that have continuous backup enabled will incur an additional monthly charge to store the backup and to restore your data. The restore cost is added every time the restore operation is initiated. If you configure an account with continuous backup but don't restore the data, only backup storage cost is included in your bill.

The following example is based on the price for an Azure Cosmos account deployed in West US. The pricing and calculation can vary depending on the region you are using, see the Azure Cosmos DB pricing page for latest pricing information.

  • All accounts enabled with continuous backup policy incur an additional monthly charge for backup storage that is calculated as follows:

    $0.20/GB * Data size in GB in account * Number of regions

  • Every restore API invocation incurs a one time charge. The charge is a function of the amount of data restore and it is calculated as follows:

    $0.15/GB * Data size in GB.

For example, if you have 1 TB of data in two regions then:

  • Backup storage cost is calculated as (1000 * 0.20 * 2) = $400 per month

  • Restore cost is calculated as (1000 * 0.15) = $150 per restore

Tip

For more information about measuring the current data usage of your Azure Cosmos DB account, see Explore Azure Monitor Cosmos DB insights.

Customer-managed keys

See How do customer-managed keys affect continuous backups? to learn:

  • How to configure your Azure Cosmos DB account when using customer-managed keys in conjunction with continuous backups.
  • How do customer-managed keys affect restores?

Current limitations

Currently the point in time restore functionality has the following limitations:

  • Azure Cosmos DB APIs for SQL and MongoDB are supported for continuous backup. Cassandra API is not supported at present

  • Table API and Gremlin API are in preview and supported via PowerShell and Azure CLI.

  • Multi-regions write accounts are not supported.

  • Azure Synapse Link and periodic backup mode can coexist in the same database account. However, analytical store data isn't included in backups and restores. When Synapse Link is enabled, Azure Cosmos DB will continue to automatically take backups of your data in the transactional store at a scheduled backup interval.

  • Azure Synapse Link and continuous backup mode can't coexist in the same database account. Currently database accounts with Synapse Link enabled can't use continuous backup mode and vice-versa.

  • The restored account is created in the same region where your source account exists. You can't restore an account into a region where the source account did not exist.

  • The restore window is only 30 days and it cannot be changed.

  • The backups are not automatically geo-disaster resistant. You have to explicitly add another region to have resiliency for the account and the backup.

  • While a restore is in progress, don't modify or delete the Identity and Access Management (IAM) policies that grant the permissions for the account or change any VNET, firewall configuration.

  • Azure Cosmos DB API for SQL or MongoDB accounts that create unique index after the container is created are not supported for continuous backup. Only containers that create unique index as a part of the initial container creation are supported. For MongoDB accounts, you create unique index using extension commands.

  • The point-in-time restore functionality always restores to a new Azure Cosmos account. Restoring to an existing account is currently not supported. If you are interested in providing feedback about in-place restore, contact the Azure Cosmos DB team via your account representative.

  • After restoring, it is possible that for certain collections the consistent index may be rebuilding. You can check the status of the rebuild operation via the IndexTransformationProgress property.

  • The restore process restores all the properties of a container including its TTL configuration. As a result, it is possible that the data restored is deleted immediately if you configured that way. In order to prevent this situation, the restore timestamp must be before the TTL properties were added into the container.

  • Unique indexes in API for MongoDB can't be added or updated when you create a continuous backup mode account or migrate an account from periodic to continuous mode.

  • Continuous mode restore may not restore throughput setting valid as of restore point.

Next steps