ADSM-L

Re: [ADSM-L] Expiration

2008-03-11 10:40:01
Subject: Re: [ADSM-L] Expiration
From: William Boyer <bjdboyer AT COMCAST DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 11 Mar 2008 10:38:02 -0400
Nothing that I'm aware of, but you could always run a couple select statements 
before and after the expiration process to list the
total occupancy of the stgpool(s) defined in your VTL:

Select sum(physical_mb) from occupancy where stgpool_name in 
('stgpool1','stgpool2',...)

The list of stgpool(s) that are defined to your VTL in UPPERCASE.

This should give you a before and after occupancy picture.

Bill Boyer
"Life is like riding a bicycle. To keep your balance you must keep moving" - ??
 


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Lepre, James
Sent: Tuesday, March 11, 2008 10:22 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Expiration

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>