Azure Cosmos DB takes snapshots of your data every four hours. At any given time, only the last two snapshots are retained. However, if the container or database is deleted, Azure Cosmos DB retains the existing snapshots of a given container or database for 30 days.
How can I see those snapshots?
You will not be able to see them.
CosmosDB uses Azure Blob storage in the same region as your database's write region for backups. If you have multiple write regions, CosmosDB picks one of them to store your backups. But wait, Microsoft does not stop there! Each snapshot of the backups in Azure Blob storage gets replicated again to another region for disaster recovery.
All these operations do not cost you any extra charge or RU. Also backups do not affect the performance of your databases. If you need to restore data for any reason, you need to contact Azure support within 8 hours!
Related
Does Azure charge you per region when performing periodical Cosmos backups?
Based on their calculator it seems that's what they do. I have a single write region and a single read region and it looks like I will be charged for both regions when I enable backups.
Also, how does the "backup restore redundancy" (GRS, ZRS, and LRS) work into pricing for backups? It's an option in the Azure Portal but their calculator does not account for it.
Yes, you are right. You will be charged for both regions.
However, 2 periodic backups per region are free. You are charged only if you opt for more than 2 backups.
By default, Azure Cosmos DB stores periodic mode backup data in geo-redundant storage (GRS). Updating backup storage redundancy to ZRS or LRS will not have any impact on backup storage pricing.
I am having an issue creating differential backups of Azure SQL database in storage account blob storage using powershell. I don't know if it is possible or not to get a differential back up of an Azure SQL database. Please suggest me what can I do.
If have seen the differential backup document, you will find this:
Azure SQL database has the feature Automated backups. It referred that:
SQL Database supports self-service for point-in-time restore (PITR) by automatically creating full backup, differential backups, and transaction log backups. Full database backups are created weekly, differential database backups are generally created every 12 hours, and transaction log backups are generally created every 5 - 10 minutes, with the frequency based on the compute size and amount of database activity. The first full backup is scheduled immediately after a database is created. It usually completes within 30 minutes, but it can take longer when the database is of a significant size. For example, the initial backup can take longer on a restored database or a database copy. After the first full backup, all further backups are scheduled automatically and managed silently in the background. The exact timing of all database backups is determined by the SQL Database service as it balances the overall system workload. You cannot change or disable the backup jobs.
I also asked Azure Support, they told me that we(customer) can not create the differential backup by ourselves, Azure SQL database will do that automatic.
Hope this helps.
I've configured the retention policy in 'Manage Backups' for my Azure SQL Server but nothing is appearing under 'Available Backups'. Does there need to be an associated storage account? If so, how do I set it up?
From Azure's doc it is known that the automatic backups (full, differential and transaction log) are possible. And it is possible to configure retention period for these backups. The main question is where these backups are stored (from documentation by default within RA-GRS Standard blob storage)? and whether it is possible to change storage account and how to access to standard storage account with backups?
Thanks in advance.
Automatic backups are part of Azure SQL Database service and are managed by Azure. You cannot change where these backups are stored, that is managed by Azure. You cannot access those backups and copy them to another storage account, and you cannot manage them.
You can use PowerShell Get-AzureRmSqlDatabaseRestorePoints to get the earliest possible restore point for the database based on the automated backup service.
Get-AzureRmSqlDatabaseRestorePoints -ResourceGroupName "resname" `
-ServerName "yourservername" -DatabaseName "yourDBName"
With automatic backups, full database backups are created weekly, differential database backups are generally created every 12 hours, and transaction log backups are generally created every 5 - 10 minutes, with the frequency based on the performance level and amount of database activity. The first full backup is scheduled immediately after a database is created. It usually completes within 30 minutes, but it can take longer when the database is of a significant size.
If you want to have control over backups, you want to have greater retention period, then you can configure long term backups o export bacpacs of your database to an storage account as explained here.
Why do we need Azure backup for our VMs (disks) on azure, when azure storage account provides different replication options like LRS, ZRS, GRS, RA-GRS.
All the data is already replicate in different region (in case of GRS), what advantes I will get out of Azure Backup.
All the data is already replicate in different region (in case of
GRS), what advantes I will get out of Azure Backup.
Replication is not backup!
It is true that when you opt for GRS replication, 6 copies of your data is maintained (3 in primary and 3 in secondary) but when you delete the data from primary, data from secondary is automatically deleted.
UPDATE
You mean, if any data is deleted/corrupted due to some error/bug, can
be reproduced from backup and it is not possible in case of storage
replication.
You're absolutely correct!
But Microsoft sells "Azure backup and Site recovery" as a BCDR
strategy. In context of any disaster, why not just rely on Storage
replication. Any advantages of Azure backup/site recovery?
I have not used Azure backup so let me answer it from Storage Replication point of view. To put things simply, "In context of Azure, a disaster is not a disaster unless Microsoft thinks it is a disaster". Till the time that happens, you don't get access to secondary assuming you have opted for GRS replication (with RA-GRS, you obviously have an option to read the data from secondary at all times).
Furthermore if you choose LRS or Premium LRS replication and there's indeed a disaster in one data center, all of your data will be lost. With Azure Backup, you at least have a copy of your data lying somewhere safe and you could recreate your environment based on that backup.
I know this question is old but MS provide a solution for Disaster recovery by Storage account
We may have 2 solution for dealing with Disaster
https://learn.microsoft.com/en-us/azure/storage/common/storage-disaster-recovery-guidance?toc=/azure/storage/blobs/toc.json
it said :
If the primary endpoint becomes unavailable for any reason, the client is no longer able to write to the storage account. The following image shows the scenario where the primary has become unavailable, but no recovery has happened yet:
enter image description here
The customer initiates the account failover to the secondary endpoint. The failover process updates the DNS entry provided by Azure Storage so that the secondary endpoint becomes the new primary endpoint for your storage account, as shown in the following image:
enter image description here
I want to confirm our understanding of how our Azure SQL databases are being backed up to enable point in time restore. We have not currently configured geo-replication to have the database available in another region. We may in the future as some data analysis is done. But my understanding is that the database is still being backed up to a geo redundant location so I could do a geo-restore if there was an issue with the data center that houses my sql database. Is that correct or do I need to enable geo-replication and pay for a second database in order to have a disaster recover option if the datacenter had an issue.
To clarify further: I think this article states what I'm saying in the Geo-Restore section.
https://azure.microsoft.com/en-us/documentation/articles/sql-database-business-continuity/
Thanks
Yes, all databases have a geo-replicated copy for disaster recovery purposes. For more details, please see the following: https://azure.microsoft.com/en-us/blog/azure-sql-database-geo-restore/
Geo-restore uses the same technology as point in time restore with one
important difference. It restores the database from a copy of the most
recent daily backup in geo-replicated blob storage (RA-GRS). For each
active database, the service maintains a backup chain that includes a
weekly full backup, multiple daily differential backups, and
transaction logs saved every 5 minutes. These blobs are geo-replicated
this guarantees that daily backups are available even after a massive
failure in the primary region.
Yes, Azure SQL Databases are automatically backed up to a different Azure data center using Geo-Replication. This is an automatic features of Azure SQL that is baked into the service offering.
Here's a blog post with further information about Azure SQL Data Replication:
https://azure.microsoft.com/en-us/blog/azure-sql-database-standard-geo-replication/