Continuous Backups with Point-in-Time restores in Azure Cosmos DB

Azure Cosmos DB now provides us with the ability to continuously backup our data, allowing more granular control over our backups.

The ability to perform backups on your data is essential to ensure that you can recover in the event of any data failure, such as data corruption, human-error or datacenter failure.

Azure Cosmos DB takes backups of your data automatically at regular intervals without affecting the performance or availability of our database operations. This is great for when we encounter any of the data failures mentioned above.

There are two options available to us when we need to perform backups in Azure Cosmos DB:

• Periodic backup mode  — the default method of backing up our data
• Continuous backups or Point-In-Time Restores (In public preview) — Allows to to restore at any point in time within the last 30 days.

In this article, I’ll cover the following:

• What do we mean by periodic backups in Azure Cosmos DB?
• Alternative backup strategies before Point-in-Time Restores
• Introducing Point-In-Time Restores
• Configuring Continuous Backups in Azure Cosmos DB
• Current Limitations

By the end of this article, you’ll have an idea of what the differences are between Periodic and Continuous backups in Cosmos DB, how you can configure Continuous backups in your Cosmos DB account and how you can initiate a Point-In-Time restore.

What do we mean by Periodic Backups in Azure Cosmos DB?

Before continuous backups, Azure Cosmos would still perform backups every 4 hours. A snapshot of the backups would be stored in a Blob storage in the same region at the main write region that you’ve configured for your Cosmos DB account (Or one of the write regions for multi-region write accounts).

In case of regional disaster, each snapshot of the backup is replicated to another region. This would be based on the region of the original Blob Storage account (your write region for Cosmos DB) and the regional pair associated with it.

Unfortunately, you can’t access the backup yourself. You’d have to raise a support request with the Azure Cosmos DB team, who would then perform the backup for you.

With Periodic backups, these were taken without affecting the performance or availability of your application, without consuming any throughput (RUs).

We are able to customize the periodic backup if we wanted to. We can customize the backup interval, backup retention as well as the number of copies that are retained. We can get two copies of the backup free of charge. However, you can retain more copies for a charge.

Alternative backup strategies before Point-in-Time Restores

Arguably as a developer, it’s nice not to have to worry about managing backups yourself and just let the PaaS service handle it for you. I wouldn’t recommend making that pitch towards any DBAs, Security, Risk, Architects etc. So how could you enable more granular control over your backups?

There are a couple of DIY solutions that we could explore:

• Using the Change Feed to monitor changes inside that container and then extract the monitored changes into alternative storage platform, such as Blob Storage.
• Use Data Factory to copy the data inside our containers at regular intervals and store that data elsewhere.

Both of these approaches are viable, but they do affect the performance of our Cosmos DB operations, which is far from ideal.

The solution lies in Point-In-Time Restores 😊

Introducing Point-In-Time Restores

Last year, the Cosmos DB team released the Point-In-Time restore (PITR) feature (otherwise known as continuous backup mode) into public preview.

Similar to periodic backups, these are performed without affecting the performance of your database. Backups are taken in every region where your Cosmos DB account exists and are stored in Azure Blob Storage. By default, these Storage accounts are Locally Redundant, but if Availability Zones are enabled, then these are Zone-Redundant storage accounts.

The retention period is between the time that the resource was created and 30 days back in the past from now.

Databases, containers and items are backed up within 100 seconds. Everything that is restored is restored into a new account and is guaranteed to be consisted up to the restore time that you’ve configured. Restores will always restore the data into a new Cosmos DB account.

One thing to note is that PITR will not restore configurations such as regions configured on the account, consistency settings, Server-side scripts or networking configurations. You will need to reconfigure these yourself.

Configuring Continuous Backups in Azure Cosmos DB

Let’s set up a Cosmos DB account with Continuous Backups enabled. We need to enable this when we create our account (One limitation at the time of writing is that we can’t change between backup modes for our Cosmos DB accounts. Once we’ve picked a mode, we’re stuck).

Just a quick comment on who can initiate a restore, you can isolate who can restore to a specific role or a principal. Since I’m the owner of this account, I’m able to do this. I can also assign roles to other principles to perform restores. For more information on Permissions for continuous backups, check out the following article:

Configure permissions to restore an Azure Cosmos DB account.

Back to our walkthrough. When we configure our Cosmos DB account, all we need to do is choose continuous as our backup option. From the backup tab, we can see that there are costs associated with continuous backups.

Backup costs are $0.20 * size of data in GB of the account * number of regions the account is present in. This is charged monthly.

Restore costs are $0.15 * size of the data in GB, and charged per restore action.

I’ve gone ahead and created a new container within this account. I’ll add some items to it and then delete the container. I will then attempt to restore the container:

Here’s a before picture with the items in my container:

I’ll go ahead and delete the container now….and it’s gone!

Let’s restore this container. To do this, first click on the ‘ Point in Time Restore ’ tab in your Cosmos DB account.

First up, we’ll need to set our Restore Point. Currently, the retention period is 30 days, so we’ll need to pick a time within that limit.

Then we need to select a location to create our new account with the restored data in. We can restore to any region that’s associated with our account.

We can then choose whether we want to restore the entire account, or selected databases or containers. In our example, I just want to restore the DeviceReadings container that I deleted earlier. Remember, we can only restore databases, containers, accounts and the data itself. Account configuration will not be restored and you will need to set that up again.

Finally, we need to give our target account a new name.

Click Submit to start the restore.

One thing that’s quite cool is that you can view an event feed to choose a restore point if we’re not quite sure when we should restore our account from.

Once you’ve hit Submit, an new backup Cosmos DB account will be created with our resorted container and data inside it:

Now that our data is restored, we can copy this data back into our original account. We could do this via Data Factory or the Change Feed.

We aren’t just limited to performing restores in the portal. We can also do them using AZ CLI commands, PowerShell or using Azure Resource Manager. Check out the following articles on how to do that:

• Use Azure PowerShell to configure continuous backup and point in time restore in Azure Cosmos DB.
• Use Azure CLI to configure continuous backup and point in time restore in Azure Cosmos DB.
• Use ARM template to configure continuous backup and point in time restore in Azure Cosmos DB.

Current Limitations

As of the time of writing this post, there are some limitations to Point-In-Time restores while it’s in preview. Some of them are:

• Support for PITR only exists for SQL and MongoDB API accounts.
• If you have a Cosmos DB account with periodic backups configured, you can’t switch to continuous backups.
• No support for accounts that use customer-managed keys or Synapse Link.
• Any restore will be restored to a new account. Unfortunately, you can’t restore to a different account.
• The restore period is only 30 days. No yearly backups are available.

The full list of limitations can be found here. Remember, the feature is still in preview, so keep an eye out for these issues to be addressed (or you can give feedback to the Cosmos DB team here).

Conclusion

In this article, we covered what the differences are between Periodic and Continuous backups in Cosmos DB, how you can configure Continuous backups in your Cosmos DB account and how you can initiate a Point-In-Time restore on your Cosmos DB account.

I really believe that backups have moved up a gear with this feature. Having the ability to initiate your own custom backups has been on my wish list for a while as it allows Cosmos DB administrators to have more granular control over their backups, rather than relying on the Cosmos DB support team.

It’s important to note that this feature is still in preview, so while there are still some limitations to the Point-In-Time restores, I’m really looking forward to watching this feature grow.

As always, if you have any questions, please feel free to drop any questions in the comments below or reach out to me on Twitter.