cancel
Showing results for 
Search instead for 
Did you mean: 

Backup completing successfully with skipping the files

Sagar_Kolhe
Level 6

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 ACCEPTED SOLUTION

Accepted Solutions

mph999
Level 6
Employee Accredited

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 6

mph999
Level 6
Employee Accredited

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

watsons
Level 6

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?

Sagar_Kolhe
Level 6

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

rookie11
Moderator
Moderator
   VIP   

check with unix SA do these file really exist

 

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

Marianne
Level 6
Partner    VIP    Accredited Certified

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.'

mph999
Level 6
Employee Accredited

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