Okay so I figured since Azure has a lot of tools and I am failing at best processes to just ask on SO.
What I can do:
BACPAC creation
Creation is directly from SSMS with hovering over the database in Object Explorer. Right Click>Tasks>Export Data Tier Application. Choose a disk location. The caveat is generally to not have a database that is in use querying. So have a copy or system that can be not using the database.
BACPAC restore to Azure
SqlPackage.exe https://learn.microsoft.com/en-us/sql/tools/sqlpackage?view=sql-server-2017
When I do it it is similar to: (must have Visual Studio or equivalent Sql management object DLLs installed)
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\SqlPackage.exe" /a:Import /sf:(bacpac Location) /tdn:(dbName)/tsn:bvtest.database.windows.net /tu:(user) /tp:(password)
In Azure>SQL Servers>(Top ribbon)>Import database>(have blob storage with a bacpac created to it already). This method appears slightly faster if they are both on same region.
My question is that I have seen articles like this one: https://learn.microsoft.com/en-us/sql/azure-data-studio/tutorial-backup-restore-sql-server?view=sql-server-2017 as well as knowing SSMS pretty well. It seems all options to restore to Azure SQL PAAS are turned off for a 'bak' backup and you have to make a bacpac for going instance to Azure PAAS. The problem is that this takes hours just to make the bacpac on a relatively medium sized database of 120 gigs. Then it takes hours to restore. Other than what I have tried above is there a faster way?
You can use Azure Data Migration Service (ADMS) instead of importing/exporting bacpacs. Azure Data Migration Service allows you to migrate data from SQL Server to Azure SQL Database with no downtime if your database does not have "heaps". If your database has heaps you will have to perform an offline migration. Copying/migrating data from a SQL Server ARM (IaaS) Premium Storage (200 GB / 790 tables) to an Azure SQL Database (Premium) takes 1 hour 40 minutes with an offline migration. That is the fastest data migration I have seen as a workaround to import/export bacpacs since SQL Server native backups are not supported on Azure SQL Database (DTU-model / Vcore model).
ADMS performs a validation of your data at the end, if you want.
Related
I've created an azure **serverless ** sql database. It seems there is no way to backup/restore this type of databases. I know there is restore to a point in time feature, But I what to download and save database backups my self.
Is there a way to backup serverless azure sql databases?
1-) There is no Backup/restore option on the database right click
2-) I've tried to use BACKUP T-SQL with azure storage account and storage url from SSMS but this is not supported.
You can use the "export" functionality by accessing the specific database in your Azure Portal to get a copy of your DB.
You can rely on Azure SQL's integrated Backup funcionality by setting up your requirements by accessing your DB Server in you Azure Portal and selecting the "Backup" uption.
You can use SSMS (SQL Management Studio), right click on the DB in question, and select "Tasks" --> "Export Data-tier Application", which will return a .bacpac file with your database. NOTE: bacpac files are not quite the same as full .bak files. bacpac files are not aware of any transactions that may be being executed whilst the data is being dumped, which means that you could end up with some data corruption.
Export your database as bacpac to an Storage Account. We are using weekly exports of the database on Saturdays, with a retention of one year for long-term backups.
The export will trigger an auto-resume of the database if the database was auto-paused.
We use an Azure Automation account and a PowerShell script to schedule the export of the database. Here you will find the script and the steps needed to schedule the script using Azure Automation.
Azure SQL has built in backups. If the SQL database and server are deleted from within the Portal these backups are lost.
What is best practice for backing up Azure SQL that will withstand deletion of the server from the portal.
I have manually exported the database to a storage location, however Azure says that this should not be used as a backup. Why should it not be used and what should I be doing instead?
If you want a direct control over your backups, then the best mechanism is fairly straight forward.
Create a copy of your database. This ensures no active transactions because it's a copy.
Use the BACPAC process to export the copy of the database. BACPAC doesn't respect transactions, this is why we created a copy.
Store this where ever you want.
Drop the copy of the database because you're paying for that while it exists.
You can use the BACPAC to import into a new Azure database, or you can import it into a VM in Azure, AWS, or locally.
Azure SQL has built in backups. If the SQL database and server are
deleted from within the Portal these backups are lost.
Yes,If you delete the Azure SQL server that hosts SQL Databases, all databases that belong to the server are also deleted and cannot be recovered. You cannot restore a deleted server.
What is best practice for backing up Azure SQL that will withstand
deletion of the server from the portal.
If your Azure SQL Server has been deleted, you need to create a support ticket to restore the databases.
When you really need to delete a SQL sever and then try to back up it, You can configure the Azure Recovery Services vault to store Azure SQL database backups and then recover a database using backups retained in the vault using the Azure portal or PowerShell.
Why should it not be used and what should I be doing instead?
I think you can export your database to your local storage , but it's complex to restore it to Azure. Also, it may change some information of your SQL database and may need migration to Azure.
Well, there is no real answer to this, you can use any backup method you like. Its mostly a personal preference.
But the easiest way (probably) is using Azure Backup Vault to do long term backups (which is a native way for Azure). Its pretty easy to configure (next\next\next) and it is not connected to the Azure SQL Server, so when you delete the server the backups are there.
I am trying to upgrade an Azure DB in a continuous release scenario. The DB lives in SQL Azure and its size keeps growing. Now it's about > 50G. In my previous on-premise experience, I usually backup the old DB in a compressed format and save it to an on-premise file sever. In case the upgrade fail, I can restore it safely.
But with SQL Azure, I am not sure if it's OK to download such a big DB from SQL Azure. And is there any best practice for the SQL Azure DB upgrade scenario?
ADD
I found this link regarding different SQL Azure backup strategies. But it'll be great if someone can share some field experiences.
Azure now has automatic exports (aka full backups) to blob storage that you can schedule. The .bacpac files are complete compressed copies of your database and blob storage is pretty cheap. To give you an idea of size we have a 20GB database that is backed up to only 500 MB. We typically keep 14 days of backups but how long to retain them is up to your needs.
It's kind of like the Ron Popeil Rotisserie. You just set it, and forget it.
Obviously after you take a backup you want to restore it somewhere else to verify it worked. It's also a good idea to periodically restore your backups to make sure they working over time. You can do all of this in the Azure Portal. Just create a new database based on a .bacpac file that you created from the automated export.
You actually don't have to download the DB on premise unless you want another copy locally. Because if you are using geo-redundant blob storage its already copied to another region and you have 6 copies in total. But again its up to you.
When you log into the management portal navigate to the Sql Database tab. Click on your DB and then click configure. There you can set up automated backups for your db to blob storage.
The path on the management portal looks like this:
https://manage.windowsazure.com/mycompany.com#Workspaces/SqlAzureExtension/SqlServer/coolazuredb/Database/5.coolazuredb/Config
Here is a screenshot of the automated export section:
I'm building a web app using Azure & SQL Azure. I'm setting it up so each organization has their own database. Low to moderate traffic per customer organization.
I'm thinking about using SQL Azure Data Sync as part of a failover/backup plan, so that if SQL Azure goes down, my app can switch over to my on-premises SQL Server (read-only mode).
I would also be able to do all of my backups on-prem, instead of in the cloud which could incur costs.
One issue may be trying to data-sync multiple databases to my on-prem
sql server (not sure what the limit is on the number of databases
that can be synced to one server)
Bandwidth may be an issue, but I'll probably only sync daily.
Does anyone see any other problems with this approach?
Data Sync is ok, but may or may not be good for your particular DR plan since it's not a transactional sync model.
One option to consider is making a database copy:
CREATE DATABASE destination_database_name
AS COPY OF [source_server_name.]source_database_name
Then you can create a backup from this copy, store the backup in blob storage, and (optionally) delete the database copy. While this does add an additional cost due to a second database being live, you can keep that cost to a minimum if you delete the database instance after creating a backup and storing to blob storage (remember that databases are amortized daily).
Since your backups would then be in blob storage, you could keep multiple backups in blob storage, and pull a backup to your on-premises server if needed.
Tricky question - Does anyone know where the ORM SQL code lives that the Azure Dev storage emulator uses for Table Storage?
I'm wanting to implement a SQL version of Azure Table storage for use on-premises (outside of Azure).
And before explaining to me the differences between a relational db like SQL Server and a NoSQL key/value store like Azure Table storage - I know already, thanks :)
Go to the SQL server you installed the Storage Emulator. You will see a database called "DevelopmentStorageDb20110816" if you have installed the Azure SDK v1.5+ (It was a different date previous to that - something like DevelopmentStorageDb20090919 I think).
In that database you will find all the tables, stored procedures and functions needed to emulate Windows Azure storage.