OB3.1 vs SQL Server 6.5 integration (194 Views)
Zelenskii Andrei
Posts: 28
Registered: ‎08-16-2000
Message 1 of 4 (194 Views)
Accepted Solution

OB3.1 vs SQL Server 6.5 integration

When trying to backup MS SQL database
OmniBack3.1 console issue following message:
DB-library message:
Can't open dump device '\.pipepubs0', device error or device offline

In MSSQL network setup, option Named Pipes is marked. Utilities makepipe, readpipe are worked.

Is there some additional configuration need on OB or MSSQL side?

Thanks for help!
Zelenskii Andrei
Posts: 28
Registered: ‎08-16-2000
Message 2 of 4 (194 Views)

Re: OB3.1 vs SQL Server 6.5 integration

Sorry for triple.
Valued Contributor
Isabel Romero
Posts: 68
Registered: ‎08-23-2000
Message 3 of 4 (194 Views)

Re: OB3.1 vs SQL Server 6.5 integration

I think the problem is in SQL configuration. I had the same problem and the SQL administrator configured the SQL to support dump device. Then the backup ran correctly.

Sorry, but I don't know more about SQL configuration.
Honored Contributor
Joseph T. Wyckoff
Posts: 2,722
Registered: ‎05-31-2000
Message 4 of 4 (194 Views)

Re: OB3.1 vs SQL Server 6.5 integration

Actually that symptom is fairly generic.

Look for name resolution issues and account/security issues. Either one is a common cause of this. The stepa are in the manual, but it isn't necessarily obvious what you are doing with any given step...

1. Doublecheck that the NT Servername matches the hostname/name that Omniback is using, and if you have multiple network cards on the SQL server, import them as 'virtual hosts' into Omniback.

2. Make sure the Omniinet service on the SQL server is running as a named user. That named user must be an administrator of the local machine in order for normal backups to take place. That user should be someone that is also an administrator/su in the SQL environment. Finally, that user should be an Omniback administrator.

Often the omninet service is running as the local system authority - this is fine for file system backups, and can work with the more complex integrations, but it is often simpler just to define a known, consistent user with all the right you need, and just be done with it. The Local System Authority generally can do 'everything' within its own security domain - but that security domain does NOT cross the network, or into applications such as Oracle, SQL, and Exchange.

Omniback logs into sql in order to begin backups, hence the account needs to have sql rights (although this part is a bit flexible, you can run the backup job as a particular user...)

SQL opens up one side of a named pipe (these get NT security) and Omniback opens the other side. If there is a security mis-match (one can read/write, but the other can't....) or a name mis-match (opened for write on server_1 opened for read on server-1) then we are dead in the water.

Let me also ask you to go ahead and find and download patches for your version of Omniback, if they are available. There are some important fixes for the NT environment in patches for OB II 2.55, 3.0 and 3.1 I recommend downloading the patches, and at least reading the readme. After reading the readme, I expect you will want to install the patch...Remember that the NT and UX environments are patched separately.

Thanks for using Omniback.