Yes, I unmounted the lun before changing to the earlier bookmark.

How do you do this specifically?

You can check the properties of the group in the RecoverPoint console, it will show then the rollback to the point in time is complete

Thanks,

When you switched from the 4pm to the 12pm bookmark did you dismount the LUN first from the host?

When you are using Virtual Access you should be able to mount the LUN immediately, but since the access to the point in time is virtual it requires access to the journal volumes for the specific blocks from that point in time. This affects the performance of the LUN. You can check the properties of the group in the RecoverPoint console, it will show then the rollback to the point in time is complete.

In the RP console expand the Consitency Group then select the target site. Select the Journal tab and in the Image section it should display the status of the selected image and list the rollback %.

Hey there SanMan

Aran is spot on, as usual!

I used to this issue with the "wrong" file timestamps in support all the time.

The issue is that something on the mount host is keeping a handle on the filesystem(s).

So, when you present an older/newer version of the filesystem, the host believes it is the same filesystem as before.

What OS and patch level is the host?  The typical procedure to do this would be to either use

Replication Manager (looks after all this automatically)

or

Stopping image access

1) Ensure no user or process if referencing the RP bookmark's filesystem mount points

2) Unmount the filesystems

3) Vary off/export the VGs - if using a volume manager

4) Disable image acess

5) If using Windows - disable the volumes (with either Device manager or Kutils)

6) Rescan the host at a disk, and perferrably HBA level.

Then

Enabling image access

1) Enable your virtual or physical image

2) Rescan the host at a disk, and perferrably HBA level.

3) Vary on/import the VGs - if using a volume manager

4) Mount the filesystems

Hope this helps

James.

Between each test, I unmount the filesystem(s) and do a reconfiguration reboot.  It is a Solaris 9 server.  See the odd file timestamps below.  The bookmarks on the 18th actually have timestamps on the 19th.  And the control files should be the same in both locations. 

Selected bookmark 11/18 at 02:04:36

drwxr-x---   2 oracle   dba         1024 Oct 20 23:55 .

drwxr-xr-x   4 oracle   dba          512 May  1  2008 ..

-rw-r-----   1 oracle   dba      12582920192 Nov 19 09:45 pydata01.dbf

-rw-r-----   1 oracle   dba      524296192 Nov 18 00:36 PYT_sysaux01.dbf

-rw-r-----   1 oracle   dba      340795392 Nov 19 09:54 PYT_system01.dbf

-rw-r-----   1 oracle   dba      1572872192 Nov 18 22:13 PYT_temp01.dbf

-rw-r-----   1 oracle   dba      78651392 Nov 19 09:45 PYT_tools01.dbf

-rw-r-----   1 oracle   dba      838868992 Nov 18 00:51 PYT_undo01.dbf

-rw-r-----   1 oracle   dba      12075008 Nov 18 02:04 PYT_control01.ctl

-rw-r-----   1 oracle   dba      12075008 Nov 19 09:23 PYT_control02.ctl

Selected bookmark 11/18 at 02:00:36

-rw-r-----   1 oracle   dba      12582920192 Nov 19 09:45 pydata01.dbf

-rw-r-----   1 oracle   dba      524296192 Nov 18 00:36 PYT_sysaux01.dbf

-rw-r-----   1 oracle   dba      340795392 Nov 19 09:54 PYT_system01.dbf

-rw-r-----   1 oracle   dba      1572872192 Nov 18 22:13 PYT_temp01.dbf

-rw-r-----   1 oracle   dba      78651392 Nov 19 09:45 PYT_tools01.dbf

-rw-r-----   1 oracle   dba      838868992 Nov 18 00:51 PYT_undo01.dbf

-rw-r-----   1 oracle   dba      10371072 Nov 19 11:03 PYT_control01.ctl

-rw-r-----   1 oracle   dba      12075008 Nov 19 09:23 PYT_control02.ctl

Selected bookmark 11/19 at 14:05:27

-rw-r-----   1 oracle   dba      12582920192 Nov 18 00:02 pydata01.dbf

-rw-r-----   1 oracle   dba      524296192 Nov 18 02:05 PYT_sysaux01.dbf

-rw-r-----   1 oracle   dba      340795392 Nov 18 02:35 PYT_system01.dbf

-rw-r-----   1 oracle   dba      1572872192 Nov 18 22:13 PYT_temp01.dbf

-rw-r-----   1 oracle   dba      78651392 Nov 18 00:02 PYT_tools01.dbf

-rw-r-----   1 oracle   dba      838868992 Nov 18 02:35 PYT_undo01.dbf

-rw-r-----   1 oracle   dba      12075008 Nov 18 02:04 PYT_control01.ctl

-rw-r-----   1 oracle   dba      12075008 Nov 18 02:45 PYT_control02.ctl

Aran

As always you bring up very valid points and suggestions about our products, and in this case you are absolutely correct.

I have been pushing this internally for quite a while and there are a few technical and priority-related reasons why this support has not yet occurred.

The groupset feature of RP cannot be triggered, as you know as a once-off process, like say a bookmark.  If it were, it would have been a quick and easy win for Replication Manager team, because now in RM 5.2.2 they have that federated appset support (needed for their cool support of SharePoint).

So, I can tell you engineering know they need it and I know they are working on it.  Stay tuned for more information on same.

Sanman,

As this point in time, and considering how this is blocking you from progressing, I recommend you open an official customer support call.  They can webex into your environment and assist in this issue.  Of course, they can also get engineering involved where necessary.  But please do let us know how it is going.

Thanks!

James.

James,

Thanks for the response. I am trying understand this a little more. I created a series of RecoverPoint CLI scripts for creating bookmarks and accessing the newly created bookmarks at our DR site for testing and backup purposes. In my script it uses the following command to create a bookmark across all the CGs in my group set:

plink -ssh %PXDC_RPA1% -l admin -pw XXXXXXXX apply_parallel_bookmark groups=%GroupSet% bookmark=%Image%

Is RM unable to use that same process or is that not the issue?

Thanks,

Aran