My question is related to Azure-Azure scenario. I see we can create Azure Backup and Site Recovery to use the same Recovery service vault. I understand that for ASR the Recovery vault should be on the DR site so all snapshots are available for restore during DR situations. Since we would use Azure Backup Service primarily for day to day restore needs (non-DR) I was wondering if it would make more sense to separate out the Recovery service vault used by Backup from the one used by ASR and instantiate the former into the primary location? This is because otherwise this would be adding dependency on DR region availability which doesn't make sense as under normal operation it would be a pity if we cannot restore stuff on primary because DR region is unavailable. Are there any best practices in this area? Extending the question a bit more, if we have ASR setup is there anyway we can use its backups to recover/restore individual VMs/files during normal operations (non-DR). If possible then we wouldn't need a separate backup service.
by nature of the set of scenarios each service provides protection, backup is suited to be in the same location as VM whereas DR should always be to a location which is different from the source VM.
And also to serve the needs differently, they use different technologies to save data - DR uses log shipping for a less RPO and egress scenario where as backup relies on snapshot mechanism as keeping data for long term is the goal here typically.
Related
I am confused with azure SQL database backup plan (short term backup retention).
As far as i understood,
In DTU purchasing model, no extra charge for backup storage, you only pay for redundancy type (such as LRS,ZRS)
In vCore purchase model, you will have to pay for backup storage.
am i right ?
does that mean , i will not have any backups if do not subscribe to backup storage in vCore ?
further, in azure pricing calculator, in vCore, General purpose option, you have two redundancy drop down options (i am not talking about long term retention plan) , what is the difference between them ?
Thanks.
i will not have any backups if do not subscribe to backup storage in vCore ?
Yes, in vCore, if you do not allocate a storage account for backups, you will not be able to perform backup operations, either manually or automatically. If you believe you do not need backups, then you might be a fool ;), Azure will maintain access to your database according to the standard SLAs but the infrastructure will not provide a way for you to point-in-time restore the state of your database, only backups can adequately do that for you. But the storage costs are usually a very minimal component of your overall spend. Once the backup operation is complete you can download the backup for local storage and then clear the blob, making this aspect virtually cost free, but you will need a storage account to complete the backup process at all.
in azure pricing calculator, in vCore, General purpose option, you have two redundancy drop down options
Are you referring to the Computer Redundancy:
Zone redundancy for Azure SQL Database general purpose tier
The zone redundant configuration utilizes Azure Availability Zones to replicate databases across multiple physical locations within an Azure region. By selecting zone redundancy, you can make your serverless and provisioned general purpose single databases and elastic pools resilient to a much larger set of failures, including catastrophic datacenter outages, without any changes of the application logic. This configuration offers 99.995% availability SLA and RPO=0. For more information see general purpose service tier zone redundant availability.
In the other tiers, these redundancy modes are referred to as LRS (Locally Redundant) and ZRS (Zone Redundant). Think of this your choice on what happens when your data centre is affected by some sort of geological or political event that means the server cluster, pod or whole data centre is offline.
Locally Redundant offers redundancy only from a geographically local (often the same physical site). In general this protects from local hardware failures but not usually against scenarios that take the whole data center off-line. This is the minimal level of redundancy that Azure requires for their hardware management and maintenance plans.
Zone Redundant offers redundancy across multiple geographically independent zones but still within the same Azure Region. Each Azure availability zone is an individual physical location with its own independent networking, power, and cooling. ZRS provides a minimum of 99.9999999999% durability for objects during a given year.
There is a third type of redundancy offered in higher tiers: Geo-Redundant Storage (GRS). This has the same Zone level redundancy but configures additional replicas in other Azure regions around the world.
In the case of Azure SQL DB, these terms for Compute (So the actual server and CPU) have almost identical implications as that of Storage Redundancy. So with regard to available options, the pricing calculator is pretty well documented for everything else, use the info tips for quick info and go to the reference pages for the extended information:
The specifics are listed here: Azure Storage redundancy but redundancy in Azure is achieved via replication. That means that an entire workable and usable version of your database is maintained so that in the event of failure, the replica takes the load.
A special feature of replication is that you can actively utilise the replicated instance for Read Only workloads, which gives us as developers and architects some interesting performance opportunities for moving complex reporting and analytic workloads out of the transactional data manipulations OOTB, traditionally this was a non-trivial configuration.
The RA prefix on redundancy options is an acronym for Read Access.
Our application uses RA-GZRS for storage which enables to read data from the secondary when the primary is down, but can't write to it.
Is there a solution which enables application to do both read from and write to storage in the event of an Azure region going down?
In Azure Storage, there can be only one region (primary) where you can write. The other region (secondary) will always be read only.
One possible solution would be to do a manual failover so that the secondary region of your account becomes the primary and then you should be able to write to it. However, please be aware that the manual failover comes with a lots of caveats and make sure you understand those.
You can read more about those things here: https://learn.microsoft.com/en-us/azure/storage/common/storage-initiate-account-failover?tabs=azure-portal#important-implications-of-account-failover.
Please go through this. To quote from the article:
If the primary region becomes unavailable, you can choose to fail over
to the secondary region. After the failover has completed, the
secondary region becomes the primary region, and you can again read
and write data. For more information on disaster recovery and to learn
how to fail over to the secondary region, see Disaster recovery and
storage account failover.
The tutorial here tells you how to build a highly available application that automatically switches between endpoints on a failure. It uses a circuit breaker pattern.
Can we get Recovery point retention and app consistent snapshot while doing ASR if i did not set up any back up vault while configuring the VM in first place?
While ASR we get options for recovery point replication and app consistent snapshot options....are these recovery points and snapshots are the back-ups we create while creating VM ?
Back up and ASR are different things, to enable ASR you don't need any previous backup points. All you need is a vault in azure, a configuration/process server on premises. Once you enable replication, it will get a snap shot of your disk as the initial replication. After that the crash/app consistent snap shots are taken and replicated to the disk in azure.
I may have miss understood your question, so if that's not the answer you were looking for, clarify please
Azure Site Recovery is used for mainly 2 purposes- For DR and For Migration.
For both, replication is required and back-up for on-prem is not mandatory (if you have it, it is good). Recovery points and app-consistent snapshots will be generated anyhow post complete replication. Though app-consistent snapshots also depend on VSS installed on source machine.
Let's say I have a mydev.database.windows.net Azure SQL Server and Azure SQL DW database for development. And I have a myprod.database.windows.net for prod. If I want to restore prod to dev (cross server) is that possible? From what I can see in the documentation (see the -TargetServerName switch documentation), it is not possible.
Are there recommended workarounds other than scripting out all the objects then using a Polybase CREATE EXTERNAL TABLE AS SELECT command to export all tables to blobs then import those tables with Polybase?
The recommended approach to cross server restores with Azure SQL Database (not DW) is to export to a bacpac file then restore, but I don't believe that's an option for Azure SQL DW right?
I may start creating prod and dev on the same Azure SQL Server (as long as the customer wants both in the same Azure subscription). I would prefer the servers be separate, but ease of restore is important.
This will depend on the frequency and freshness of the restores today. The simplest approach is to restore one of the snapshots we take in the background to support RPO. This is called geo-restore. Snapshots are taken at least every eight hours. However, in practice you will see these taken more frequently. As RPO improves over time so will the frequency of snapshots.
To perform a geo-restore of production into dev you can go to the portal and begin the provisioning process. In the provisioning blade for SQL DW select your dev server. Under select source choose "backup". This will extend the provisioning blade as you will need to then choose the backup you want to use. The rest should be straight forward.
If you need to do this much more frequently or against an "on demand" (i.e. times of your choosing) snap then you would need to build out custom code as you suggest. However, if you are ok to live with our snapshots then the geo-restore would be a good option.
The team are looking for customer feedback on RPO and backup / restore requirements. If you have a business need for more frequent snapshots to support a business case then the team would love to hear from you. Please post this on our user voice feedback channel or reach out to us directly at sqldwfeedback#microsoft.com if business sensitive.
I'm working on a quiet large and critical application. It's been deployed to azure with 3 web roles and sql azure db.
In case of disaster, we need to be able to restore both web roles and sql azure to different data centers. Could someone please help me how we can restore SQL Azure DB and Web Role(s) to different data center.
The simple answer is that you take regular backups of your SQL Azure database, which can be restored to a database in another datacenter. You will have a problem with the data since the last backup being lost, which becomes a more difficult problem to resolve — the simplest may be to have a hot standby and use SQL Database Data Sync, but it may not be practical for all the data. Web roles are easier — you redeploy them somewhere else, and change the connection strings to the database. You would also have to change the CNAME for your domain as they will be restored to a different cloudapp.net name.
You did ask for restore, and not failover, right? Performing a failover (where you have a hot standby) is a more difficult problem, particularly as far as data synchronisation is concerned.
I would go back and question 'disaster' and correlate with known facts. I am not sure of the outage history of Azure in specific data centres, but there have been significant Azure-wide outages (leap year 2012 and the certificate problem this year). The ability to restore to a different Azure datacentre won't help you in these scenarios. (Although AWS seems to mostly have regional outages) I don't think that a datacenter-specific recovery strategy is necessary on Windows Azure, but you may want to check the history and likelihood of datacenter-specific failures before making a final call. Having a multi-region architecture that distributes load and data across datacentres, and handles live traffic across all (say using traffic manager), has many benefits — of side effect being builtin-disaster recovery - but comes at an architectural, development, hosting and bandwidth cost.
Go back and write the business case for your datacenter disaster recovery scenario. You may find that it is not worth it financially, or doesn't solve your real problem.