Disaster recovery management: Restore it from outside volumes from copy stgpool
Por favor, responda a "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Enviado por: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Destinatarios: [EMAIL PROTECTED] 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
