locked
Azure Data migration from On-premise, need a solution RRS feed

  • Question

  • I have 5 TB of data in the on-premise. I would like to achieve as below as I have huge data inflow on a  monthly basis. We also have bandwidth restriction of 500Mbps

    On-premise ----- 10 days retention, primary copy
    Azure - Retention 60 days, Secondary Copy
    Other Cloud Platforms like AWS/GCP, 3rd copy

    How do I configure storage options to backup my data from my secondary site i.e, Azure to other cloud platforms.

    How to configure HA from 3rd copy to Primary?

    What will be the RTO & RPO for my data from Azure to AWS/GCP or Vice-versa?
     
    Thursday, October 31, 2019 7:22 AM

Answers

  • If you are looking  Azure Site Recovery service contributes to your disaster recovery strategy by managing and orchestrating replication, failover, and failback of on-premises machines, and Azure virtual machines (VMs).

    Set up disaster recovery to Azure for on-premises physical servers

    In RPO threshold, specify the recovery point objective (RPO) limit. This value specifies how often data recovery points are created. An alert is generated if continuous replication exceeds this limit.

    Azure site recovery support four types of Disaster Recovery as a Service:

      • Azure to Azure site recovery
      • VMware to Azure site recovery
      • Hyper-V to Azure site recovery
      • On-premises (physical server) to Azure site recovery

      This blog is focusing on On-Premises (physical server) to Azure site recovery.

      Azure Site Recovery for On-Premises to Azure Disaster Recovery

      Note: Traffic replicates to Azure storage public endpoints over the internet. Alternately, you can use Azure ExpressRoute with public peering. Replicating traffic over a site-to-site virtual private network (VPN) from an on-premises site to Azure isn't supported.

      And for failback - To fail back, you need a VPN connection (or ExpressRoute) from the Azure network to the on-premises site.

      • RPO stands for recovery POINT objective, i.e., how much data is one potentially prepared and willing to lose, worse case
    • RTO stands for recovery TIME objective, i.e., if/when the ‘bad thing’ happens, how much time does it take to be back up and running again

    Recovery time objective (RTO): The amount of time that it takes to complete a recovery or restore.

    Azure backup solutions have high RTO’s because of the larger RPO, the amount of data that a backup solution needs to process is typically much higher, which leads to longer RTOs.

    Azure site Recovery solutions have smaller RTOs because they are more in sync with the source. Fewer changes need to be processed.

    Keep recovery time objectives (RTO) and recovery point objectives (RPO) within organizational limits. Site Recovery provides continuous replication for Azure VMs and VMware VMs, and replication frequency as low as 30 seconds for Hyper-V. You can reduce RTO further by integrating with Azure Traffic Manager.

     Many of us first reaction is they want RTO and RPO of zero (i.e. NO data loss with no downtime).

     

    While this is technically possible, RPOs of zero require synchronous replication.  Synchronous replication by design require multiple writes/updates/deletes in multiple locations before giving an ACK back to the application.  These additional transactions to multiple locations may introduce unacceptable performance, typically due to network distances and associated latency (think speed of light overhead).

     

    More traditional IaaS Azure business continuance and disaster recovery solutions like Azure backup and Azure Site Recovery (ASR), as well as many of our Azure Marketplace partner protection solutions, are generally asynchronous by design and therefore provide RPOs > 0.

     

    From a design perspective it is nearly impossible to guarantee specific RPOs and RTOs for these types of solutions because many variables are outside of your control, HOWEVER, here are some general guidelines…

     

    RPO of backup solutions are most dependent on the backup policies.  For example, if someone setups up a daily backup policy, then the RPO is closer to a day.

     

    RPO of replication solutions are often most dependent on the distance separating the two sites.  For example, when someone configures ASR to replicate across two regions, then the RPO is more likely to be in the ~seconds to many seconds range.

     

    When designing for RTO it is important to understand the variables that are not always in your control.  For example, if someone initiates a restore, the time it takes to be back up and running is dependent on variables like the size of the restore, available network bandwidth, speed of the disk drives/VMs, etc.

    In summary, it is difficult to guarantee RPO/RTO targets as there are many dependencies not necessarily in your control but it is still critically important to understand your RPO and RTO targets from a requirements gathering perspective.  Knowing if your requirements are truly RPO and/or RTO of zero, a minute or two, a few hours, daily, etc, can help you design the most appropriate Azure based solution.

    For more information on Backup and recovery: Refer to this article

    Hope this helps! 

    Kindly let us know if the above helps or you need further assistance on this issue.
    ------------------------------------------------------------------------------------------

    Do click on "Mark as Answer" and Upvote on the post that helps you, this can be beneficial to other community members.

    Friday, November 8, 2019 5:09 PM

All replies

  • Hi,

    Sorry can you confirm your requirements?  You have 5TB on prem storage (of what?).  Do you currently use Azure for backup with the 60 day retention or separate services?

    I need more info to advise.

    Thanks,

    Matt  

    Thursday, October 31, 2019 11:46 PM
  • @Vivan RA Can you clarify if this is backup , DR or migration use case?

    Based on retention policies in your query it looks like a backup need.Can you clarify the needs of RPO and RTO on this scenario?


    Friday, November 1, 2019 5:46 AM
  • Is there any update on the issue?

    If the suggested answer helped for your issue, do click on "Mark as Answer" and “Vote as Helpful” on the post that helps you, this can be beneficial to other community members.

    Monday, November 4, 2019 6:51 AM
  • Vivan, 

    You could leverage the use of Azure File sync to resolve the On premise/Azure retention issue, for the third point the result would vary based on the location of data centers on both ends: source and destination. If you want to go manual on data transfer(in Azure), you could use services such as Databox:https://azure.microsoft.com/en-us/services/databox/ 
    Monday, November 4, 2019 5:34 PM
  • Hi Adam,

    We can't do DR restore manually.  We are looking for DR solution from 3rd copy to on-premise. What will be RTO/RPO for restoring the data from different cloud vendors. 

    Do you have any plugin?

    Note: Our 3rd copy can be in Azure as well. 

    Tuesday, November 5, 2019 7:12 AM
  • If you are looking  Azure Site Recovery service contributes to your disaster recovery strategy by managing and orchestrating replication, failover, and failback of on-premises machines, and Azure virtual machines (VMs).

    Set up disaster recovery to Azure for on-premises physical servers

    In RPO threshold, specify the recovery point objective (RPO) limit. This value specifies how often data recovery points are created. An alert is generated if continuous replication exceeds this limit.

    Azure site recovery support four types of Disaster Recovery as a Service:

      • Azure to Azure site recovery
      • VMware to Azure site recovery
      • Hyper-V to Azure site recovery
      • On-premises (physical server) to Azure site recovery

      This blog is focusing on On-Premises (physical server) to Azure site recovery.

      Azure Site Recovery for On-Premises to Azure Disaster Recovery

      Note: Traffic replicates to Azure storage public endpoints over the internet. Alternately, you can use Azure ExpressRoute with public peering. Replicating traffic over a site-to-site virtual private network (VPN) from an on-premises site to Azure isn't supported.

      And for failback - To fail back, you need a VPN connection (or ExpressRoute) from the Azure network to the on-premises site.

      • RPO stands for recovery POINT objective, i.e., how much data is one potentially prepared and willing to lose, worse case
    • RTO stands for recovery TIME objective, i.e., if/when the ‘bad thing’ happens, how much time does it take to be back up and running again

    Recovery time objective (RTO): The amount of time that it takes to complete a recovery or restore.

    Azure backup solutions have high RTO’s because of the larger RPO, the amount of data that a backup solution needs to process is typically much higher, which leads to longer RTOs.

    Azure site Recovery solutions have smaller RTOs because they are more in sync with the source. Fewer changes need to be processed.

    Keep recovery time objectives (RTO) and recovery point objectives (RPO) within organizational limits. Site Recovery provides continuous replication for Azure VMs and VMware VMs, and replication frequency as low as 30 seconds for Hyper-V. You can reduce RTO further by integrating with Azure Traffic Manager.

     Many of us first reaction is they want RTO and RPO of zero (i.e. NO data loss with no downtime).

     

    While this is technically possible, RPOs of zero require synchronous replication.  Synchronous replication by design require multiple writes/updates/deletes in multiple locations before giving an ACK back to the application.  These additional transactions to multiple locations may introduce unacceptable performance, typically due to network distances and associated latency (think speed of light overhead).

     

    More traditional IaaS Azure business continuance and disaster recovery solutions like Azure backup and Azure Site Recovery (ASR), as well as many of our Azure Marketplace partner protection solutions, are generally asynchronous by design and therefore provide RPOs > 0.

     

    From a design perspective it is nearly impossible to guarantee specific RPOs and RTOs for these types of solutions because many variables are outside of your control, HOWEVER, here are some general guidelines…

     

    RPO of backup solutions are most dependent on the backup policies.  For example, if someone setups up a daily backup policy, then the RPO is closer to a day.

     

    RPO of replication solutions are often most dependent on the distance separating the two sites.  For example, when someone configures ASR to replicate across two regions, then the RPO is more likely to be in the ~seconds to many seconds range.

     

    When designing for RTO it is important to understand the variables that are not always in your control.  For example, if someone initiates a restore, the time it takes to be back up and running is dependent on variables like the size of the restore, available network bandwidth, speed of the disk drives/VMs, etc.

    In summary, it is difficult to guarantee RPO/RTO targets as there are many dependencies not necessarily in your control but it is still critically important to understand your RPO and RTO targets from a requirements gathering perspective.  Knowing if your requirements are truly RPO and/or RTO of zero, a minute or two, a few hours, daily, etc, can help you design the most appropriate Azure based solution.

    For more information on Backup and recovery: Refer to this article

    Hope this helps! 

    Kindly let us know if the above helps or you need further assistance on this issue.
    ------------------------------------------------------------------------------------------

    Do click on "Mark as Answer" and Upvote on the post that helps you, this can be beneficial to other community members.

    Friday, November 8, 2019 5:09 PM