</C/ProgramÀ Files/Veritas/NetBackup/Logs/user_ops/dbext/logs/

[Dollypee]

Master server : WIN2k3 64bit R2

Client : WIN2k8 64bitR2

Will like to know why my SQL backup sometimes go out of its regular backup schedules and appear in a NONE schedule.

Also failing with error code 48 "client hostname could not be found" while in the schedule.

No changes were made to the backup script as well as the environment. Please advice.

Activity monitor error:

8/22/2014 2:47:55 PM - Error bprd(pid=8360) Unable to write progress log </C/ProgramÀ Files/Veritas/NetBackup/Logs/user_ops/dbext/logs/12248.0.1408733275> on client raven123.. Policy=SQL_raven1234_TRNXLOG Sched=NONE 
8/22/2014 2:47:55 PM - Error bprd(pid=8360) CLIENT raven123 POLICY raven1234_TRNXLOG  SCHED NONE  EXIT STATUS 48 (client hostname could not be found)

Please aalso see attached.

[Will_Restore]

Check DNS lookups.  Sounds just like this older thread

https://www-secure.symantec.com/connect/forums/netbackup-status-code-48-db-backups-suddenly-failed

[sri_vani]

1)Yes please verify DNS...

2)Make sure that the folders available in both the Master and Client
Once dns issues fixed andthis directory has been created, run the database backup again.

http://www.symantec.com/business/support/index?page=content&id=TECH37192

3)The recommendation is to make the /usr/openv/netbackup/logs (UNIX/Linux) and <install>\NetBackup\logs (Windows) subdirectories readable and writeable by all users.

http://www.symantec.com/business/support/index?page=content&id=TECH52446

[Dollypee]

Thank you will. Am monitoring this closely and if it occurs again, will need to check with the dns team. I'll keep you posted. Thanks

[Dollypee]

Backup still appears to be failing and seems to be complaining of virtual or physical memory. The box currently have 64Gb memory running idle on it. Please advice

[Will_Restore]

Look to the Windows Event Viewer on the SQL server.  Lots of possibilites like this

http://www.symantec.com/business/support/index?page=content&id=TECH42958

Resolution:
The backups were being initiated via Microsoft Terminal Server, and then the terminal server session was exited. This caused the backup processes to stop, and the backup to fail. Do not launch SQL operations through Terminal Server sessions, or via other remote management software. Initiate backups either from the master server or directly at the SQL console, and launch all restore operations directly from the SQL console.