Veritas 备份出错 status code : 96
通过 “Activity Monitor” 发现在AIX中对Lotus Notes实现文件级备份过程出现错误，状态代码(Status Code)为96。
备份描述：
|
Media Server |
Policy |
Pools |
Backup Type |
Start/End Time |
Target |
|
|
Sybzx_app |
OAappFull |
OA_mailFS_appFS |
在线全备 |
FS |
09:30-11:00 week7 |
/app/notesdata |
|
Sybzx_app |
OAappIncr |
OA_mailFS_appFS |
在线增量 |
FS |
03:00-04:00 week1/5 |
/app/notesdata |
|
Media Server |
Policy |
Pools |
Backup Type |
Start/End Time |
Target |
|
|
Sybzx_mail |
OAmailFull |
OA_mailFS_appFS |
在线全备 |
FS |
09:30-11:00 week 7 |
/mail/notesdata |
|
Sybzx_mail |
OAmailIncr |
OA_mailFS_appFS |
在线增量 |
FS |
03:00-04:00 week 1/5 |
/mail/notesdata |
故障描述：
Activity Monitor.jpg
JobDetails_jobOverview.jpg
JobDetails_DetailedStatus.jpg
首先执行”available_media”检查对应volume pools中的磁带状态，具体执行输出为：
HP-UX hostname B.11.11 U 9000/800 (ta)
login: Password: Please wait...checking for disk quotas (c)Copyright 1983-2000 Hewlett-Packard Co., All Rights Reserved. (c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the
…… RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS 252.227-7013. # cd /usr/openv/netbackup/bin/goodies
# available_media
media media robot robot robot side/ ret size status ID type type # slot face level KBytes
----------------------------------------------------------------------------
DataStore pool
NetBackup pool
U U
None pool
OA_mailFS_appFS pool
U U U U U
·介质U
Symantec 官方800(bj) 一位姓”张”的工程师解释到，该错误代码表示为容器中没有可用的设备…仅此而已！事实上通过”job details”已经明确指明”不能分配新的介质，存储单元不可用”。且该工程师阐述，针对一个” volume pools”当其中某介质存在”Full”状态时，且数据在”Schedule”中定义的”Retention”尚未到期，则程序将对”Policies”中为对应的作业分配”状态”为空的介质（注意：不是存在剩余空间的介质，而是一个空间未被利用的介质。）当然上述情况发生前，一旦数据在”Schedule”中定义的”Retention”已经过期，则该介质将被释放，并被循环使用。
解决办法：扩展volime pools，为” OA_mailFS_appFS”增加新的介质。
与该工程师提及Basis之间的讨论”由于多个Policies共同应用一个volime pools，当两个policies共同占用一个介质时会发生抢占介质资源的情况，定论为抢占介质资源冲突而导致该错误”。该论证结果被官方认同。
解决办法：调整产生冲突的Policies中的Schedule内部作业计划时间，将产生冲突的Policies作业计划时间撮开。
通过Activity Monitor.jpg分析，首先考虑800的推断，如果这样的话，为什么又会出现下述情况：
19日 app增量执行报错 mail增量执行完成
20日 app全备执行完成 mail全备执行报错
故此，将定论转移为Basis论点…假设为可用介质发生抢占资源冲突…
但通过此后的日志分析，这个假设是不成立的：
22日 app增量执行报错 mail增量执行报错
23日 app全备执行报错 mail全备执行报错
通过华胜工程师确认，该软件设计对于介质抢占资源冲突是考虑过的！当若干policies应用同一介质并先后在很短的时间内同时出发作业…那么首先被执行的policies将被顺利执行，此后出发的策略作业将进入队列，等待介质空闲后执行
应用Reports将MediaServer 中sybzx_app和sybzx_mail的相关日志数据Run出，并进一步进行排查分析，其结果：
Reports>>Image on media >>Client:sybzx_app
Reports_ImgOnMeida_sybzxapp1.JPG
