I hope I am asking this in the correct community. I did check for SQL Azure in others, but could not find anything so here goes.
I am trying to work out the best strategy to create a backup of my SQL Azure DB if my main datacentre has a significant availability or integrity problem. My initial thought was to "Create a Database", in a different region, on a new DB Server, using the "Geo-Replicated Backup" which works excellently. However because it is on a new DB Server I lose all of my Short Term (PITR) and Long Term Retention(LTR) Backups which I might need to restore from for data correction or compliance.
So how can I backup this "history". I may have missed something simple, but my only ideas at present are:
Take automated "Exports" to BACPACs" to Azure Storage, say weekly.
Use specialised Backup software such as VEEAM SQL Azure Backup which retains multiple versions, and can operate at hourly intervals. Works off Transaction Logs.
Use Azure Failover groups which effectively use 2 DB Servers and 2 PITR and LTR setups.
Thanks in advance,
Related
Is there a way to restore a Cosmos DB container after I accidentally deleted it? I just confused the live environment with a local Cosmos DB emulator.
When I go to the Settings - Backup & Restore it says:
Your account is on periodic backup mode. You can now change to continuous mode for a better backup and restore experience. Change to continuous mode
Does it mean that it is still somehow possible to revert the delete operation? But I can not find an option to revert the deletion.
For Cosmos DB containers configured with periodic backup (as you've mentioned is the case here), Microsoft has very prescriptive guidance on how to potentially restore the data. TL;DR - you should file a support request with the Microsoft Azure support team as soon as is feasible (being sure to include all information they need as indicated in the linked article). Their word choice in the linked document strongly indicates a time-sensitive aspect to this, and a relatively short window in which you need to lodge such a request to ensure the best possible outcome.
I've reproduced the relevant bits from the linked documentation below for convenience/posterity (emphases mine):
Request data restore from a backup
If you accidentally delete your
database or a container, you can file a support ticket or call the
Azure support to restore the data from automatic online backups. Azure
support is available for selected plans only such as Standard,
Developer, and plans higher than those. Azure support is not available
with Basic plan.
To restore a specific snapshot of the backup, Azure Cosmos DB requires
that the data is available during the backup cycle for that snapshot.
You should have the following details before requesting a restore:
Have your subscription ID ready.
Based on how your data was accidentally deleted or modified, you
should prepare to have additional information. It is advised that you
have the information available ahead to minimize the back-and-forth
that can be detrimental in some time sensitive cases.
If the entire Azure Cosmos DB account is deleted, you need to provide
the name of the deleted account. If you create another account with
the same name as the deleted account, share that with the support team
because it helps to determine the right account to choose. It's
recommended to file different support tickets for each deleted account
because it minimizes the confusion for the state of restore.
If one or more databases are deleted, you should provide the Azure
Cosmos DB account, and the Azure Cosmos DB database names and specify
if a new database with the same name exists.
If one or more containers are deleted, you should provide the Azure
Cosmos DB account name, database names, and the container names. And
specify if a container with the same name exists.
If you have accidentally deleted or corrupted your data, you should
contact Azure support within 8 hours so that the Azure Cosmos DB team
can help you restore the data from the backups. Before you create a
support request to restore the data, make sure to increase the backup
retention for your account to at least seven days. It’s best to
increase your retention within 8 hours of this event. This way the
Azure Cosmos DB support team will have enough time to restore your
account.
In addition to Azure Cosmos DB account name, database names, container
names, you should specify the point in time to which the data can be
restored to. It is important to be as precise as possible to help us
determine the best available backups at that time. It is also
important to specify the time in UTC.
I can't find a straight answer to this question so hoping someone here came across this.
As the LTR backups are tied to the subscription there should be a way to restore a backup even if the original SQL Server that hosted the database is deleted.
How can these be viewed and restored via the Portal after the SQL Server is deleted?
Or via other means.
Currently there isn't a built-in method to restore the entire server. When a server is deleted (soft deleted) then you should call Azure support as soon as possible before a purge process that runs periodically fully removes the logical server. There are no SLAs for server deletions. So the quicker you can get to Azure CSS, the better it is.
If the server is deleted, there is no way to restore from automated built-in backups offered by Azure. Quoting from the page:
If you delete an Azure SQL Database server instance, all its databases
are also deleted and cannot be recovered. There is currently no
support for restoring a deleted server.
So everything is AS-IS. When a user deletes a logical server, you were asking the server to be deleted which is why you typed in the server name, etc. etc. CSS can work with engineering to figure out what is possible at best but there are no service-level guarantees unless Disaster Recovery (Geo-replication, Synchronization, long-term backups, etc.) was part of the deployment strategy.
I witnessed a case where a developer that works for a company in Costa Rica deleted their production Azure SQL logical server on a Thursday and Azure Support was able to recover on the next Monday. Usually Azure CSS gives a time frame of 7 days to recover an Azure SQL logical server that was accidentally deleted.
To avoid this in the future you can use “resource locks” which can protect against accidental deletion using Azure portal.
This question specifically asks about Long Term Retention backups which the other answers (so far) do not address. Yes, when a logical server is deleted, all the automatic backups are also deleted, but NOT the long term retention backups. If a database was configured to use LTR and the LTR backup's retention period has not expired, then yes you can restore from them.
After a logical server is deleted, you can't see the LTR backups from the portal so you must use Powershell commands to list them and issue the restore.
Get-AzSqlDatabaseLongTermRetentionBackup
Restore-AzSqlDatabase
This link gives a good basic tutorial.
https://www.mssqltips.com/sqlservertip/6443/how-to-restore-azure-sql-ltr-backup-after-azure-sql-instance-deleted/
If you delete your Azure sql server, then you could not backup it from the LTR backup.
Alberto Morillo has show you the document:
If you delete an Azure SQL Database server instance, all its databases are also deleted and cannot be recovered. There is currently no support for restoring a deleted server.
I also asked Azure support to get more message about your question. The replied me:
" Azure support can help you recover you Azure SQL server in 7 days after the deletion. You need to provide your server name and region for Azure Support."
You can call Azure Support from portal:
Hope this helps.
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/
this is my first post,and i am trying my best to make my question clear. pls forgive me if i failed to do so :)
Here's the situation:
- 1 sql azure server ABC.
- 2 database instances in that server, ABC1 (my backup database) and ABC2(my live database)
This morning, I created a new database by from ABC1, and at the same time some users complained about performance issue they have in live environment( which is using ABC2 db). So I am wondering if it's possible that copying one db instance will impact performance to another db instance in the same server.
Command I used(inside XYZ sql azure server):
CREATE database XYZ1 as copy of ABC.ABC1
the server you refer to in Azure SQL Database is just a logical one and does not correspond to an actual physical server. The databases you create in that logical server maybe on different SQL nodes in Azure.
Rather than guess what's causing the performance issue, have a look at the Azure SQL DMVs/system views to see if the stats you get gives an indication about the performance degradation
The performance of a Azure SQL Database is largely dependent on the Service-Tier and the performance level, which comes with an associated billing.
Please refer this link for more information, Azure-Service-Tier and Performance-Level
I would like to transfer my existing SQL Azure location to other one, but I think there is no functionality right now to do so on the management portal of Azure.
I just googled it and found one link http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e6c961cc-5eea-4f07-82c9-a8805d367b05 that says I need to use the data sync option in Azure's portal but I don't have that feature enabled in my Azure portal.
Also if I do use that option, is there any charge for it? Finally, are there any other option that is possible for moving the SQL Azure location?
To Move an Existing SQL Server Database to a New Region on Azure Assuming There Are No Blob Containers Associated With the Database. For further reference see:
https://azure.microsoft.com/en-us/blog/migrating-azure-services-to-new-regions/
Upgrade the database, if necessary, to one of the Premium pricing tiers
Add geo-replication to the existing database. You can choose what region to have the backup of the existing database. Create a new Database server in the target region of your choice. I suggest provisioning that new database server with the same admin username and password as the existing sql database. When creating the secondary database, I suggest making the Secondary type “Readable” as it will allow you the ability to check that all data and schemas were replicated correctly.
Allow the two databases time to sync. Rule of thumb according from Microsoft AzureCAT is: 3 * (5 minutes + database size / 150 MB/minute)
Configure the Firewall settings of the secondary database to allow the necessary IP addresses to access the database
Temporarily shut down whatever users or applications are accessing the existing database.
From the Azure portal select the existing database and change its geo-replication role from primary to secondary.
Run any ddl scripts that rely on the masterdb such as ddl scripts to recreate users and user profiles
Change the connection strings of any applications to point to the new database.
Users and applications can now connect to the new Database
At your discretion you can remove the old database as a backup and add any new regions as backup.
In terms of charges there will be charges for upgrading the old database if it isn't already a premium database. There will also be charges for creating the geo-replicated database. However, those charges can be limited to a day to a few days worth of fees (depending on how long geo-replication takes). Once the new database is up and running, delete the old database as soon as possible to limit additional fees. Finally, if you upgraded the service level of the old database to a premium tier to facilitate the geo-replication, you will want to downgrade the new database to the original service level of the old database to also limit fees.
I think you can use new Import/Export bacpac feature. I have used it to move databases between accounts and can't see why it wouldn't also work between regions.
See how here
If you are able to stop writes to the DB for a time then you can use the Copy feature on the Azure Portal.
Create a new SQL Server in the region of your choosing.
Add your service(s) IP addresses to the new SQL Server firewall.
Stop writes to the origin database.
Open the origin database in the Azure Portal and click Copy at the top of the blade.
Choose your new SQL server located in the destination region.
Wait for the copy to complete.
Update your service(s) to point to the destination DB.
Enable DB writes.
Verify everything is working.
Delete origin database (and server if it was the only DB on the server).
I wouldn't use DataSynch because it creates many objects in your database to perform synchronization (it's an invasive solution). You can indeed try the Import/Export feature; that should work fine. You can also download a trial version of the Enzo backup tool, which comes with a 30-day free trial: http://www.bluesyntax.net/backup.aspx. [disclaimer: I am the author of this tool]
Regarding the pricing question, you may be charged for data being extracted out of the database. Moving data "in" SQL Azure is free of charge for now. If you are transferring the data to a different data center, you will be charged for extracting the data. It's 15 cents per GB in the US and Europe, and 20 cents in Asia. Here are the pricing details: http://www.microsoft.com/windowsazure/pricing/
Keep in mind that a database that requires 4GB of storage doesn't mean you have 4GB of data. Sometimes indexes can take a lot of space. To estimate the size of the data you will need to transfer you can either drop your indexes (and wait a little for the database size to shrink; the database size should be roughly equal to your data transfer needs) or you can calculate the size of your tables by running a command. Here is a link to an article that shows how to do something similar (look at the second command with is a SELECT statement; just run it for all the tables): http://www.sqldocumentor.com/table-size-in-sql-server-find-rows-and-disk-space-usage
Azure has released a new tool called Azure Resource Mover.
Resource mover can for now handle these resources:
Azure VMs and associated disks
NICs
Availability sets
Azure virtual networks
Public IP addresses
Network security groups (NSGs)
Internal and public load balancers
Azure SQL databases and elastic pools
https://learn.microsoft.com/en-us/azure/resource-mover/move-region-within-resource-group
Azure SQL Server is not supported yet but Azure has a complete guide for this anyway:
https://learn.microsoft.com/en-us/azure/resource-mover/tutorial-move-region-sql#move-the-sql-server