You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| N/A | locations, for example `Atlantic Ocean`, `library`, `Eiffel Tower`, `Statue of Liberty`|`2019-10-01`|
47
-
| Geopolitical Entity (GPE) | Cities, countries, states for example `Seattle`, `Pennsylvania`, `South Africa`, `Tokyo`|`2020-02-01`|
47
+
| Geopolitical Entity (GPE) - English only| Cities, countries, states for example `Seattle`, `Pennsylvania`, `South Africa`, `Tokyo`|`2020-02-01`|
48
48
49
49
### Organization
50
50
51
51
Recognized organizations, corporations, agencies, and other groups of people. For example: companies, political groups, musical bands, sport clubs, government bodies, and public organizations. Nationalities and religions are not included in this entity type.
Copy file name to clipboardExpand all lines: articles/site-recovery/azure-to-azure-how-to-reprotect.md
+15-20Lines changed: 15 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,8 +13,7 @@ ms.author: rajanaki
13
13
---
14
14
# Reprotect failed over Azure VMs to the primary region
15
15
16
-
17
-
When you [fail over](site-recovery-failover.md) Azure VMs from one region to another using [Azure Site Recovery](site-recovery-overview.md), the VMs boot up in the secondary region, in an unprotected state. If fail back the VMs to the primary region, you need to do the following:
16
+
When you [fail over](site-recovery-failover.md) Azure VMs from one region to another using [Azure Site Recovery](site-recovery-overview.md), the VMs boot up in the secondary region, in an **unprotected** state. If you want to fail back the VMs to the primary region, you need to do the following:
18
17
19
18
- Reprotect the VMs in the secondary region, so that they start to replicate to the primary region.
20
19
- After reprotection completes and the VMs are replicating, you can fail them over from the secondary to primary region.
@@ -36,7 +35,7 @@ When you [fail over](site-recovery-failover.md) Azure VMs from one region to ano
36
35
37
36
### Customize reprotect settings
38
37
39
-
You can customize the following properties of the target VMe during reprotection.
38
+
You can customize the following properties of the target VM during reprotection.
@@ -49,7 +48,6 @@ You can customize the following properties of the target VMe during reprotection
49
48
|Cache Storage | You can specify a cache storage account to be used during replication. By default, a new cache storage account is be created, if it doesn't exist. |
50
49
|Availability Set |If the VM in the secondary region is part of an availability set, you can choose an availability set for the target VM in the primary region. By default, Site Recovery tries to find the existing availability set in the primary region, and use it. During customization, you can specify a new availability set. |
51
50
52
-
53
51
### What happens during reprotection?
54
52
55
53
By default the following occurs:
@@ -64,31 +62,28 @@ When you trigger a reprotect job, and the target VM exists, the following occurs
64
62
1. The target side VM is turned off if it's running.
65
63
2. If the VM is using managed disks, a copy of original disks are created with '-ASRReplica' suffix. The original disks are deleted. The '-ASRReplica' copies are used for replication.
66
64
3. If the VM is using unmanaged disks, the target VM's data disks are detached and used for replication. A copy of the OS disk is created and attached on the VM. The original OS disk is detached and used for replication.
67
-
4. Only changes between the source disk and the target disk are synchronized. The differentials are computed by comparing both the disks and then transferred. To find the estimated time check below.
68
-
5. After the synchronization completes, the delta replication begins, and creates a recovery point in line with the replication policy.
65
+
4. Only changes between the source disk and the target disk are synchronized. The differentials are computed by comparing both the disks and then transferred. Check below to find the estimated time to complete the reprotection.
66
+
5. After the synchronization completes, the delta replication begins, and a recovery point is created in line with the replication policy.
69
67
70
68
When you trigger a reprotect job, and the target VM and disks do not exist, the following occurs:
71
69
1. If the VM is using managed disks, replica disks are created with '-ASRReplica' suffix. The '-ASRReplica' copies are used for replication.
72
70
2. If the VM is using unmanaged disks, replica disks are created in the target storage account.
73
71
3. The entire disks are copied from the failed over region to the new target region.
74
-
4. After the synchronization completes, the delta replication begins, and creates a recovery point in line with the replication policy.
72
+
4. After the synchronization completes, the delta replication begins, and a recovery point is created in line with the replication policy.
75
73
76
-
#### Estimated time to do the reprotection
74
+
#### Estimated time to do the reprotection
77
75
78
-
In most cases, Azure Site Recovery doesn’t replicates the complete data to the source region.
79
-
Below are the conditions that determines how much data would be replicated:
76
+
In most cases, Azure Site Recovery doesn’t replicate the complete data to the source region.
77
+
Below are the conditions that determines how much data would be replicated:
80
78
81
-
1. If the source VM data is deleted, corrupted or inaccessible due to some reason like resource group change/delete then during reprotection complete IR will happen as there is no data available on the source region to use.
82
-
2. If the source VM data is accessible then only differentials are computed by comparing both the disks and then transferred. Check the below table to get the estimated time
79
+
1. If the source VM data is deleted, corrupted, or inaccessible due to some reason, like a resource group change/delete, then during reprotection a complete Site Recovery will happen as there is no data available on the source region to use.
80
+
2. If the source VM data is accessible, then only differentials are computed by comparing both the disks and then transferred. Check the table below to get the estimated time.
83
81
84
-
|**Example situation **|**Time taken to Reprotect**|
85
-
|---|---|
86
-
|Source region has 1 VM with 1 TB standard Disk<br/>- Only 127 GB data is used and rest of the disk is empty<br/>- Disk type is standard with 60 MiB/S throughput<br/>- No data change after failover| Approximate time 45 minutes – 1.5 hours<br/> - During reprotection Site Recovery will populate the checksum of whole data which will take 127 GB/ 45 MBs ~45 minutes<br/>- Some overhead time is required for Site Recovery to do auto scale that is 20-30 minutes<br/>- No Egress charges |
87
-
|Source region has 1 VM with 1 TB standard Disk<br/>- Only 127 GB data is used and rest of the disk is empty<br/>- Disk type is standard with 60 MiB/S throughput<br/>- 45 GB data changes after failover| Approximate time 1 hours – 2 hours<br/>- During reprotection Site Recovery will populate the checksum of whole data which will take 127 GB/ 45 MBs ~45 minutes<br/>- Transfer time to apply changes of 45 GB that is 45 GB/ 45 MBps ~ 17 minutes<br/>- Egress charges would be only for 45 GB data not for the checksum|
82
+
|Example situation |Time taken to Reprotect |
83
+
|---|---|
84
+
|Source region has 1 VM with 1 TB standard Disk<br/>- Only 127 GB data is used, and the rest of the disk is empty<br/>- Disk type is standard with 60 MiB/S throughput<br/>- No data change after failover| Approximate time: 45 minutes – 1.5 hours<br/> - During reprotection, Site Recovery will populate the checksum of all data which will take 127 GB/ 45 MBs ~45 minutes<br/>- Some overhead time is required for Site Recovery to auto scale: approx. 20-30 minutes<br/>- No Egress charges |
85
+
|Source region has 1 VM with 1 TB standard Disk<br/>- Only 127 GB data is used and rest of the disk is empty<br/>- Disk type is standard with 60 MiB/S throughput<br/>- 45 GB data changes after failover| Approximate time: 1 hours – 2 hours<br/>- During reprotection, Site Recovery will populate the checksum of all data which will take 127 GB/ 45 MBs ~45 minutes<br/>- Transfer time to apply changes of 45 GB that is 45 GB/ 45 MBps ~ 17 minutes<br/>- Egress charges would be for 45 GB data changes, not for the checksum|
88
86
89
-
90
-
91
-
92
87
## Next steps
93
88
94
-
After the VM is protected, you can initiate a failover. The failover shuts down the VM in the secondary region, and creates and boots VM in the primary region, with some small downtime. We recommend you choose a time accordingly, and that you run a test failover before initiating a full failover to the primary site. [Learn more](site-recovery-failover.md) about failover.
89
+
After the VM is protected, you can initiate a failover. The failover shuts down the VM in the secondary region and creates and boots the VM in the primary region, with some small downtime during this process. We recommend you choose an appropriate time for this process and that you run a test failover before initiating a full failover to the primary site. [Learn more](site-recovery-failover.md) about Azure Site Recovery failover.
0 commit comments