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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Hans Christian Riksheim
Sent: Monday, March 10, 2008 6:46 PM
To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT 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) <Chip.Bell AT bhsala DOT com> 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>
|
