This post is more than 5 years old
15 Posts
0
1038
Solutions Enabler 6.4.2 Restore to a R1 volume.
Hi folks,
I am doing some TSIMSNAP testing at the moment, and as part of this am attempting a restore to a R1 volume. In the past we would have run a symmir -g {device group} -restore -noprompt command, which would restore the volume. But since upgrading to SE 6.4.2 running the same command causes the following error to be displayed:
The device is not in a valid RDF state for this operation
From Primus solution emc152639, I see that the ability to restore to a R1 volume has changed in 6.4.2 and that we now need to use the command symmir -g {device group} -remote -restore.
Does this new command do anything different, when compared to the old command? In the old command, the restore was performed on the R1, with the changes replicated to the R2. Does this new command do the same, or does it do something to the R2? We need to replicate the restore changes to the R2 in real time, so a suspend of the RDF link is not an option.
Any help, or clarification appreaciated.
Regards,
D
I am doing some TSIMSNAP testing at the moment, and as part of this am attempting a restore to a R1 volume. In the past we would have run a symmir -g {device group} -restore -noprompt command, which would restore the volume. But since upgrading to SE 6.4.2 running the same command causes the following error to be displayed:
The device is not in a valid RDF state for this operation
From Primus solution emc152639, I see that the ability to restore to a R1 volume has changed in 6.4.2 and that we now need to use the command symmir -g {device group} -remote -restore.
Does this new command do anything different, when compared to the old command? In the old command, the restore was performed on the R1, with the changes replicated to the R2. Does this new command do the same, or does it do something to the R2? We need to replicate the restore changes to the R2 in real time, so a suspend of the RDF link is not an option.
Any help, or clarification appreaciated.
Regards,
D
xe2sdc
2 Intern
2 Intern
•
2.8K Posts
0
December 12th, 2007 07:00
-remote Applies only for a split of a BCV RDF1
device, or for a restore from a BCV to a
STD RDF1 device. If this flag is specified,
then the data is also propagated to the
remote mirror of the RDF device and the
RDF link is resumed if necessary. If this
flag is not specified, then the default is
not to propagate the data to the remote
mirror of the RDF device.
It looks like it's the right flag for you .. It will push data to R2 devices, eventually resuming the link if needed. Could you plese issue a symrdf query command and show the output ??
xe2sdc
2 Intern
2 Intern
•
2.8K Posts
0
December 12th, 2007 06:00
What version of S.E. were you using before reaching 6.4.2 ??
Usually "-remote" flag refers to "the other side of the RDF link" ..
Are you issuing commands from R2 side ??
cecida
15 Posts
0
December 12th, 2007 07:00
Was using v6.0.3. Apologies I enclosed the wrong primus, correct solution ID is emc150170. I am running the restore command from the R1 side, and restoring to the R1 device from the local BCV. This always worked with previous versions of SE, but according to the primus solution v.6.3 and above now require the -remote flag. I am curious as to what the -remote flag does, and what (if any) changes it makes to the RDF link or R2 volume during the course of the restore. The R2 side must be in sync with the R1 volume at all times, and this includes during a restore.
D