Dell DR4300 DR Series System Administrator Guide - Page 17

Reverse Replication

Page 17 highlights

target and replication re-synchronization is done to complete any pending data transfers. Thereby, continuous replication can be done, which reduces network traffic significantly, and data can be replicated and synced with the target in a short amount of time. NOTE: The following scenarios are not supported for seeding: • Import AND export from one share/device cannot occur at the same time. • Import from one share/device cannot be completed from multiple locations at the same time. • Export to a mount point can be completed only from one seed job. Multiple seed export jobs cannot send data to a single mount point. You initiate seeding using CLI, and the data to be seeded is gathered in an organized manner and stored in the target devices. Refer to the Dell DR Series System Command Line Reference Guide for more information about replication seeding support. Reverse Replication The concept of reverse replication is not a supported operation on DR Series systems. This is because replica containers are always in a R-O (read-only) mode on the DR Series system, thus making write operations a nonsupported operation. Alternate Ways to Retrieve Data Under very specific conditions, it might be possible for replica containers to support a type of write operation whose sole function is to restore data from an archival target. For example, data could be replicated back to the remote site where a data management application (DMA), or backup software, is connected to allow this data to be restored directly. This specific type of case applies only to configurations where data is backed up from a remote location to a local container, and then replicated over a WAN to a replica container that is backed up to tape. The data needs to be restored from the tape backup to the original location; first back to a DR Series system replica container, and then back to the original source location of the data on the other side of the WAN link. NOTE: If you choose to use this alternate workaround method, you must set up a new data storage unit in the DMA, and import the images before a restore to the original location can occur. To leverage this type of deduplication across the WAN, complete the following: 1. Make sure that the replication operation has completed (between source and target). 2. Delete the current replication relationship, and re-create a replication relationship (reversing the source and target roles). 3. Restore data to the original source container (now the target). 4. Make sure that the replication operation has completed. 5. Delete the replication relationship and re-create a replication relationship (restoring original source and target destinations). Under this scenario, a fraction of the data to be recovered is sent across the WAN link. This could speed up a remote restore significantly. However, there are some downsides to this type of scenario: • If step 1 is not followed correctly, any changes not fully replicated are lost. • During steps 2 and 3, any data that is written to the original DR Series system source container may be lost. • During step 4, if the data is not fully replicated back before the switch is made, it may be lost. Alternatively, you could still support this type of effort by completing the following: 1. Create a new container on the target DR Series system. 17

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186

target and replication re-synchronization is done to complete any pending data transfers. Thereby, continuous
replication can be done, which reduces network traffic significantly, and data can be replicated and synced with the
target in a short amount of time.
NOTE:
The following scenarios are not supported for seeding:
Import AND export from one share/device cannot occur at the same time.
Import from one share/device cannot be completed from multiple locations at the same time.
Export to a mount point can be completed only from one seed job. Multiple seed export jobs cannot send data
to a single mount point.
You initiate seeding using CLI, and the data to be seeded is gathered in an organized manner and stored in the target
devices. Refer to the
Dell DR Series System Command Line Reference Guide
for more information about replication
seeding support.
Reverse Replication
The concept of reverse replication is not a supported operation on DR Series systems. This is because replica
containers are always in a R-O (read-only) mode on the DR Series system, thus making write operations a non-
supported operation.
Alternate Ways to Retrieve Data
Under very specific conditions, it might be possible for replica containers to support a type of write operation whose
sole function is to restore data from an archival target. For example, data could be replicated back to the remote site
where a data management application (DMA), or backup software, is connected to allow this data to be restored
directly.
This specific type of case applies only to configurations where data is backed up from a remote location to a local
container, and then replicated over a WAN to a replica container that is backed up to tape. The data needs to be
restored from the tape backup to the original location; first back to a DR Series system replica container, and then back
to the original source location of the data on the other side of the WAN link.
NOTE:
If you choose to use this alternate workaround method, you must set up a new data storage unit in the
DMA, and import the images before a restore to the original location can occur.
To leverage this type of deduplication across the WAN, complete the following:
1.
Make sure that the replication operation has completed (between source and target).
2.
Delete the current replication relationship, and re-create a replication relationship (reversing the source and target
roles).
3.
Restore data to the original source container (now the target).
4.
Make sure that the replication operation has completed.
5.
Delete the replication relationship and re-create a replication relationship (restoring original source and target
destinations).
Under this scenario, a fraction of the data to be recovered is sent across the WAN link. This could speed up a remote
restore significantly. However, there are some downsides to this type of scenario:
If step 1 is not followed correctly, any changes not fully replicated are lost.
During steps 2 and 3, any data that is written to the original DR Series system source container may be lost.
During step 4, if the data is not fully replicated back before the switch is made, it may be lost.
Alternatively, you could still support this type of effort by completing the following:
1.
Create a new container on the target DR Series system.
17