Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Netbackup unable to access /db/images for particular client

Created: 11 Dec 2012 | 6 comments

Hi All,

Master server : Solaris 10, client solaris 10, Nbu version 7.1

We have issue with one restore, where restoration is taking long time to start , in queued state for more than 3 days. i found one issue in bpdm logs

09:30:34.680 [22688] <2> list_files: /usr/openv/netbackup/db/images/<client> is empty. i went into that directory and found directory was actually not empty.

What could be the reason?

 

 

 

Comments 6 CommentsJump to latest comment

mph999's picture

When you run the restore, do you know the backup id of the images ...

Let us pretend, for an example it is this :

womble_1335467583

You need to look and see if this dir is empty:

/usr/openv/netbackup/db/images/<client>/ctime   (ctime is first 4 digits of ctime + six 0's )

So in my example, it would be

/usr/openv/netbackup/db/images/womble/1335000000

There should be two files:

<policy name>_<cime>_FULL (or INCR or UBAK)

<policy_name>_<ctime>.f

Do these exist ?  (hence why you need to know the ctime of the backup)

Martin

 

Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
Marianne's picture

Please show us output of:

ls -lR  /usr/openv/netbackup/db/images/<client>

We can provide better assistance if we see what you see...

Were you able to browse the images in BAR GUI? If so, it had to find files/folders in images folder.

Please post master server's bprd log as File attachment along with all text in Job details.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Amit Karia's picture

Here is output from

-rw-------   1 root     root       75521 Nov 28 11:39 LWK_NonProdLinux1_1354085332_INCR.f
-rw-r--r--   1 root     root        1274 Nov 28 11:39 LWK_NonProdLinux1_1354085332_INCR
-rw-------   1 root     root       76478 Nov 29 12:55 LWK_NonProdLinux1_1354171645_INCR.f
-rw-r--r--   1 root     root        1274 Nov 29 12:55 LWK_NonProdLinux1_1354171645_INCR
-rw-------   1 root     root      113010 Nov 30 11:43 LWK_NonProdLinux1_1354258173_INCR.f
-rw-r--r--   1 root     root        1275 Nov 30 11:43 LWK_NonProdLinux1_1354258173_INCR
-rw-------   1 root     root          72 Dec  3 02:13 LWK_NonProdLinux1_1354334829_FULL.f
drwx------   2 root     root        1024 Dec  3 02:13 catstore
-rw-r--r--   1 root     root        1436 Dec  3 02:13 LWK_NonProdLinux1_1354334829_FULL
-rw-------   1 root     root       90830 Dec  4 14:22 LWK_NonProdLinux1_1354609428_INCR.f
-rw-r--r--   1 root     root        1277 Dec  4 14:22 LWK_NonProdLinux1_1354609428_INCR
-rw-------   1 root     root       63085 Dec  5 02:08 LWK_NonProdLinux1_1354673320_INCR.f
-rw-r--r--   1 root     root        1268 Dec  5 02:08 LWK_NonProdLinux1_1354673320_INCR
-rw-------   1 root     root       70280 Dec  6 02:12 LWK_NonProdLinux1_1354759896_INCR.f
drwxr-xr-x   3 root     root        1024 Dec  6 02:12 tmp
-rw-r--r--   1 root     root        1271 Dec  6 02:12 LWK_NonProdLinux1_1354759896_INCR

image id :

lonlx10645-b_1354334829

 

Marianne's picture

We need to see in which context the line in the log appears. 
Lines like that is normal while still browsing (list_files).  
Note that it is a <2> - debug info, and not a Warning <8>, Error <16>, or Severe Error <32>.

The fact that you managed to start the restore means that the correct image entries in the catalog was found.

So, that entry should not be related to the queued state.

What reason was displayed in Job Details? Were all required resources available?

Do you have the bprd log for us to have a look at?
If so, please post all text in Details tab as well as bprd log as File attachment.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

thesanman's picture

Can your master server "ping" the client you are restoring to.  I have seen this where the restore get's queued but regardless of which media server is involved in performing the restore; the master server seems to need to be able to connect to the client you are restoring to.  Until it can; the restore just sits there and doesn't even get started.

NBU v7.5.0.6 Master and Media servers on RHEL 5/6 & Win2008; SAN based LTO3, 4 and 6 tape libraries
Linux, Solaris, Windows and OpenVMS clients.
PureDisk, SLP, VMware, HyperV, Oracle, Netezza, SQL/Server,

Yasuhisa Ishikawa's picture

Where db/images/<client_name> actually reside? On NFS?

Have you already cancel and retry restore after checking this directory? If not, please retry again and tell us the result.

Authorized Symantec Consultant(ASC) Data Protection in Tokyo, Japan