ADSM-L

Re: [ADSM-L] Turning Encryption Off/On

2010-01-13 09:46:16
Subject: Re: [ADSM-L] Turning Encryption Off/On
From: Wanda Prather <wanda.prather AT JASI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 13 Jan 2010 09:09:28 -0500
This is for TSM-managed encryption (the library is set to
application-managed).
You only need 1 set of scratch tapes.

One library, two storage pools, two devclasses, one encrypted, one not.
Same pool of scratch tapes.

When an encrypted tape goes scratch and comes back from the vault, it can be
reused non-encrypted.
(I think that is because the label isn't encrypted, just the data.)
TSM DB backups are never encrypted, either.

Works fine.  Beauty of TSM-managed encryption; easy peasy.  Set it and
forget it.






On Wed, Jan 13, 2010 at 6:06 AM, Stefan Folkerts <stefan.folkerts AT itaa DOT 
nl>wrote:

> I don't think you can have two devices classes (one with and one without
> encryption) sharing the same pool of scratch volumes (one logical library)
> using LTO hardware encryption.
> This is because the volume label on the tape is either written encrypted or
> it is not, I don't think the none encrypted deviceclass is able to write to
> a scratch tape labeled within an encrypted deviceclass configuration because
> the first thing it does is check the label, that's encrypted so label
> doesn't match eject -> set to private, next volume please...etc etc.
>
>
>
>
> -----Oorspronkelijk bericht-----
> Van: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Namens
> Druckenmiller, David
> Verzonden: dinsdag 12 januari 2010 18:07
> Aan: ADSM-L AT VM.MARIST DOT EDU
> Onderwerp: Re: [ADSM-L] Turning Encryption Off/On
>
> Using hardware encryption, managed by TSM.
>
> Are you saying I can have two device classes sharing the same devices?  For
> some reason, I was always under the impression that you couldn't.  But after
> scanning the help, I don't know where I came up with that notion.  That
> would definitely make things simple for me.
>
> Thanks.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Wanda Prather
> Sent: Tuesday, January 12, 2010 10:20 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Turning Encryption Off/On
>
> Is your encryption application-managed (controlled by TSM) or
> library-managed (controlled by EKM/TKLM)?
>
> If application managed, IBM is correct, you just need a different devclass
> that specifies drive encryption OFF, pointing to the same library, and a
> new
> storage pool that specifies the non-encrypted devclass.  .
>
> I've got 4 LTO drives, onsite pool is NOT encrypted (long story there),
> COPY
> pool IS encrypted.  No biggie.
>
> W
>
>
> On Tue, Jan 12, 2010 at 9:10 AM, Druckenmiller, David
> <DruckeD AT mail.amc DOT edu>wrote:
>
> > We currently encrypt all our offsite tapes.  Mgmt wants to me create a
> > single unencrypted archive tape to be stored offsite long term for
> > litigation reasons.
> >
> > My question is:  If I turn off encryption long enough to get some data
> > written to this one tape, then turn encryption back on, could I then
> > continue to write uncrypted data to this one tape while all other tapes
> > would be encrypted?
> >
> > IBM is being non-committal saying we should really use new device class,
> > but I'd then have to move one tape drive over to new class each time I
> want
> > to write unencrypted.
> >
> > TSM 5.5.3
> > AIX 6.1
> > Tapes are LTO4
> >
> > Thanks
> > Dave
> >
> > -----------------------------------------
> > CONFIDENTIALITY NOTICE: This email and any attachments may contain
> > confidential information that is protected by law and is for the
> > sole use of the individuals or entities to which it is addressed.
> > If you are not the intended recipient, please notify the sender by
> > replying to this email and destroying all copies of the
> > communication and attachments. Further use, disclosure, copying,
> > distribution of, or reliance upon the contents of this email and
> > attachments is strictly prohibited. To contact Albany Medical
> > Center, or for a copy of our privacy practices, please visit us on
> > the Internet at www.amc.edu.
> >
>

<Prev in Thread] Current Thread [Next in Thread>