RPC program or version mismatch - when trying to use nsrclone

Assuming that the backups are running ok , even manual backup from the client runs successful ,

then please check the clone storage node attribute for the client , and see if the appropriate name is updated
also if using a different NIC to backup data , please verify the server network interface on the client attribute ..

SwethaJustin, thank you for your response. It brings up more questions for me...

Does the storage node name need to be listed on the client in order for it to allow it to use that storage node for a clone?

I don't have anything listed for "Clone Storage Nodes" on Globals (2 of 2) on most of my clients.

Got this from the online help...
Clone storage nodes - This attribute specifies the hostnames of the storage nodes that are to be selected for the `save' side of clone operations. Cloned data originating from the storage node will be directed to the first storage node that has an enabled device and a functional media daemon (nsrmmd). There is no default value. If this attribute has no value, the server's 'clone storage nodes' will be consulted. If this attribute also has no value, then the server's 'storage nodes' attribute will be used to select a target node for the clone. The clone storage node affinity is determined from the client resource for the storage node where cloned data originates.

Is it unclear to me as to if this field matters when using nsrclone from the CLI. Or if this is only used for automatic cloning. If this field is used, I would expect nsrclone would respond with a message saying something about not having a valid storage node to clone to, as opposed to a RPC error. Can anyone shed any light on this?

Clone storage node field is used only for storage node clients and it says for storage node X where tape would be read what is going to be target storage node where clone would be written.

To your first question, the storage node names listed in the client configuration is the default storage nodes that the client will try to backup to. Even if a storage node is not listed in the client config, the client should still backup to it. This is my understanding and I haven't tried this so I am not certain.

The clone storage node field would be applicable for the manual clones as well. However, in your case, this value is likely to be overwritten by the -J option being specified. Would suggest that you try the cloning with the -J option.

Thank you for your comments Hari.

Unfortunately, I am already using -J and it's giving me this error - hence the reason for this post. Do you or anyone else know how I can troubleshoot this RPC error? Please keep in mind that backups run perfectly fine to this storage node, so I know the simple things are working fine (DNS resolution, network duplex mismatch, etc). I only get this when trying to start a clone job from the networker server to a remote storage node using nsrclone.


D:\>nsrclone -v -J BackupNWVH3 -b "Daily Clone" -S 3300409512
5874:nsrclone: Automatically copying save sets(s) to other volume(s)
6216:nsrclone:
Starting cloning operation...
39078:nsrclone: RPC error: RPC program or version mismatch


Thanks!

Sorry ... a slight typo ... I meant to say try the clone without the -J.

Unfortunately, that isn't getting me the results I want either. If I do not use the -J option, all the cloning happens on the networker server, it does not go to the storage node.

Thank you for the suggestion.

Am not sure if this will help you.

Your previous message seems to suggest to me that you have set the clone storage node value for the client from where the backup was initially taken. To redirect the nsrclone to write to a specific storage node, you would need to set the clone storage node value the backup server's client resource or in the source storage node's client resource. Found the following in the man page for nsrclone;

The target storage node of a clone is determined by the "clone storage nodes" attribute of the source storage node¿s client resource, the "clone storage nodes", or the "storage nodes" attribute of the server¿s client resource in descending priority. Please note that nsrclone never looks at the clone storage node affinity of the clients whose savesets are being clones.

Additionally, if the read host name value is set in your jukebox configuration, it will cause the volumes in that jukebox to be read specifically from the host mentioned in the read host name parameter.