Hi James! Your explanation is absolutely valid. I only think that it is not very logical. Let's say I have my database backed up at 11:00 AM. At 16:00 I delete volume TAPE001 for whatever reason (in my case it was a corrupted virtual volume, yes it happens sometimes). On the next day disaster strikes at 04:00 AM and I have to restore the database of the previous day 11:00 AM. Now I have volume TAPE001 back as private again. If TSM tries to read it, it will definitely result in I/O errors since the data it expects on the tape will not be there... Kind regards, Eric van Loon Air France/KLM Storage Engineering
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of James Thorne Sent: maandag 27 maart 2017 13:55 To: ADSM-L@VM.MARIST.EDU Subject: Re: delete volume Hi Eric. Our experience with physical tapes checked in as scratch in a shared library environment is that if you delete the volume (with or without DISCARDDATA=yes) on the library client, the volume immediately goes to scratch on the library manager and is available for reuse. This seems similar to the behaviour you are seeing. We generally only manually delete volumes which have had errors and we have to check out the volume on the library manager *before* we delete the volume on the client, otherwise we have a bad tape entering scratch that could be reused before we check it out. Reusedelay specifies the number of days before a volume can be reused after all files are deleted from a volume, not after a *volume* is deleted. A volume becomes pending when all files are gone from it and is deleted from a storage pool after reusedelay days. When deleted the library volume then becomes scratch if it was scratch before or empty (and remains in the storage pool) if it was a private volume. DELETE VOLUME deletes the volume so there is no volume that can have a status of pending and hence cannot be controlled by reusedelay. By using DELETE VOLUME on a scratch volume, you are asking TSM to bypass reusedelay. From the manual: "The DELETE VOLUME command automatically updates the server library inventory for sequential volumes if the volume is returned to scratch status when the volume becomes empty. To determine whether a volume will be returned to scratch status, issue the QUERY VOLUME command and look at the output. If the value for the attribute "Scratch Volume?" is "Yes," then the server library inventory is automatically updated." Which suggests that any volume that was taken from scratch will return to scratch when you delete it. James Thorne, IT Services, University of Oxford -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Loon, Eric van (ITOPT3) - KLM Sent: 24 March 2017 13:58 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] delete volume Hi Neil! Roger stated that he is pretty sure that when he deletes a volume on physical tape, the volume becomes pending. In my case it's turning into scratch immediately and thus being relabeled immediately. I don't understand why it should work differently... Kind regards, Eric van Loon Air France/KLM Storage Engineering -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Schofield, Neil (Storage & Middleware, Backup & Restore) Sent: vrijdag 24 maart 2017 13:53 To: ADSM-L@VM.MARIST.EDU Subject: Re: delete volume Classification: Public Eric My experience of DELETE VOLUME going back to ADSM 3.1 is that it will immediately make the library volume (physical or virtual) scratch with no pending reuse delay. By typing the words DISCARDDATA=YES, I guess you are explicitly consenting to never being able to access the data again. You might have a way back if by chance a physical tape hasn't been re-used by the time you realise your mistake, but with virtual tape the data erasure is immediate when the volume is relabelled. I suppose my advice would be to only use DISCARDDATA=YES in the event that all remaining data on the volume has already proven (through MOVE DATA operations, or whatever) to be unreadable, and you don't have the option to recover it from a copy pool. In this case, a pending reuse delay wouldn't help make the data any more readable. I realise this doesn't address your concerns around accidental deletion of a volume, but I believe there's a saying about great responsibility accompanying great power. Regards Neil Schofield IBM Spectrum Protect SME Backup & Recovery | Storage & Middleware | Central Infrastructure Services | Infrastructure & Service Delivery | Group IT LLOYDS BANKING GROUP ________________________________ Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. Telephone: 0345 603 1637 Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Cheltenham & Gloucester plc is authorised and regulated by the Financial Conduct Authority. Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings is a division of Lloyds Bank plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ********************************************************
