Data Protector Practitioners Forum

complete hang of the DB ? => velocis daemon error

Regular Contributor.

complete hang of the DB ? => velocis daemon error

OS : Win NT4 SP5

Serious problem with OBII:
I can start the "OmniBack II Manager", but can't do anything after due to this beautiful message:
"[12:1166] Velocis daemon error - the daemon is probably not running."

So I try a few things read on the forum's still hang.

C:\Program Files\OmniBack\bin>omnisv stop
Stopping OmniBack II services...
Cannot stop OmniBack II Database service, system error:
[1052] La commande demand??e n'est pas valide pour ce service.
Services stopped.
(in my poor english : [1052] command asked for is not valid for this service)
C:\Program Files\OmniBack\bin>omnisv start
Starting OmniBack II services...
Cannot start OmniBack II Database service, system error:
[1056] Un exemplaire du service s'ex??cute d??j??.
Services started.
(always in my poor english : [1056] service already running)
The "rds.exe" is still runing whatever I do...
So I try to kill it and do a "omnisv start" again, but still the same message in the "OmniBack II Manager":
[12:1166] Velocis daemon error - the daemon is probably not running.
If anybody had an idea...
Even if this idea imply the lost of the DB, it's not too important, but making the system back to full save functionality is vital !

Is there a simple command that allow to generate an empty database in order to have my backup system work???

thanks a lot !
Leif Halvarsson
Acclaimed Contributor.

Re: complete hang of the DB ? => velocis daemon error

Before you do anything with the OmniBack installation, try to restert the server. It is not sure this is a OmniBack error.

It is possible to recreate the database, but you will lose evrything.


omnidbinit - initializes the OmniBack II database

omnidbinit -version | -help

omnidbinit [ -force ]

The omnidbinit command initializes the OmniBack II database (OBDB).
All information about sessions, media and objects is lost after the
initialization. The command does not delete OBDB transaction logs. The
command creates a gap in the sequence of OBDB transaction logs; when a
roll forward operation is performed using the omnidbrestore command,
the operation applies only the transaction logs created before the
initialization of the OBDB.

The OBDB directory structure has to exist in order to initialize the
OBDB successfully. You can re-create the OBDB directory structure by
copying it from the /opt/omni/newconfig/ (HP-UX Cell Manager) or from
the /NewConfig/ (Windows Cell Manager) directory.

-version Displays the version of the omnidbinit command

-help Displays the usage synopsis for the omnidbinit command

-force Overrides the default safety check for the
initialization. By default, the command displays a
confirmation request. With this option, there is no
confirmation request.

The command can only be used locally on the Cell Manager.

omnidb(1M), omnidbcheck(1M), omnidbupgrade(1M), omnidbrestore(1M),

Hewlett-Packard Company - 1 - omniback II A.04.10: Nov. 2001

omnidbinit(1M) omnidbinit(1M)

omnidbutil(1M), omnidbxp(1M), omnidbva(1M)

The "last chance" is to reinstall OmniBack.
Jean-Luc Oudart
Honored Contributor.

Re: complete hang of the DB ? => velocis daemon error


last I got this , our OBII database was corrupted.

We decided to restore previous backup of the Omniback database.
Hope you have a recent copy of it.

Checking and Fixing OmniBackII Database (omnidb) corruption:

Here are your options for checking the OmniBackII database (omnidb):
1 - To find out the size of your database run
'/opt/omni/sbin/omnidbutil -extendinfo'.
2 - Run '/opt/omni/sbin/omnidbcheck' from command-line. If you
have a large database (>1GB), then this could take a while
(possibly a number of hours).
3 - If you want a quicker (less thorough) database check, you
can run '/opt/omni/sbin/omnidbcheck'. If this
doesn't return any errors, then you may need to run the
full check anyway.

Here are your options if the 'omnidbcheck' returns errors:
A - Run '/opt/omni/sbin/omnidbcheck -fix' from the command-line.
This rebuilds the index records, however, will probably not
fix the problem. This is a quick option that has a chance
of solving the problem.

B - Perform the 'writeascii-readascii' process (Chp. 9 of Admin
Guide). Again, depending on the size of your omnidb, this
could take awhile. If your omnidb is badly corrupted, this
may not be possible.

C - Restore your omnidb from backup. This option would require
the following steps:
1 - Copy your current omnidb into a different location and/or
back it up.
2 - Perform a writeascii of your 'mmdb' only so that you can
maintain your configuration of devices and media pools.
3 - Reinitializing the omnidb (/opt/omni/sbin/omnidbinit).
4 - Perform a readascii of your 'mmdb' only so that you can
maintain your configuration of devices and media pools.
5 - Run '/opt/omni/sbin/omnidbutil -cdbsynd ' to
syncronize the cdb and mmdb.
6 - Reimporting the catalog of your omnidb tape (see man page
for omnimm).
/opt/omni/sbin/omnimm -import_catalog
-slot -pool

7 - Restoring omnidb to a different location (see Chp. 9 of
Admin Guide).
8 - Bring down OBII, move omnidb into place, bring OBII back up.
9 - Run '/opt/omni/sbin/omnidbutil -set_session_counter 100'
from command-line. This will set the session counter so
that you will not have any duplicate sessions for any
backups that run afterwards. The next session will start
with a session ID of 100 (ex. 2000/07/31-100).
10 - Import the tapes of the backups that you have performed
since your last omnidb backup. If these tapes already
exist in the omnidb, then you can import just the catalog
information (see omnimm -import_catalog).

D - If you do not have a backup of your omnidb, then you have the
following options:
1 - Perform a writeascii-readascii with the 'no_detail' option.
This will clear all of the catalog information from your
database. Then you can import the catalog information from
all of the tapes that you are concerned about.
2 - Run a writeascii-readascii of your mmdb only. Syncronize
the omnidb (/opt/omni/sbin/omnidbutil -cdbsync ).
Set the session counter. Import the catalog information of
the tapes (see omnimm command).
3 - Run '/opt/omni/sbin/omnidbinit'. Create your devices and
media pools. Import your tapes.
fiat lux
Regular Contributor.

Re: complete hang of the DB ? => velocis daemon error

no "omni*" command can be execute...
Always the same error message.
So I finally reinstall OBII.

After that:
1) I stop OBII : omnisrv stop
2) I copy my old /db/mmdb directory in the new install directory.
3) I start OBII : omnisrv start
4) I launch the manager
Now, I see my old config (device&media) but no clients(no too important, I've got the list, so I simply "import" them without having to reinstall them.)
5) but always a problem : now that everything is quite OK, I really wanna try to recover my old DB.
Gracefully, I've got many copy of it on DATs (HP SureStore 6*DDS3) but don't have any idea on how to proceed...

Thanks for all guys !
You learn me good things :)))

PS : shall we not always have a copy of our DB directory on HD in order to prevent such disaster ?
Jean-Luc Oudart
Honored Contributor.

Re: complete hang of the DB ? => velocis daemon error

To restore the OBII database.
you want ot restore the latest copy.
I understand you have a working version of OBII but you're missing the information related to the last (or is it all) sessions.

- restore the database to a different location (as you currently need OBII to be up to do this)
- stop omniback
- move /copy the DB components to the right location
- restart OBII

This is explained in the online documentation (Omniback II database / Restoring the omniback II database)

Once you've done that you should have the sessions up to your last OBII database backup.
For subsequent backup sessions, check the log (media.log) for the medium names.
You can import them (this may take sometimes) otherwise be sure to protect the tapes so nobody will use them !

fiat lux