qtree is currently involved in another operation

[NEWNETAPP987]

Hi,

I have a snapvault issue with one of my volumes.

If I do snapvault status -l it shows " transfer aborted becuase of network error: connection reset by peer

Then I try a snapvault update "destination volume"  but it reports " qtree is currently involved in another operation.

How do I restart the transfer and retain what has been transferred so far ?

Thanks,

[MSARETZOZ]

Hi,

same issue here. We have a scheduled OSSV-JOB at 2AM. This Job has 69 machines involved. The backup was successful with 49 machines. The others run into an error: "Qtree machinename:SystemState is involved in another transfer"

Only systemstate has this problem. All other backups of partitions or files work fine, even with those machines that have this error.

Is there a workaround???

Also it is very hard to understand those errormessages. We have had a lot of issues with this kind of backup. A Knowledgbase would be very helpful.

PS: a manual backup works fine, but if I start a backup of one machine and then start a backup of the other one it fails with this error. When I start it at the same time it works???????????????????????

[gdefevere]

Same over here. Only some SystemState relationships in OSSV are failing. You found any solution for this yet ?

[PIYUSHBANSAL198722]

any update on this ?? Looks to be the same issue as mine.....

[gdefevere]

We found our cause. We had moved OSSV destination volumes to another filer. Volumes had many snapvault relationships but the nearstore option wasn't enabled on this filer. If you have the same issue, you will see many "Defer (too many active transfers at once)" entries in the snapmirror.log. Obviously OSSV Systemstate relations aren't happy with this, because other snapvault relations didn't suffered from a defer. Number of concurrent snapvault updates depend on the filer type. You can activate the nearstore on 7mode systems through cmd : options licensed_feature.nearstore_option.enable on