Disaster recovery management: Restore it from outside volumes from copy
stgpool


Por favor, responda a "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Enviado por:    "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Destinatarios:        ADSM-L AT VM.MARIST DOT EDU
CC:
Asunto:        Re: Saving data on a defective cartridge


>I just found a way to partially recover data on a defective 3590
cartridge.
>Move data and audit volume aborted when processing a specific file.
>Unfortunately, this was very near to the beginning of the tape. So I was
>afraid to lose about 10 GB of data.
>
>I started del vol discard=yes. Then I got a new idea. The discard is a
>background process which can be cancelled. I cancelled it and ran audit
>volume. Everything was fine because the offendig file was deleted!
>
>Unfortunately, 17000 files and 1.7 GB are lost because the idea came too
>late. I should have cancelled the process much earlier. In case you have
the
>same problem I hope you will remember this mail and cancel the discard
>process earlier.
>
>Or is there an even better method?

Our employers have made us trustees of our company's data.  It is our
responsibility to safeguard the data in the TSM storage pools, as it may
be the
only surviving copy of the data, and may have to be called back.  That is
what
the TSM product is all about.  Tape being "tape" (open to the environment
and
its surface exposed to mechanical forces) it is essential to employ Backup
Stgpool as soon as possible after the client has sent data to the server,
giving
us that second copy, and by virtual of temporal adjacency, allowing us to
alert
the client to re-send any data wherein the Backup Stgpool cannot read the
just-written primary tape.  If at some later time the primary tape cannot
be
read, the second copy is my assurance.  (And there may be a third, offsite
copy.)

My odd view is that I have no right to casually destroy data which does
not
belong to me, and therefore I take architectural steps to safeguard it.

Richard Sims, BU