Hello All, Is there a SELECT Statement that would tell you how many files are expired and how much data this correlates to? For example if we expire 1,000,000 file that could be 500MB of actual data. The reason for this request is because we need to know how much data is actually coming off of our VTL from the expiration process.
Thank you in Advance James -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Hans Christian Riksheim Sent: Monday, March 10, 2008 6:46 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM has built-in encryption? A lot of people opt for the transparent encryption scheme where the key is held in the TSM database and it seems that IBM is moving in that direction with this feature being the only option in 5.5 for the BA-client. It seems that I am the only one who wants it the other way around. As I see it, client-key encryption offers far better security. OK, you must protect the key and store it on paper or other media on more than one secure location in case of DR but isn't that the whole game with crypto anyways? No key? Sorry, no data for you! Transparent encryption on the other hand is easier but security is poorer. I have thought on some security breach scenarios and compared the two schemes. Correct me if I am wrong on any of the technicalities. Tapping the lines between data center(customer) and backup site: The is the same for both client-key encryption and transparent encryption. A snooper will in both cases only get DES56/AES128 garble. Lost/stolen tape media: This depends. The data tapes alone are protected with both schemes. But if you also get hold of the DBbackup tapes(Hijack the truck with DR tapes) you can restore the TSM-server with the keys if you are using transparent encryption. With client-key encryption the data is safe from inspection because you do not have the keys. Backup site breakin: The data will be safe with client-key encryption. With transparent encryption the intruder will have full access to all data. Backup-LAN: Someone puts a client into your Backup-LAN or one client that is already there wants to snoop into another clients data. For example if backup is outsourced different customers/competitors are sharing the same TSM infrastructure. With transparent encryption you can access all the data on the TSM server IF you have an admin password for an account with system privilege. And a lot of admin passwords are not that secret. Many places admin password are not changed for different reasons. In some setups with config manager and library sharing it is seen as too cumbersome to change these passwords. Anyway, in this scenario transparent encryption offers no security. Client-key encryption does. Trusting the TSM administrator: I'm not saying that TSM administrators are an untrustworthy lot. But with client-key encryption you don't have to trust the TSM admin and it is a big difference. If I offer a TSM service, backup "through a hole in the wall" or what it is called, the customer can set the encryption key himself and even if I wanted to, would have no chance of retrieving his data and giving it away. The backup is as secure as the customers own standard for protecting the key. He does not have to rely on the supplier of the TSM service. I guess there are more examples and pros and cons but this sums it up for me: I want IBM to continue with client-key encryption for the BA client, offer the same option for TDPO(though there are other means to the end in Oracle10/11) and likewise for Exchange(where I'm not sure of which options exist in the application itself). Best regards Hans Chr. Riksheim ________________________________ Fra: ADSM: Dist Stor Manager på vegne av Wanda Prather Sendt: to 06.03.2008 17:03 Til: ADSM-L@VM.MARIST.EDU Emne: Re: TSM has built-in encryption? The TSM clients (including TDP's) can encrypt at AES 256. You take a hit on performance for both backup and restore; you need to also turn on compression on the client, as encrypted data can't be compressed by the tape drive. If you want to encrypt using the backup client, I STRONGLY recommend you upgrade to 5.5, where the TSM server manages the keys for you. Prior to that level, you have to maintain the keys manually; if you lose the keys and have to go to a DR site, you won't get your data back. At 5.5, the keys are generated randomly and maintained in the TSM data base. (The TDP's have the keys managed by the TSM data base starting at 5.3; for regular clients, that feature starts at 5.5). A better/cleaner method is encrypting outboard in the hardware. Look into upgrading your drives to LTO4; then (with an additional feature code on your 3584) you can do the encryption outboard, with no performance hit. TSM can still maintain the keys for you, if you want, or you can use an external key manager that IBM provides. Whether or not you can encrypt data that goes to your VTL outboard depends on your VTL vendor. On 3/6/08, Bell, Charles (Chip) <[EMAIL PROTECTED]> wrote: > > I am wondering what level of encryption TSM has as an application, if at > all. > > > > > We are running v5.4.2.0 on the server. > > We have a 3584 with LTO1 and LTO2, with copies of both going offsite to > Iron > Mountain. > > We have a VTL emulating 3592 for onsite use. > > > > God bless you!!! > > Chip Bell > Network Engineer I > IBM Tivoli Certified Deployment Professional > Baptist Health System > Birmingham, AL > > > > > > > ----------------------------------------- > Confidentiality Notice: > The information contained in this email message is privileged and > confidential information and intended only for the use of the > individual or entity named in the address. If you are not the > intended recipient, you are hereby notified that any dissemination, > distribution, or copying of this information is strictly > prohibited. If you received this information in error, please > notify the sender and delete this information from your computer > and retain no copies of any of this information. > <html><body><br /><br /><br /><font face="Arial" size="1"><hr>This email originates from Steria AS, Biskop Gunnerus' gate 14a, N-0051 OSLO, http://www.steria.no. This email and any attachments may contain confidential/intellectual property/copyright information and is only for the use of the addressee(s). You are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way if you are not the addressee(s) or responsible for delivery. If you receive this email by mistake, please advise the sender and cancel it immediately. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Any email is susceptible to alteration and its integrity cannot be assured. Steria shall not be liable if the message is altered, modified, falsified, or even edited.</font></body></html>