You can also try doing "Q CON <volume-name> DAM=Y" to see if TSM sees any
damaged files on that volume. It could be that the MOVE DATA managed to
read the data after all, and it's now on a different volume. In any case,
you have a suspect volume.

More concerning, though, is the state of your copy pool. Without your copy
pools, you're vulnerable to losing all data in your primary pools.

On Mon, Dec 16, 2013 at 05:30:09AM -0800, mik wrote:
> Skylar Thompson
>
> The MOVE DATA encountered a problem with either the tape, or the drive
> itself. A couple things to try:
>
> * Try marking DRIVE2 as offline (UPD DR <library> DRIVE2 ONL=N), and
> then running the MOVE DATA again. This will force the operation to use a
> different drive. If you get the same problem, then it points to a
> problem with the tape, not the drive.
>
> --> The drive 1 are already down.
>
> * Try running an audit on the tape (AUDIT VOL A00015L3 F=Y) and watch
> the activity log for problems
>
> --> I try no error during this (maybe after that move data that should be 
> different
>
> * If you do have a bad tape, you can use your copy pool to restore it
> with RESTORE VOLUME.
>
> --> 1 drive down and copypool down too
>
> You might also check the logs on your library; some of them will give an
> indication of whether the problem is media- or drive-related.
>
> --> Just basic information no precision or else.
>
> For Richard B same response
>
> Thanks for the reply.
>
> Regards, Mickael.
>
> +----------------------------------------------------------------------
> |This was sent by bobpatrick808182 AT yahoo DOT fr via Backup Central.
> |Forward SPAM to abuse AT backupcentral DOT com.
> +----------------------------------------------------------------------

--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine