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.
Related
We've got a Atlassian Bitbucket Datacentre installation which we want to DR to another region.
Can Azure Site Recovery be used to replicate the PostgreSQL server?
Can Azure Site Recovery be used to replicate the NFS server?
Can Azure Site Recovery be used to replicate a VM from a VMSS?
It would be great if we could orchestrate the whole thing with ASR as it would make PITR a breeze. If not we'd need to look at each item individually then work out how to coordinate the retores to the same point in time.
Thanks
Phill
This is a generic question and I would need more detailed idea about your Infrastructure. But yes you can use ASR to replicate these servers. ASR is a mechanism that installs an agent on the source machine and this agent replicates all the data to PS and eventually uploaded to Azure.
However it isn't application aware which means it won't give you PITR for DBs, but you will have an option to failover (restore) entire machine even 5 minutes ago. Since ASR creates recovery point every 5 minutes. It isn't a file level replication but a server level replication. Below article implies for Vmware and Physical machines replication to Azure.
https://learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-architecture
Let me know if this helps.
We have a VM using premium managed drives that is also replicated to another azure data center using azure site recovery. I am aware of how to convert the premium drives to standard by deallocating the vm and changing the drive type. However I suspect I will need to stop and remove the disaster recovery replication and reinitializing vm replication resulting in the loss of all previous recovery points.
Does anyone know for sure and what the process to convert the disks given VM replication would be.
Thx.
You need to reach out to the right Azure Support Team. The Azure Site Recovery support team should be able to give you the correct information, they handle disaster recovery replication scenario.
You want to make sure you are getting vetted information on issues like this.
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.
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.
AFAIK Amazon AWS offers so-called "regions" and "availability zones" to mitigate risks of partial or complete datacenter outage. Looks like if I have copies of my application in two "regions" and one "region" goes down my application still can continue working as if nothing happened.
Is there something like that with Windows Azure? How do I address risk of datacenter catastrophic outage with Windows Azure?
Within a single data center, your Windows Azure application has the following benefits:
Going beyond one compute instance, your VMs are divided into fault domains, across different physical areas. This way, even if an entire server rack went down, you'd still have compute running somewhere else.
With Windows Azure Storage and SQL Azure, storage is triple replicated. This is not eventual replication - when a write call returns, at least one replica has been written to.
Ok, that's the easy stuff. What if a data center disappears? Here are the features that will help you build DR into your application:
For SQL Azure, you can set up Data Sync. This facility synchronizes your SQL Azure database with either another SQL Azure database (presumably in another data center), or an on-premises SQL Server database. More info here. Since this feature is still considered a Preview feature, you have to go here to set it up.
For Azure storage (tables, blobs), you'll need to handle replication to a second data center, as there is no built-in facility today. This can be done with, say, a background task that pulls data every hour and copies it to a storage account somewhere else. EDIT: Per Ryan's answer, there's data geo-replication for blobs and tables. HOWEVER: Aside from a mention in this blog post in December, and possibly at PDC, this is not live.
For Compute availability, you can set up Traffic Manager to load-balance across data centers. This feature is currently in CTP - visit the Beta area of the Windows Azure portal to sign up.
Remember that, with DR, whether in the cloud or on-premises, there are additional costs (such as bandwidth between data centers, storage costs for duplicate data in a secondary data center, and Compute instances in additional data centers). .
Just like with on-premises environments, DR needs to be carefully thought out and implemented.
David's answer is pretty good, but one piece is incorrect. For Windows Azure blobs and tables, your data is actually geographically replicated today between sub-regions (e.g. North and South US). This is an async process that has a target of about a 10 min lag or so. This process is also out of your control and is purely for a data center loss. In total, your data is replicated 6 times in 2 different data centers when you use Windows Azure blobs and tables (impressive, no?).
If a data center was lost, they would flip over your DNS for blob and table storage to the other sub-region and your account would appear online again. This is true only for blobs and tables (not queues, not SQL Azure, etc).
So, for a true disaster recovery, you could use Data Sync for SQL Azure and Traffic Manager for compute (assuming you run a hot standby in another sub-region). If a datacenter was lost, Traffic Manager would route to the new sub-region and you would find your data there as well.
The one failure that you didn't account for is in the ability for an error to be replicated across data centers. In that scenario, you may want to consider running Azure PAAS as part of HP Cloud offering in either a load balanced or failover scenario.