Unsolved

This post is more than 5 years old

11 Posts

1353

June 4th, 2007 09:00

SanCopy Errors in RM5.0.2

I just upgraded from RM4 to RM5.0.2. My old application sets and jobs were not as clean as I would have liked so I deleted everything down to the storage and recreated the application sets, storage pools, jobs, and schedules (no big deal, I only have a dozen or so).

SnapView snaps are working great.

Some of my SanCopy incremental jobs work fine, but two of them (one is NTFS source, the other is SQL2000) consisently error like this:

2007 06 02 12:17:15 mail03b 000033 ERROR: Function dcSANCopyMarkSessions failed.
2007 06 02 12:17:15 mail03b 000618 ERROR: Replication Manager was unable to unmark the Incremental SAN Copy session clariion_RMINC-APM00012345678_0030-061116130145 on array APM00012345678.

Note that the initial SanCopy incremental session went without error.

Any suggestions appreciated!

Jake

Message was edited by:
primoprimus

7 Posts

August 16th, 2007 04:00

thanks
but I unselected "mount the replica volume read only" and "unmount the replica on job completion" and I stay with it select too?

And where is the option for the log of exchange to be truncated or not
Thanks
Olivier

257 Posts

August 16th, 2007 04:00

Yes indeed - thats correct :)

Best of luck
James.

7 Posts

August 16th, 2007 05:00

My sequence is this
One job with SnapView Clone with mount option on a mount host with eseutil with mount replica in read only and unmount at the end
the second job, witch start at the end of the first, is SanCopy Full on the clone thaht I create with the first job to another CX

and when I do it in simulationin separate it works, and when I coupple it, it fails at the san copy job with the error that I send you before

SO I don't understand why
Thanks
Olivier

257 Posts

August 16th, 2007 05:00

Olivier -
I dont understand your first sentence - but Readonly & Unmount does not matter - you still need to ensure it creates a san.

The VSS Readonly bit is above Lun R/W access. ie Windows will still use sysvol to write to the volume metadata - affecting SCopy.

Have a look at the User Guide - Exchange section for how to truncate :)

Cheers
James

257 Posts

August 16th, 2007 06:00

Olivier
It is because of the additional sanity checking Replication Manager performs when you link jobs like this. There is no workaround.

James.

7 Posts

August 16th, 2007 06:00

what is sanity?

7 Posts

August 16th, 2007 06:00

but this two coupled jobs work in RM/SE, so how can I do?

257 Posts

August 22nd, 2007 00:00

Sanity, in this context of "sanity checking" means that

RM will check to make sure that the current state of the replica is in an appropriate state to support a SanCopy session without issues occurring.

RM logically decides that the best sane state for the SanCopy source (ie your local clone) is to be in a steady state where no writes are occurring during the SanCopy session.
And so, RM makes the decision to inform the user (thats you :)) that no, the local Clone is not in a protected state when it is mounted directly without a snap - ie writes could occur on the SanCopy source lun.

Hope this helps
James
No Events found!

Top