前面在做的一个恢复动作，因为它需要很多磁带，而我们又得不停的去异地取磁带，当时没时间去取磁带
于是我将TSM的request取消掉了，今天他们在做reclaim的时候就报了如下的错误
ANR1171W Unable to move files associated with node
KABMNT1, filespace \\kabmnt1\f$ fsId 1 on volume 000871
due to restore in progress. (PROCESS: 304)
ANR1089E Space reclamation is ended for volume 000871.
There is a lock conflict. (PROCESS: 304)
所以没有办法对这几盘磁带做reclaim
于是网上google了一下，同样有人遇到这样的问题，并且解决了这个问题，通过他的办法我也可以解决这个问题了，这里留在这里作为记录：
The ANR1171W incident means that during movement of data (this can be
migration, reclamation or a move data) for a sequential volume, files
were encountered that were locked by a restore operation. The following
command is part of our housekeeping; "reclaim stg backuptape
threshold=70 duration=600". All 3 volumes listed in the q ac are part
of this storagepool.
After a q restore on the TSM server the restartable restore showed up.
We can't just cancel this session with cancel restore, so up to the
administrator of this node.
After contacting the already mentioned administrator of this Unix
system, we performed a dsmc q restore on the client and this also
showed that there was 1 restartable restore. The restore, he assured
us, was no longer needed.
We've cancelled this session and after that the next scheduled backup completed successfully.
Thus, we can learn that a pending restore indeed keeps some sort of
lock on the filespaces on tape. Of course this is the same as a h 1171
will reveal, but sometimes it's nice to see that this info is correct.
我做的动作是在TSM Server上面
>cancel restore session_number
>q restore
OK，然后再进行reclaim
阅读(1399) | 评论(0) | 转发(0) |
