Continuous backup with point in time restore feature in Azure Cosmos DB (original) (raw)

APPLIES TO:NoSQLMongoDBGremlinTable

Azure Cosmos DB's point-in-time restore feature helps in multiple scenarios including:

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. For example, an account can have a write region in West US and read regions in East US and East US 2. These replica regions can then be backed up to a remote Azure Storage account in each respective region. 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.

Diagram illustrating how a container is backed up across multiple regions.

The time window available for restore (also known as retention period) is the lower value of the following two options: 30-day & 7-day.

The selected option depends on the chosen tier of continuous backup. The point in time for restore can be any timestamp within the retention period no further back than the point when the resource was created. In strong consistency mode, backups taken in the write region are 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 the latest restorable timestamp for a given resource in a specific region. Referring to latest restorable timestamp helps to confirm resource backups are up to the given timestamp, and can restore in that region.

Currently, you can restore an Azure Cosmos DB account (API for NoSQL or MongoDB, API for Table, API for Gremlin) contents at a specific point in time to another account. You can perform this restore operation via the Azure portal, the Azure CLI (Azure CLI), Azure PowerShell, or Azure Resource Manager templates.

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.

Different ways to restore

Continuous backup mode supports two ways to restore deleted containers and databases. They can be restored into a new account as documented here or can be restored into an existing account as described here. The choice between these two modes depends on the scenarios. In most cases, it is preferred to restore deleted containers and databases into an existing account. This avoids the cost of data transfer that is required in the case they are restored to a new account. For scenario where accidental data modification was done, restore into new account could be the preferred option.

What is restored into a new account?

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 Azure Storage backup media is down or unavailable, the mutations are persisted locally until the media is available. Then the mutations 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. The newly restored database account’s consistency setting will be same as the source database account’s consistency settings.

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 isn't restored?

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

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 aren't deleted, it's 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

Point-in-time-restore feature supports following scenarios. 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.

Life-cycle events with timestamps for a restorable account.

  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.
    Life-cycle events with timestamps for a restorable database and container.
  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. To learn more, see the Permissions article.

Understanding Multi-region write account restore

Writes that are performed on the hub region are immediately confirmed and backed up asynchronously within 100 seconds. In multi-write accounts, any mutations performed on the satellite region are sent to hub region for confirmation. The hub region checks to see if any conflict resolution is needed, assigns a conflict-resolution timestamp after resolving the conflicts and sends back the document to satellite region. The satellite region only backs up the documents after the confirmation is received from the hub.
In short, the restore process only restores the documents confirmed by the hub region by the restore point of time.

What happens for restore for multi region write account?

Note

Restoring from satellite region is slower compared to restore in hub region for multi-region account to resolve local tentative writes as confirmed or take an action to roll them back.

More information about understanding timestamps in a multi write enable account can be found here.

Example scenario below: Given a multi-write region account with two regions East US and West US, out of which East US is the hub region, consider the following sequence of events:

T1: Client writes a document Doc1 to East US. (Since East US is the hub region, the write is immediately confirmed)

T2: Client writes a document Doc2 to West US

T3: West US sends Doc2 to East US for confirmation

T4: East US received Doc2, confirms the document and sends of Doc2 back to West US

T5: West US received confirmed Doc2

In this scenario, if the restore timestamp provided is T3 for hub region as source, only Doc1 will get restored. Doc2 has not been confirmed by hub by T3. Only if the restore timestamp is more than T4, the doc2 will get restored as restore at T4 in satellite contains only doc1 since doc2 is not confirmed yet.

Pricing

Azure Cosmos DB account with continuous 30-day backup has an extra monthly charge to store the backup. Both the 30-day and 7-day tier of continuous back incur charges 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 DB account deployed in West US. The pricing and calculation can vary depending on the region you're using, see the Azure Cosmos DB pricing page for latest pricing information.

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

Continuous 30-day tier vs Continuous 7-day tier

Time to live

Customer-managed keys

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

Current limitations

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

Next steps