Cosmos DB’s continuous backup mode is a game-changer for data durability, but its true power lies in enabling point-in-time restore (PITR), which is far more flexible than traditional snapshot-based backups.
Let’s see it in action. Imagine you have a products container in a store database, with data like this:
{
"id": "SKU123",
"name": "Wireless Mouse",
"price": 25.99,
"category": "Electronics",
"lastUpdated": "2023-10-27T10:00:00Z"
}
Now, suppose an accidental update overwrites the price to 0.99 at 2023-10-27T11:30:00Z. With PITR, you can rewind to just before this change.
Here’s how you’d initiate a restore to a specific timestamp using Azure CLI:
az cosmosdb restore --account-name MyCosmosAccount --resource-group MyResourceGroup --name MyRestoredAccount --restore-timestamp "2023-10-27T11:29:59Z"
This command creates a new Cosmos DB account, MyRestoredAccount, containing the data as it existed at the specified timestamp. The original account, MyCosmosAccount, remains untouched. You can then compare data, migrate specific records, or simply clone the state for analysis.
The core problem continuous backup and PITR solve is the trade-off between backup frequency and restore granularity. Traditional backups are often taken hourly or daily, meaning you could lose hours or even a full day of data in a disaster. Continuous backup stores every transaction for a configurable retention period (up to 30 days), allowing you to restore to any second within that window. This is achieved by the service continuously replicating write operations to a separate, geo-replicated log store. When you request a PITR, Cosmos DB reads from this log and replays transactions up to your specified timestamp to reconstruct the data in a new account.
You control this capability at the account level. When creating a new Cosmos DB account, you specify the backup mode:
az cosmosdb create --name MyCosmosAccount --resource-group MyResourceGroup --kind GlobalDocumentDB --locations region1 region2 --backup-policy '{ "type": "Continuous", "intervalInMinutes": 10, "retentionInDays": 7 }'
Here, type: Continuous enables the feature. intervalInMinutes dictates the frequency of full backups (which are still taken for efficiency, but PITR uses the transaction logs). retentionInDays sets how long the transaction logs are kept. Crucially, the transaction logs are not directly accessible; they are only used by the PITR operation.
The most surprising aspect for many is that PITR always creates a new account. You cannot restore in-place to the original account. This is a deliberate design choice for safety. It prevents accidental overwrites of your live data and allows for a period of verification before you decide to replace the original account or migrate data back. You’ll need to manually delete the old account if it’s no longer needed after you’ve validated the restored data.
The next hurdle to overcome is understanding how to manage and automate the process of migrating data from a restored account back to a live, potentially updated, account.