2010-05-26 03:23 AM
I am in the process of setting up multiple OSSV backups using Protection Manager at a customers site, but for some reason I am getting the above error on some of the servers but other servers are running fine.....
They have got Operations Manager 184.108.40.20653 (4.0) installed. The Netapp Host Agent version is 2.7 and the OSSV client version is 2.6.1
I have changed the NDMP port to 10001 as they currently have Backupexec agents installed.
fasc1col01> Wed May 26 11:10:21 BST [fasc1col01: recover.abort.ROOLR:notice]: The abort event, snapmirror: Read Socket received EOF. , is just notified.
Wed May 26 11:10:24 BST [fasc1col01: replication.dst.err:error]: SnapVault: destination transfer from smcrfile02:SystemState to /vol/ossv_smcrfile02_backup/ossv_smcrfile02_smcrfile02_SystemState : could not read from socket.
Also, I have noticed an error on the server which I am not sure if it is releated...
Faulting application qsmserver.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00000198.
I have read through all the posts on here with a similar error message and none of them appear to be a fix.
Any help will be very much appreciated.
2010-05-27 08:43 AM
We have this error a number of times when using OSSV. In our experience its always been related to not enough disk space on the OSSV client. There needs to be enough space for OSSV database to be written to on the source. When we have had this issue, we either free up additional space on the dive where the OSSV client is installed, or if that isnt possible, to move the OSSV database to a different drive on the server.
Hope this helps
2010-05-28 01:48 AM
I have checked the free space on the drives they have at least 30g free on each of the servers....
I was also requested by Netapp to reboot the servers which I done out of hours last night, but we are still seeing the same error messages... they do however now seem to be limited to the Systemstate OSSV jobs....
2010-06-07 08:10 AM
We have the same problem when trying to take make a baseline from a System State on a Windows 2008 R2 server.
The snapvault of the data however works fine under w2k8-R2.
It seems that Windows 2008 R2 is not yet supported in the latest version of OSSV (2.6.1)
2010-06-07 11:38 PM
This could be a little off base - but I was getting a very similar error on my SnapMirror update.
Turned out to be an error with the snapmirror.allow file.
Have you checked the options snapvault.access host=
2010-06-09 07:49 AM
Another option to look at (though it should not be related) is
There are conditions where this option can be consulted incorrectly and prevent access to a SnapVault primary filer with this exact message. In my environment I have developed the habit of populating both "options snapvault.allow" and "options snapmirror.allow" with the same host list. I have some information on the causes of this stashed away in email somewhere, and will see if I can dig it up.
2010-12-09 08:28 AM
Is this Problem solved? I have Problem with the OSSV too. My Console Message ist this one:
Thu Dec 9 17:02:02 CET [email@example.com:error]: SnapVault: source transfer from "Source" to "Destination" : vfiler has no access to this source.
Thu Dec 9 17:02:02 CET [replication.dst.err:error]: SnapVault: destination transfer from "Source" to "Destination" : source is offline, is restricted, or does not exist.
The Error Occurs, after he has replicated 3/4 of the data.
snapvault status -l:
Mirror Timestamp: Tue Dec 7 12:33:45 CET 2010
Base Snapshot: ""
Current Transfer Type: Retry
Current Transfer Error: could not read from socket
Last Transfer Type: Initialize
Last Transfer Size: 238399824 KB
Last Transfer Duration: 10:29:14
Last Transfer From: ""
We have two Server, where this Error occurs. This Server have the even data on it. (W2K STD SP2)
Strange Thing now is, its only one Folder on the Servers, which have the same Data in it. Other Folder works really fine.
We tried lot of things, reinitialize, deleted db of ossv and recreatet it.
Only thing that has changed, was the Ontap Update to 7.3.4P3.
OSSV will be handelt over OPM 220.127.116.1132
But the errors on the Server, doesnt occurs at the same time, there was a lag of 3 Weeks, after de Second Server broke up the relation..
Any Ideas? Thanks in Advance