We have enabled LTR backup for Azure SQL DB's and Geo Backup policy is by default enabled in Synapse.
Below are my queries:
Does the LTR backup for Azure SQL DB's and Geo Backup in Synapse are created in a regional pair or in a Geo redundant location?
Lets say my DB/Synapse is in North Europe region and the entire Europe region is down, is it possible for me the restore the DB/Synapse backup in a server created in a different location like US.
Note -- We do not want to setup an active Geo redundant Geo replication
Is it possible to extract the backups of Azure SQL DB and Azure Synapse into a storage location of our choice (either via PowerShell or any other automated way)
Azure SQL DB has an option called Backup Storage Redundancy which can take the following values: LRS, ZRS, RA-GRS, RA-GZRS. This option replicates DB backups depending on the selected redundancy. With the RA-GRS option, backups are replicated to paired geo regions. In case the region that contains DB is down(North EU in your case), the backup replicated to paired region (West EU) can be used to perform restore using Geo-restore. This backup can be restored to a server in any region like US Central, US East, etc.
Geo-backups in Synapse also use the paired region for backup replication.
In Azure SQL DB it is not possible to extract the backups into a storage location of user’s choice.
Related
I have a requirement to basically beable to 'tag' PIT restores as to hold for longer (and then later use the restore on demand), the only way i can think to do this is basically figure out a way to export the requested Point-in-Time restore to a bacpac and save it in Azure storage.
PIT restores as to hold for longer.
The Azure SQL Database service protects all databases with an automated backup system. These backups are retained for 7 days for Basic, 35 days for Standard and 35 days for Premium.
I can think to do this is basically figure out a way to export the requested Point-in-Time restore to a bacpac and save it in Azure storage.
These are two different approach. Either you restore a database from PIT or from bacpac file which is either stored in Azure Storage account or local machine.
You can't perform a Point-of-Time restore from bacpac file.
Refer Azure SQL Database Point in Time Restore and Export to a BACPAC file - Azure SQL Database to know more.
Due to reasons (I've been told it's a networking issue with MIs; regardless, we can't fix it, we're waiting on a solution from MS that may or may not come out this year), we cannot talk from on-prem to managed instances. However, we can reach Azure SQL Databases.
We would like to replicate lookup data from on-prem to Azure Managed Instances (MIs) as well as ASDs. Is there any way to use the ASD as a "jump" box for replication, maybe by putting the Distributor on an MI that can talk to the ASD?
Looked at Azure Data Sync, but the 5-minute-minimum makes it a no-go.
Otherwise, our current fallback is to run an Azure VM/AKS instance, replicate to it, then from there to the ASDs/MIs. But man, I'd rather not have to do that.
Any suggestions appreciated.
One Way Transactional replication using SQL Data Sync for Azure.
If they wish to maintain the replication running after the migration to Managed Instances, transactional replication will be the best option at this time. Replication to Azure SQL Database
Or using ETL via Azure DataFactory
Transfer data from a SQL Server database to an Azure SQL Database using Azure Blob Storage and the Azure Data Factory (ADF): this is a supported legacy technique that benefits from a replicated staging copy.
ADF pipeline consisting of two data migration processes. They work together to transfer data between a SQL Server database and an Azure SQL Database on a regular basis. The two actions are as follows:
Data should be copied from a SQL Server database to an Azure Blob Storage account
In Oracle we have RowID, gives Physical address of a record.
Likewise we have %%physloc%% in SQL Server. What is the keyword for fetching the Physical location of a record in Azure DB.
Since the Azure SQL Database service is a PaaS (Platform as a Service) service, it abstracts out the need to care or worry about the physical disks that store your data. The service managing scaling everything in your database according to the pricing tier and DTU's you select. As a result of this there are no queries that can be performed to tell where on disk you data is stored. Also, there are no queries to specify where in physical storage you want Azure SQL Database to put your database tables and data. Azure SQL Database just manages all this for you automatically.
Do we have any standard way of daily backing up SQL Azure databases to onprim?
I know about the option of making backups to Storage, but on a daily basis, if we backup on storage blobs we will end up having many files and it will incur a high cost with Azure.
We need to take backup of SQL Azure Databases directly to onprim disks.
Maintain only two latest backups on the disk.
Do we have mechanism to schedule daily backup to storage blob and maintain only two copies at any moment of time?
Not sure if the new SQL Database Point-in-time feature is good to you. You need to enable this preview feature and select a new edition when creating your database. "Basic" edition support daily backup stores in the past 24 hours while "Standard" and "Premium" editions provides point-in-time backup stores backups in the past 7 days and 35 days.
Alternatively you need to pragmatically backup the database in blob and remove the old ones through worker role, scheduler, webjob.
I have the following set up:
Azure service
Azure SQL database
Azure Table Storage
Azure Blob Storage
I am trying to develop a backup strategy for this service.
The thing is, that SQL, Tables and BLOBs should be synced. In the backup all three of those have to be of the same version. (backups taken at the same moment). And the main problem is - I can only afford several minutes downtime, not more than that.
What should I do? May be there is existing solution?
Windows Azure Storage supports geo-replication for Blobs, Tables and Queues. Data in the storage account is made durable by replicating transactions across different storage nodes in the same region (LRS) or a secondary region (GRS). GRS is the default redundancy option when creating a storage account. Refer to http://blogs.msdn.com/b/windowsazurestorage/archive/2013/12/11/introducing-read-access-geo-replicated-storage-ra-grs-for-windows-azure-storage.aspx for more details.
If you want to build a custom backup solution then you could use the techniques suggested in the below 2 blogs
1) http://blogs.msdn.com/b/windowsazurestorage/archive/2010/04/30/protecting-your-blobs-against-application-errors.aspx
2) http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/03/protecting-your-tables-against-application-errors.aspx
I am not sure of the exact use case of why you need to backup azure table and blob. You can backup All the above services without downtime; might be there would be slight glitch or bottleneck performance with SQL database durning back.
The single shot answer is to write a custom script which would read the data from azure table ( or SQL database, or the required service ) make a archive (packaging) and store it back.
The important thing to note here is where would storage backups, broadly speaking generally store the archives in blob. In this case you have thing where you would be storing, if you are storing on-premises you need calculate upon the storage locally, out bandwidth cost and latency of the data transfer from azure.
PS : cloud storage by itself has good leave of availability and durability, you further improve these factors by enabling geo-replication