Can someone please explain below statement from the documentation:
"In open systems environments, Enginuity sets the target device and the virtual device to the Not Ready state while protection bits are set. The target device automatically becomes available for use (Ready) as soon as protection bits are set. Enginuity then begins copying the tracks until all protected tracks have been restored."
Basically it says the device will be ready as soon as the protection bits are set. so then what happens if there are more writes from host as the device is now available (more importantly if the tracks which are going to be copied by restore session modified further)?
In other words, aren't the devices (both source and target should be in 'not ready') state as long as 'restore' is undergoing and once the restore is complete it should be 'ready'.
The target is kept in a not ready state to prevent the host from accessing it so the data on it remains unchanged. The user can set it to ready immediately after the restore command is issued if they wish, but if the data is changed then it will lose it's point-in-time and you will not be able to restore from that point-in-time again if needed.
Writes to tracks that have not been restored yet (still protected) are similar to writes to protected tracks in a clone copy session. A write to the source will clear protection and the track will not need to be copied from the target during the restore. And write to target will force the original track to be copied to source. This is why the source can be made ready as soon as the restore command completes but before the copy completes.
>>>>> The user can set it to ready immediately after the restore command is issued if they wish, but if the data is changed then it will lose it's point-in-time and you will not be able to restore from that point-in-time again if needed. <<<<
Still didn't get it. If the data is changes, it will lose its point of time - I got that as user explicitly changes by making the device ready. But I didn't get the following statement 'you will not be able to restore from that point-in-time again if needed'
Isn't user can remove restore session once the restore is completed and then try to restore the session again from the target dev (from virtual copy session).
>>>> This is why the source can be made ready as soon as the restore command completes but before the copy completes.
So essentially user can access the lun - but its his/her own as there is potential for the copy is no longer point-in-time especially when the protected tracks are re-written by user after restore. Most likely users will wait for restore to complete I guess, to avoid this risk because essentially that's why they took this virtual copy - to get back to the 'Point-In-Time'.
Sorry for the confusion. I didn't mean that a restore command is not allowed, was just trying to say the data/point-in-time is changed once VDEV is written to. Leaving the VDEV Not Ready protects from this, so be sure there is a specific reason to Ready it, otherwise just leave it NR.
There is no risk in accessing the Source (standard) device before restore is complete. The user should never be presented with the incorrect point-in-time; If the track has not copied yet it will be redirected to the VDEV.