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
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???????????????????????