cancel
Showing results for 
Search instead for 
Did you mean: 

Backup completing successfully with skipping the files

Hi All,

 

I am facing serious issue @ our environment. We have upgraded the NBU to 7.5.0.4. After that , if any backup skip any file it will not show partially successful. Is there any solution for these ?

What needs to be done to avoid this.

08/22/2013 01:00:17 - begin writing
08/22/2013 06:36:03 - Info bpbrm (pid=19708) from client xyz: TRV - Cannot process path /home/eguard/enstage/accosa/quickcached1/log: No such file or directory. Skipping.
08/22/2013 06:36:03 - Info bpbrm (pid=19708) from client xyz: TRV - Cannot process path /home/eguard/enstage/accosa/quickcached2/log: No such file or directory. Skipping.
08/22/2013 06:36:03 - Info bpbrm (pid=19708) from client xyz: TRV - Cannot process path /home/eguard/enstage/soft/jboss-4.2.3.GA/bin/F:/accosa/EA_Log: No such file or directory. Skipping.
08/22/2013 06:36:07 - Info bpbrm (pid=17956) media manager for backup id xyz_1377113412 exited with status 0: the requested operation was successfully completed
08/22/2013 06:36:07 - end writing; write time: 5:35:50
the requested operation was successfully completed  (0)

Master Server : Solaris 10

NBU version : 7.5.0.4

xyz Client OS : HP-UX-IA64, HP-UX11.23

xyz NBU version : 6.5.4
 

 

Regds,

Sagar

 

 

1 Solution

Accepted Solutions
Accepted Solution!

This can be argued both ways.

This can be argued both ways.  I happen to know it has recently been rasied in a case.  

NBU is not a file management system, if the file is not there, it is not for NBU to alert.  Therefore this has not been considered as a bug and there is no current fix.

If a path could not be found by bpbkar, it does not affect the status of the backup – it will complete with status 0 (unless none of the paths were found, which causes status 71). 

The reason is because in some operational environments, some paths may not be available on a client all of the time in normal operation, and customers do not want the backup to fail for a temporary missing path. This is the same idea as ALL_LOCAL_DRIVES – bpbkar backups all of the paths it can find on the client. It is the responsibility of the customer/user to make sure that all of the data that they want to backup are accessible on the client at backup time. 

However, it can be understood that some customers will want this.

Therefore, this has been raised with product management as an enhancement request, meaning it will be considered as a change.

Martin

View solution in original post

6 Replies
Accepted Solution!

This can be argued both ways.

This can be argued both ways.  I happen to know it has recently been rasied in a case.  

NBU is not a file management system, if the file is not there, it is not for NBU to alert.  Therefore this has not been considered as a bug and there is no current fix.

If a path could not be found by bpbkar, it does not affect the status of the backup – it will complete with status 0 (unless none of the paths were found, which causes status 71). 

The reason is because in some operational environments, some paths may not be available on a client all of the time in normal operation, and customers do not want the backup to fail for a temporary missing path. This is the same idea as ALL_LOCAL_DRIVES – bpbkar backups all of the paths it can find on the client. It is the responsibility of the customer/user to make sure that all of the data that they want to backup are accessible on the client at backup time. 

However, it can be understood that some customers will want this.

Therefore, this has been raised with product management as an enhancement request, meaning it will be considered as a change.

Martin

View solution in original post

Sagar, your NBU client is

Sagar, your NBU client is 6.5.4, does it mean before you upgrade the master server it was able to backup those files perfectly?

No , but backup was

No , but backup was completing with status 1(partially completed).Now backup has completing with status 0.

check with unix SA do these

check with unix SA do these file really exist

 

/home/eguard/enstage/soft/jboss-4.2.3.GA/bin/F:/accosa/EA_Log

I totally agree with Sagar -

I totally agree with Sagar - I would want to see a status 1 for this backup.

I have recently logged a call with Symantec for a similar issue and also worked with Product Management (through our local Symantec office) to request enhancement.

It seems that Symantec engineers cannot make up their minds whether the above errors must be interpreted as TRV (trivial) or as an error and behaviour is seen to change between versions.

The answer to my Support call was: 'The product is behaving as intended.'

A good idea would be to have

A good idea would be to have an on/ off option for the alerts, that way tose who want them can turn it on, and those who don;t can turn it off ...

M