LMS Backup Problem

Answered Question
Nov 13th, 2008

Can someone advise with the following. My LMS server is configured to back itself up to a local directory every morning at 3:30 AM. However recently the backup runs and according to the log file (attached) there doesn't seem to be any errors. However the backup reports as failed and the backup.lock file remains in place. The only way to remove this file is to stop the ciscoworks service delete the lock file and restart the service.

It then fails the next day with the same error?

I have this problem too.
0 votes
Correct Answer by Joe Clarke about 7 years 11 months ago

I see the problem. You originally typed "dfmlnv" (D-F-M-L-N-V). The command is dfmInv (D-F-M-I-N-V). The uppercase 'I' looks a lot like the lowercase 'l' with a sans serif font. Redo the command with dfmInv:

dbRestoreOrig.pl dsn=dfmInv dmprefix=INV

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Joe Clarke Thu, 11/13/2008 - 08:01

The one thing I notice is it appears the backup is being killed. Make sure you don't have a script on this system which is killing long-running processes.

The other thing I notice is that I don't see the dfmInv database being checked. This database may be corrupt which is causing the dbvalidate operation to hang. The solution for this would be to reinitialize this database:

NMSROOT\bin\perl.exe NMSROOT\bin\dbRestoreOrig.pl dsn=dfmInv dmprefix=INV

bgl-group Thu, 11/13/2008 - 09:16

attempting to run the command gives me the following reply

FATAL ERROR: D:\PROGRA~1\CSCOpx\databases\dfmlnv\orig\odbc.tmplorig does not exist, or is not readable.

Verify that the DSN exists, before contacting a Cisco support engineer.

The file does exist though and the contents are below....










# note __ values are not passed through for odbc registration

# These __ values are skipped by odbcdsn.pl.

# These __ values are used for configuring db engine startup parms.


__DbNTSvcLongName=DFM dfmInv database engine

There also appears to be an entry in the OBDC data sources for this - however I will admit to not being a database engineer.

Joe Clarke Thu, 11/13/2008 - 12:01

This error would only occur if the file didn't exist, or the parent directories were not accessible to the user running the command. As the same user that ran the dbRestoreOrig.pl command, please run the following command from a DOS prompt, and post the output:

DIR D:\PROGRA~1\CSCOpx\databases\dfmlnv\orig

bgl-group Fri, 11/14/2008 - 00:53

I have just double checked the file name I have on the server is dfmInv (Uppercase 'I') and not dfmlmv (lower case 'L'). So on the server I have a directory called delta foxtrot mike india november victor.

Is this folder missing then?

I have attached a screen print of the directory listing below.

Joe Clarke Fri, 11/14/2008 - 06:30

The datasource name is dfmInv, so your directory structure looks correct. However, the test for the file is fairly straightforward. I would still like to see the DIR output requested in my previous post.

bgl-group Mon, 11/17/2008 - 01:52

directory listing as requested

C:\Documents and Settings\Administrator>DIR D:\PROGRA~1\CSCOpx\databases\dfminv\orig

Volume in drive D is Data

Volume Serial Number is E413-8E02

Directory of D:\PROGRA~1\CSCOpx\databases\dfminv\orig

05/11/2008 10:21 .

05/11/2008 10:21 ..

27/11/2007 19:14 2,113,536 dfmInv.dborig

06/10/2008 16:41 506 odbc.tmpl

26/11/2007 10:53 467 odbc.tmplorig

3 File(s) 2,114,509 bytes

2 Dir(s) 117,760,270,336 bytes free

C:\Documents and Settings\Administrator>

Correct Answer
Joe Clarke Mon, 11/17/2008 - 09:44

I see the problem. You originally typed "dfmlnv" (D-F-M-L-N-V). The command is dfmInv (D-F-M-I-N-V). The uppercase 'I' looks a lot like the lowercase 'l' with a sans serif font. Redo the command with dfmInv:

dbRestoreOrig.pl dsn=dfmInv dmprefix=INV

bgl-group Tue, 11/18/2008 - 01:11

OK that command has run successfully and I have deleted the backup.lock file - I will post back tomorrow morning with the results of the backup process.


bgl-group Wed, 11/19/2008 - 02:03

The backup ran successfully. So all is well on that system now....




This Discussion