Forum Discussion

keyz93's avatar
keyz93
Level 3
13 years ago

/netbackup/db/images/client/xxxxxx directories and .lck file

Hi,

do you know the role of .lck file and why it is modified on every directories in /netbackup/db/images/client/xxxxxxxxxx ?

Thanks in advance

 

 

 

  • As you might have already guessed, they are lock files.  :)  We need them to prevent NetBackup from trying to do two things to one object.  (What object, you ask?  I don't know for sure if it's directory or image or something else...and I didn't have enough time to investigate further)  The files are associated with some locking that takes place and USUALLY disappear when their related images (they share most of the same filename, you'll find) expire.  Sometimes they don't.  That's probably a defect.

    What I CAN tell you is that any "orphaned" lock files should eventually get cleaned up when their directories are aged out and get removed.  This happens when there are no more valid images in those directories.

    I can also (perhaps unreasonably) speculate that there are plans to move away from this kind of behaviour, but I have no idea by what version something like that might get accomplished as that's well above my pay grade.

    The bottom line is those .lck files are very crucial at the time they are created, and then later, much less important if they end up sticking around long after their associated images are gone. :)

6 Replies

  • to do with failed catalog backups:

    "STREAMS.lck files are to do with the NetBackup's stream discovery process - for multiple streams backups (and some other type of backups, too) NetBackup will initiate stream discovery process, and the lock file would be created.

    And if a backup session is terminated unexpectedly while the stream discovery process is running, the STREAMS.lck file might not be cleaned up properly and stay behiind."

    I'm assuming here that you are referring to this particular file or the STREAMSpolicy_name.lck files which I presume server the same function?

  • in fact the file is just named ".lck" with 0 Kb size.

    I can see it on each netbackup/db/images/client/xxxxxxx directories with the actual date/time

    The master is Windows 2003 Server, NBU 7.0.1

  • I was looking directly in the client folder (where not all clients have this .lck file & when they do they are years old - version thing?) & they also appear in client/ctime & client/ctime/tmp folders.

    What I have noticed is that those within the client/ctime folders have a modified time within the period of the last catalog backup - so some relation with the catalog process.

    Other than that little "insight" I have little to offer......

  • .... have just checked again & those timestamps are still updating yet my catalog finished an hour ago.

    ****EDIT****

    Maybe the catalog does affect these timestamps, but one thing for sure is that image cleanup does. I manually ran an image cleanup shortly after the catalog finished & I've just done so again - the timestamps definitely change as a result of the image cleanup running, maybe they do also change as a result of the catalog backup. We could go on checking & guessing for some time......

  • As you might have already guessed, they are lock files.  :)  We need them to prevent NetBackup from trying to do two things to one object.  (What object, you ask?  I don't know for sure if it's directory or image or something else...and I didn't have enough time to investigate further)  The files are associated with some locking that takes place and USUALLY disappear when their related images (they share most of the same filename, you'll find) expire.  Sometimes they don't.  That's probably a defect.

    What I CAN tell you is that any "orphaned" lock files should eventually get cleaned up when their directories are aged out and get removed.  This happens when there are no more valid images in those directories.

    I can also (perhaps unreasonably) speculate that there are plans to move away from this kind of behaviour, but I have no idea by what version something like that might get accomplished as that's well above my pay grade.

    The bottom line is those .lck files are very crucial at the time they are created, and then later, much less important if they end up sticking around long after their associated images are gone. :)