cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Netbackup unable to access /db/images for particular client

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?

 

 

 

6 Replies
Highlighted

When you run the restore, do

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

Highlighted

Please show us output of: ls

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.

Highlighted

Here is output

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

 

Highlighted

We need to see in which

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.

Highlighted

Can your master server "ping"

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.

Highlighted

Where db/images/<client_name>

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.