08-22-2014 12:47 PM - edited 08-30-2017 09:13 AM
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.
08-22-2014 01:05 PM
Check DNS lookups. Sounds just like this older thread
https://www-secure.symantec.com/connect/forums/netbackup-status-code-48-db-backups-suddenly-failed
08-22-2014 01:47 PM
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
08-22-2014 01:48 PM
08-27-2014 11:41 AM - edited 08-30-2017 09:15 AM
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
08-28-2014 07:21 AM
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.