Career Opportunity?

[snoopnbu]

If there is any interest in a career opportunity in southeastern Wisconsin 
doing some bleeding edge backup technologies or helping to mature some products 
already brought in, please let me know!

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--

AW: [ADSM-L] 3592 Drive Encryption

[Herrmann, Boris]

Neil,

thanks for your detailed information. I've checked with IBM support. 
Unfortunately our 3592-E05 Drives are not encryption capable. IBM support told 
me that we can purchase a feature code (with the result, that all our drives 
would be replaced with new one), but our management didn't want pay anything. 

They asked me, if there would be any other way to encrypt the data without any 
cost. I don't know any way except the TSM client encryption (but I think it's 
not pratically to encrypt every data on the client systems, or is it?). We make 
normal backups and archives, a lot of db2 api backups, TDP (Exchange, Domino, 
MSSQL) and Oracle RMAN backups. Every day we backup up about 3-5 TB.

Does anyone have any other practical implementation of encrypting Volumes 
without hardware drive encryption? 

With kind regards,
__
 
Boris Herrmann
Produktion / Heterogene Systeme 
 
ARAG IT GmbH
ARAG Platz 1, 40472 Düsseldorf
 
Tel:  +49 (0)211 964-1137
Fax: +49 (0)211 964-1155
[EMAIL PROTECTED]
www.ARAG.de
 
 
Geschäftsführer:  Ottmar Liebler, Hanno Petersen 
Sitz und Registergericht:  Düsseldorf,  HRB 10934
USt-ID-Nr.:  DE 119 356 473
 


-Ursprüngliche Nachricht-
Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von Strand, 
Neil B.
Gesendet: Montag, 7. Januar 2008 17:03
An: ADSM-L@VM.MARIST.EDU
Betreff: Re: [ADSM-L] 3592 Drive Encryption


Boris,
   Verify that the library and drives are capable - may need a firmware upgrade 
or feature code - check with IBM.  You will also want to ensure you have the 
latest Atape driver installed.

   A logical library is either encryption capable or not - the drives in a 
logical library cannot be mixed.  If you implement library managed encryption, 
you have a great deal of flexibility over which volumes get encrypted and with 
which encryption keys they are encrypted with.

   I strongly encourage you to set up at least two, redundant Encryption Key 
Managers (EKM) because if a drive is unable to get a key, you get no volume to 
read from or write to and things can grind to a halt quickly.
   There are several IBM references including a Redbook on setting up the EKM.

   You may consider first creating a logical library with one or two drives and 
then testing various configurations with a small number of volumes and data 
that can be lost if you mess up.  If you lose the encryption key, you lose the 
data that was saved with it - you have been warned, no key, no data.

   I encrypt everyting that goes on tape (primary and copy pools) on the 
assumption that tape is easily transportable.  If a tape is ejected from the 
library (for any reason), all of the data is still protected by encryption.  
There is negligible performance impact with encryption on these drives.

   Plan on at least a 4 -6 week implementation and make sure you test and 
document your key and data recovery procedures and key changing procedures.

   I choose to implement library managed rather than application managed 
because it offered flexibility to have the encryption component managed by our 
security team without having them learn TSM.  It also allows encryption of 
media outside of TSM so if we need to ship a tarfile on tape, it can be done 
securely with a minimum of fuss.  Library managed also allows you to specify 
which tapes get encrypted - a volser range or a single tape to be encrypted 
with a specific encryption key (that key could be shared with a business 
partner).


Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Herrmann, 
Boris
Sent: Monday, January 07, 2008 10:10 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] 3592 Drive Encryption

Hello TSM'ers,

I've a question regarding Drive Encryption. We have a TSM Server v5.4.1.2 (on 
AIX 5.3.0.0) with a 3584 Tape Library and 3592-E05 Drives. We share this 
Library with our mainframe colleagues (one logical Library for mainframe and 
one logical Library for our TSM environment). Now our management wishes to 
encrypt our COPYSTORAGE-Pool volumes.

My questions:
Have anyone any experience with that issue and can give us some hints and tips 
how to implement the Drive Encryption. Need we additional Feature Codes for the 
Drives? Can we enable Drive Encryption only for our Logical Library without 
interfere our mainframe colleagues?


With kind regards,

Boris Herrmann

Produktion / Heterogene Systeme



ARAG IT GmbH

ARAG Platz 1, 40472 Düsseldorf



Tel:  +49 (0)211 964-1137

Fax: +49 (0)211 964-1155

[EMAIL PROTECTED]

www.ARAG.de 





Geschäftsführer:  Ottmar Liebler, Hanno Petersen

Sitz und Registergericht:  Düsseldorf,  HRB 10934

USt-ID-Nr.:  DE 119 356 473





IMPORTANT:  E-mail sent through the Internet is not secure. Legg Mason 
therefor

Upgrading Domino TDP

[Zoltan Forray/AC/VCU]

We are starting to experience constant issues with the Domino TDP
(Solaris) and trying to run the webclient to perform restores (API plugin
failures). The failures are helter-skelter with no pattern.

Before I call IBM, I figured I would upgrade the clients (base and TDP) to
the latest, since that is usually the first question level-1 will ask you.

So, is there a recommended/suggested/order of upgrade?  Should I upgrade
the base client (currently 5.3.0.4 - going to 5.5.0.1) first and then the
TDP (5.3.0.2 to  5.4.2.1) ?

Has anyone done such an upgrade?  Any gotchas ?

Re: LTO1/LTO2 to LTO4 migration?

[William Boyer]

Just define up your new tape drives/devc/stgpools and then set the NEXTPOOL= on 
your LTO1/LTO2 stgpool(s) to the new LTO3 or LTO4
stgpools. Now just MIGRATE STGPOOL the LTO1/2 over to the LTO4 pool. No need to 
do individual MOVE DATA/NODEDATA. Just let migration
handle it all for you. Cancel it and restart it as you need.

Bill Boyer
"I haven't lost my mind...it's backed up on tape somewhere!" - ??


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Bell, 
Charles (Chip)
Sent: Wednesday, January 09, 2008 10:16 AM
To: ADSM-L@VM.MARIST.EDU
Subject: LTO1/LTO2 to LTO4 migration?

Is it possible to run 'move data' or 'move nodedata' commands from either
LTO1 or LTO2 device class to LTO4? What about from LTO1/2 to LTO3? Has anyone 
done this?



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.

LTO1/LTO2 to LTO4 migration?

[Bell, Charles (Chip)]

Is it possible to run 'move data' or 'move nodedata' commands from either
LTO1 or LTO2 device class to LTO4? What about from LTO1/2 to LTO3? Has anyone
done this?

 

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.

"Freezing" my Email backups and starting fresh

[Bell, Charles (Chip)]

I just had a request from my boss via our legal dept. to freeze our email
backups, but of course we want to continue our backups nightly going forward.
What is the easiest way to do that? Our Exchange backups our managed through
a domain called EXCHANGE, go straight to VTL, and are sent offsite on LTO2.
Thanks in advance!

 

God bless you!!! 

Chip Bell 
Network Engineer I
IBM Tivoli Certified Deployment Professional (ITSM 5.2)
Baptist Health System 
Birmingham, AL 
Office (205) 715-5106 
Pager (205) 817-0357 
Home (256) 739-0947
Cell (256) 347-7294

 




-
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.

Re: LTO1/LTO2 to LTO4 migration?

[Stapleton, Mark]

From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
> That sounds great! So to confirm, there are no technical gotchas that
are
> going to prevent data movement from one media type (LTO1/2) ton
another
> (LTO3/4)? Anyone else done this?

Well, yes there is.

An LTO4 tape drive will NOT be able to read any data from an LTO1 tape
cartridge.

The LTO specifications call for any LTO cartridge to be readable and
writeable for a drive one level up (LTO1 to LTO2, for instance), and for
any LTO cartridge to be readable ONLY for a drive two levels up (LTO1 to
LTO3, for instance.
 
--
Mark Stapleton
Berbee (a CDW company)
System engineer
7145 Boone Avenue North, Suite 140
Brooklyn Park MN 55428-1511
763-592-5963
www.berbee.com
 

Re: AW: [ADSM-L] 3592 Drive Encryption

[Strand, Neil B.]

I would ask your management how much a single lost tape with unencrypted data 
would cost.
- Public exposure
- Customer confidence
- Government/legal investigation
- Competitor acquiring your proprietary information

Encryption on tape drive provides a highly scalable, near zero impact, 
manageable, secure solution to protect your assets and your customer's privacy. 

If you have a mix of encrypted and unencrypted data being saved from each 
client, what kind of management problems would that introduce to your 
environment? How much effort would it take to prove that a particular file was 
encrypted when it was backed up?  With the encryption on drive solution and all 
media encrypted, I can show on which tape(s) the data resides and then show the 
line in the audit log produced by the encryption key manager showing that the 
tape drive with that volume was successfully sent the encryption key.

Your IBM vendor should be able to work with you to provide an upgrade path or 
trade in value for your old drives.

Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Herrmann, 
Boris
Sent: Wednesday, January 09, 2008 9:39 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] AW: [ADSM-L] 3592 Drive Encryption

Neil,

thanks for your detailed information. I've checked with IBM support. 
Unfortunately our 3592-E05 Drives are not encryption capable. IBM support told 
me that we can purchase a feature code (with the result, that all our drives 
would be replaced with new one), but our management didn't want pay anything.

They asked me, if there would be any other way to encrypt the data without any 
cost. I don't know any way except the TSM client encryption (but I think it's 
not pratically to encrypt every data on the client systems, or is it?). We make 
normal backups and archives, a lot of db2 api backups, TDP (Exchange, Domino, 
MSSQL) and Oracle RMAN backups. Every day we backup up about 3-5 TB.

Does anyone have any other practical implementation of encrypting Volumes 
without hardware drive encryption?

With kind regards,
__

Boris Herrmann
Produktion / Heterogene Systeme

ARAG IT GmbH
ARAG Platz 1, 40472 Düsseldorf

Tel:  +49 (0)211 964-1137
Fax: +49 (0)211 964-1155
[EMAIL PROTECTED]
www.ARAG.de


Geschäftsführer:  Ottmar Liebler, Hanno Petersen Sitz und Registergericht:  
Düsseldorf,  HRB 10934
USt-ID-Nr.:  DE 119 356 473



-Ursprüngliche Nachricht-
Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von Strand, 
Neil B.
Gesendet: Montag, 7. Januar 2008 17:03
An: ADSM-L@VM.MARIST.EDU
Betreff: Re: [ADSM-L] 3592 Drive Encryption


Boris,
   Verify that the library and drives are capable - may need a firmware upgrade 
or feature code - check with IBM.  You will also want to ensure you have the 
latest Atape driver installed.

   A logical library is either encryption capable or not - the drives in a 
logical library cannot be mixed.  If you implement library managed encryption, 
you have a great deal of flexibility over which volumes get encrypted and with 
which encryption keys they are encrypted with.

   I strongly encourage you to set up at least two, redundant Encryption Key 
Managers (EKM) because if a drive is unable to get a key, you get no volume to 
read from or write to and things can grind to a halt quickly.
   There are several IBM references including a Redbook on setting up the EKM.

   You may consider first creating a logical library with one or two drives and 
then testing various configurations with a small number of volumes and data 
that can be lost if you mess up.  If you lose the encryption key, you lose the 
data that was saved with it - you have been warned, no key, no data.

   I encrypt everyting that goes on tape (primary and copy pools) on the 
assumption that tape is easily transportable.  If a tape is ejected from the 
library (for any reason), all of the data is still protected by encryption.  
There is negligible performance impact with encryption on these drives.

   Plan on at least a 4 -6 week implementation and make sure you test and 
document your key and data recovery procedures and key changing procedures.

   I choose to implement library managed rather than application managed 
because it offered flexibility to have the encryption component managed by our 
security team without having them learn TSM.  It also allows encryption of 
media outside of TSM so if we need to ship a tarfile on tape, it can be done 
securely with a minimum of fuss.  Library managed also allows you to specify 
which tapes get encrypted - a volser range or a single tape to be encrypted 
with a specific encryption key (that key could be shared with a business 
partner).


Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.

Re: LTO1/LTO2 to LTO4 migration?

[David Longo]

That's correct, one of the real nice things about TSM.

This is basically the same as migrating from any kind of
disk pool to any kind of tape pool, doesn't matter the
media type/technology.

You do need to remember though that after you have
migrated ALL of your onsite tape pool and it's offsite copies
have been made, then you need to "delete volume" with
discarddata option on the OLD offsite pool tapes, or else
old tapes will still be there.

DL

>>> "Bell, Charles (Chip)" <[EMAIL PROTECTED]> 1/9/2008 10:28 AM >>>
That sounds great! So to confirm, there are no technical gotchas that are
going to prevent data movement from one media type (LTO1/2) ton another
(LTO3/4)? Anyone else done this?

Thanks, Bill!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
William Boyer
Sent: Wednesday, January 09, 2008 9:25 AM
To: ADSM-L@VM.MARIST.EDU 
Subject: Re: [ADSM-L] LTO1/LTO2 to LTO4 migration?

Just define up your new tape drives/devc/stgpools and then set the NEXTPOOL=
on your LTO1/LTO2 stgpool(s) to the new LTO3 or LTO4
stgpools. Now just MIGRATE STGPOOL the LTO1/2 over to the LTO4 pool. No need
to do individual MOVE DATA/NODEDATA. Just let migration
handle it all for you. Cancel it and restart it as you need.

Bill Boyer
"I haven't lost my mind...it's backed up on tape somewhere!" - ??


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Bell, Charles (Chip)
Sent: Wednesday, January 09, 2008 10:16 AM
To: ADSM-L@VM.MARIST.EDU 
Subject: LTO1/LTO2 to LTO4 migration?

Is it possible to run 'move data' or 'move nodedata' commands from either
LTO1 or LTO2 device class to LTO4? What about from LTO1/2 to LTO3? Has anyone
done this?



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.



#
This message is for the named person's use only.  It may
contain confidential, proprietary, or legally privileged
information.  No confidentiality or privilege is waived or
lost by any mistransmission.  If you receive this message
in error, please immediately delete it and all copies of it
from your system, destroy any hard copies of it, and notify
the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message
if you are not the intended recipient.  Health First reserves
the right to monitor all e-mail communications through its
networks.  Any views or opinions expressed in this message
are solely those of the individual sender, except (1) where
the message states such views or opinions are on behalf of
a particular entity;  and (2) the sender is authorized by
the entity to give such views or opinions.
#

Re: LTO1/LTO2 to LTO4 migration?

[Bell, Charles (Chip)]

That sounds great! So to confirm, there are no technical gotchas that are
going to prevent data movement from one media type (LTO1/2) ton another
(LTO3/4)? Anyone else done this?

Thanks, Bill!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
William Boyer
Sent: Wednesday, January 09, 2008 9:25 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] LTO1/LTO2 to LTO4 migration?

Just define up your new tape drives/devc/stgpools and then set the NEXTPOOL=
on your LTO1/LTO2 stgpool(s) to the new LTO3 or LTO4
stgpools. Now just MIGRATE STGPOOL the LTO1/2 over to the LTO4 pool. No need
to do individual MOVE DATA/NODEDATA. Just let migration
handle it all for you. Cancel it and restart it as you need.

Bill Boyer
"I haven't lost my mind...it's backed up on tape somewhere!" - ??


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Bell, Charles (Chip)
Sent: Wednesday, January 09, 2008 10:16 AM
To: ADSM-L@VM.MARIST.EDU
Subject: LTO1/LTO2 to LTO4 migration?

Is it possible to run 'move data' or 'move nodedata' commands from either
LTO1 or LTO2 device class to LTO4? What about from LTO1/2 to LTO3? Has anyone
done this?



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.

Re: LTO1/LTO2 to LTO4 migration?

[Bell, Charles (Chip)]

OK I'm confused.  :)

I asked: "That sounds great! So to confirm, there are no technical gotchas
that are going to prevent data movement from one media type (LTO1/2) ton
another (LTO3/4)? Anyone else done this?"

I receive the two following responses:

"Well, yes there is.

An LTO4 tape drive will NOT be able to read any data from an LTO1 tape
cartridge.

The LTO specifications call for any LTO cartridge to be readable and
writeable for a drive one level up (LTO1 to LTO2, for instance), and for any
LTO cartridge to be readable ONLY for a drive two levels up (LTO1 to LTO3,
for instance."

And..

"That's correct, one of the real nice things about TSM.

This is basically the same as migrating from any kind of
disk pool to any kind of tape pool, doesn't matter the
media type/technology.

You do need to remember though that after you have
migrated ALL of your onsite tape pool and it's offsite copies
have been made, then you need to "delete volume" with
discarddata option on the OLD offsite pool tapes, or else
old tapes will still be there."

Help a brother out...can both responses be correct? So far I have 2 to 1 in
favor of TSM can handle it. But it's not a poll, either I can or I can't do
it, right?  :)


>>> "Bell, Charles (Chip)" <[EMAIL PROTECTED]> 1/9/2008 10:28 AM >>>
That sounds great! So to confirm, there are no technical gotchas that are
going to prevent data movement from one media type (LTO1/2) ton another
(LTO3/4)? Anyone else done this?

Thanks, Bill!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
William Boyer
Sent: Wednesday, January 09, 2008 9:25 AM
To: ADSM-L@VM.MARIST.EDU 
Subject: Re: [ADSM-L] LTO1/LTO2 to LTO4 migration?

Just define up your new tape drives/devc/stgpools and then set the NEXTPOOL=
on your LTO1/LTO2 stgpool(s) to the new LTO3 or LTO4
stgpools. Now just MIGRATE STGPOOL the LTO1/2 over to the LTO4 pool. No need
to do individual MOVE DATA/NODEDATA. Just let migration
handle it all for you. Cancel it and restart it as you need.

Bill Boyer
"I haven't lost my mind...it's backed up on tape somewhere!" - ??


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Bell, Charles (Chip)
Sent: Wednesday, January 09, 2008 10:16 AM
To: ADSM-L@VM.MARIST.EDU 
Subject: LTO1/LTO2 to LTO4 migration?

Is it possible to run 'move data' or 'move nodedata' commands from either
LTO1 or LTO2 device class to LTO4? What about from LTO1/2 to LTO3? Has anyone
done this?



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.



#
This message is for the named person's use only.  It may
contain confidential, proprietary, or legally privileged
information.  No confidentiality or privilege is waived or
lost by any mistransmission.  If you receive this message
in error, please immediately delete it and all copies of it
from your system, destroy any hard copies of it, and notify
the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message
if you are not the intended recipient.  Health First reserves
the right to monitor all e-mail communications through its
networks.  Any views or opinions expressed in this message
are solely those of the individual sender, except (1) where
the message states such views or opinions are on behalf of
a particular entity;  and (2) the sender is authorized by
the entity to give such views or opinions.
#

Re: LTO1/LTO2 to LTO4 migration?

[Bell, Charles (Chip)]

Yep. Thanks!

We're going to migrate when time comes, not "rip out and replace". 

Thanks again!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Wanda Prather
Sent: Wednesday, January 09, 2008 10:13 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] LTO1/LTO2 to LTO4 migration?

Been there done that lots of times.  But the answer depends on what you
mean.

If you have both LTO1/LTO2 and LTO4 drives in the same physical library, the
LTO4 drives will be in a different device class, different logical library,
differen storage pools.  You can run MOVE DATA, MOVE NODEDATA, or a MIGRATE
command (assuming you are at least TSM 5.3) to move your data from the old
tapes to the new ones.

If you are talking about replacing your LTO1/2 drives with new drives, so
that you only have the new drives in the library, here's the deal:

LTO drives can write one generation back, read 2 generations back.

SO,
an LTO3 drive can read an LTO1 cartridges, and read/write an LTO2 cartridge.
an LTO4 drive can only read LTO2 cartrdiges
an LTO1 drive can't do anything with an LTO1 cartridge

So for example, if you had your CE pull out LTO1 drives and replace them
with LTO3, you would mar your LTO1 cartrdiges as READONLY, and run MOVE DATA
(or MIGRATE) to get the data onto LTO3 cartridiges.
You can do the same with the LTO2 cartridges, or continue using them
read/write with the LTO3 drives (but you don't get the capacity increase).

Does any of that answer your questions?


On 1/9/08, Bell, Charles (Chip) <[EMAIL PROTECTED]> wrote:

> Is it possible to run 'move data' or 'move nodedata' commands from either
> LTO1 or LTO2 device class to LTO4? What about from LTO1/2 to LTO3? Has
> anyone
> done this?
>
>
>
> 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.
>

Re: "Freezing" my Email backups and starting fresh

[Wanda Prather]

The only way to guarantee that your stuff will not expire, is to change the
copy group retention to NOLIM/NOLIM/NOLIM/NOLIM.

SO here's what I would do:

Copy the domain EXCHANGE to a new domain EXCHANGE-FREEZE
Update the copy groups in that domain to verexist=NOLIM, retextra=NOLIM, etc
etc
Activate the policy set to pick up the changes
Rename your mail client to CLIENT-FREEZE
Update CLIENT-FREEZE to domain=EXCHANGE-FREEZE

That puts all the backups for the mail client into a domain where NOTHING
ever expires.

Re-register your client with its original name in the EXCHANGE domain, and
continue backing up with it.
Future backups will still be governed by the rules in the EXCHANGE comain,
but the stuff in the EXCHANGE-FREEZE domain will just sit there.

YOu will have to remember if somebody needs a restore of EXCHANGE stuff
prior to today, you'll need to get it from the CLIENT-FREEZE client.

There are alternatives, including a backupset and an export tape.  The
problem I have with those:  the data is on the tape, but the older backups
will continue to expire out of the TSM DB.  So, 6 months from now, you don't
have anyway to figure out what is ON the backupset or EXPORT tape.  This way
you can query the DB to see what is in there, if your lawyers need
something.

Wanda

On 1/9/08, Bell, Charles (Chip) <[EMAIL PROTECTED]> wrote:
>
> I just had a request from my boss via our legal dept. to freeze our email
> backups, but of course we want to continue our backups nightly going
> forward.
> What is the easiest way to do that? Our Exchange backups our managed
> through
> a domain called EXCHANGE, go straight to VTL, and are sent offsite on
> LTO2.
> Thanks in advance!
>
>
>
> God bless you!!!
>
> Chip Bell
> Network Engineer I
> IBM Tivoli Certified Deployment Professional (ITSM 5.2)
> Baptist Health System
> Birmingham, AL
> Office (205) 715-5106
> Pager (205) 817-0357
> Home (256) 739-0947
> Cell (256) 347-7294
>
>
>
>
>
>
> -
> 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.
>

Re: LTO1/LTO2 to LTO4 migration?

[Bell, Charles (Chip)]

Excellent! (On the renaming idea).

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
William Boyer
Sent: Wednesday, January 09, 2008 10:07 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] LTO1/LTO2 to LTO4 migration?

Creating the "new" copypool on the LTO4 tapes is going to be a big hit at the
beginning.

Another thing I would do is to rename your existing LTO1/2 stgpools to
something else, and then when you create the new LTO4 stgpool
call them the same names. That way you don't have to change any of your
scripts and procedures.

Bill Boyer
"A life? Cool! Where can I download one of those?" - ??


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
David Longo
Sent: Wednesday, January 09, 2008 10:50 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: LTO1/LTO2 to LTO4 migration?

That's correct, one of the real nice things about TSM.

This is basically the same as migrating from any kind of disk pool to any
kind of tape pool, doesn't matter the media
type/technology.

You do need to remember though that after you have migrated ALL of your
onsite tape pool and it's offsite copies have been made,
then you need to "delete volume" with discarddata option on the OLD offsite
pool tapes, or else old tapes will still be there.

DL

>>> "Bell, Charles (Chip)" <[EMAIL PROTECTED]> 1/9/2008 10:28 AM >>>
That sounds great! So to confirm, there are no technical gotchas that are
going to prevent data movement from one media type
(LTO1/2) ton another (LTO3/4)? Anyone else done this?

Thanks, Bill!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
William Boyer
Sent: Wednesday, January 09, 2008 9:25 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] LTO1/LTO2 to LTO4 migration?

Just define up your new tape drives/devc/stgpools and then set the NEXTPOOL=
on your LTO1/LTO2 stgpool(s) to the new LTO3 or LTO4
stgpools. Now just MIGRATE STGPOOL the LTO1/2 over to the LTO4 pool. No need
to do individual MOVE DATA/NODEDATA. Just let migration
handle it all for you. Cancel it and restart it as you need.

Bill Boyer
"I haven't lost my mind...it's backed up on tape somewhere!" - ??


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Bell, Charles (Chip)
Sent: Wednesday, January 09, 2008 10:16 AM
To: ADSM-L@VM.MARIST.EDU
Subject: LTO1/LTO2 to LTO4 migration?

Is it possible to run 'move data' or 'move nodedata' commands from either
LTO1 or LTO2 device class to LTO4? What about from LTO1/2 to LTO3? Has anyone
done this?



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.



#
This message is for the named person's use only.  It may contain
confidential, proprietary, or legally privileged information.  No
confidentiality or privilege is waived or lost by any mistransmission.  If
you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies of
it, and notify the sender.  You must not, directly or
indirectly, use, disclose, distribute, print, or copy any part of this
message if you are not the intended recipient.  Health First
reserves the right to monitor all e-mail communications through its networks.
Any views or opinions expressed in this message are
solely those of the individual sender, except (1) where the message states
such views or opinions are on behalf of a particular
entity;  and (2) the sender is authorized by the entity to give such views or
opinions.
#

Re: LTO1/LTO2 to LTO4 migration?

[William Boyer]

Creating the "new" copypool on the LTO4 tapes is going to be a big hit at the 
beginning.

Another thing I would do is to rename your existing LTO1/2 stgpools to 
something else, and then when you create the new LTO4 stgpool
call them the same names. That way you don't have to change any of your scripts 
and procedures.

Bill Boyer
"A life? Cool! Where can I download one of those?" - ??


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of David Longo
Sent: Wednesday, January 09, 2008 10:50 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: LTO1/LTO2 to LTO4 migration?

That's correct, one of the real nice things about TSM.

This is basically the same as migrating from any kind of disk pool to any kind 
of tape pool, doesn't matter the media
type/technology.

You do need to remember though that after you have migrated ALL of your onsite 
tape pool and it's offsite copies have been made,
then you need to "delete volume" with discarddata option on the OLD offsite 
pool tapes, or else old tapes will still be there.

DL

>>> "Bell, Charles (Chip)" <[EMAIL PROTECTED]> 1/9/2008 10:28 AM >>>
That sounds great! So to confirm, there are no technical gotchas that are going 
to prevent data movement from one media type
(LTO1/2) ton another (LTO3/4)? Anyone else done this?

Thanks, Bill!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of William 
Boyer
Sent: Wednesday, January 09, 2008 9:25 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] LTO1/LTO2 to LTO4 migration?

Just define up your new tape drives/devc/stgpools and then set the NEXTPOOL= on 
your LTO1/LTO2 stgpool(s) to the new LTO3 or LTO4
stgpools. Now just MIGRATE STGPOOL the LTO1/2 over to the LTO4 pool. No need to 
do individual MOVE DATA/NODEDATA. Just let migration
handle it all for you. Cancel it and restart it as you need.

Bill Boyer
"I haven't lost my mind...it's backed up on tape somewhere!" - ??


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Bell, 
Charles (Chip)
Sent: Wednesday, January 09, 2008 10:16 AM
To: ADSM-L@VM.MARIST.EDU
Subject: LTO1/LTO2 to LTO4 migration?

Is it possible to run 'move data' or 'move nodedata' commands from either
LTO1 or LTO2 device class to LTO4? What about from LTO1/2 to LTO3? Has anyone 
done this?



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.



#
This message is for the named person's use only.  It may contain confidential, 
proprietary, or legally privileged information.  No
confidentiality or privilege is waived or lost by any mistransmission.  If you 
receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies of it, 
and notify the sender.  You must not, directly or
indirectly, use, disclose, distribute, print, or copy any part of this message 
if you are not the intended recipient.  Health First
reserves the right to monitor all e-mail communications through its networks.  
Any views or opinions expressed in this message are
solely those of the individual sender, except (1) where the message states such 
views or opinions are on behalf of a particular
entity;  and (2) the sender is authorized by the entity to give such views or 
opinions.
#

Re: LTO1/LTO2 to LTO4 migration?

[Wanda Prather]

Been there done that lots of times.  But the answer depends on what you
mean.

If you have both LTO1/LTO2 and LTO4 drives in the same physical library, the
LTO4 drives will be in a different device class, different logical library,
differen storage pools.  You can run MOVE DATA, MOVE NODEDATA, or a MIGRATE
command (assuming you are at least TSM 5.3) to move your data from the old
tapes to the new ones.

If you are talking about replacing your LTO1/2 drives with new drives, so
that you only have the new drives in the library, here's the deal:

LTO drives can write one generation back, read 2 generations back.

SO,
an LTO3 drive can read an LTO1 cartridges, and read/write an LTO2 cartridge.
an LTO4 drive can only read LTO2 cartrdiges
an LTO1 drive can't do anything with an LTO1 cartridge

So for example, if you had your CE pull out LTO1 drives and replace them
with LTO3, you would mar your LTO1 cartrdiges as READONLY, and run MOVE DATA
(or MIGRATE) to get the data onto LTO3 cartridiges.
You can do the same with the LTO2 cartridges, or continue using them
read/write with the LTO3 drives (but you don't get the capacity increase).

Does any of that answer your questions?


On 1/9/08, Bell, Charles (Chip) <[EMAIL PROTECTED]> wrote:

> Is it possible to run 'move data' or 'move nodedata' commands from either
> LTO1 or LTO2 device class to LTO4? What about from LTO1/2 to LTO3? Has
> anyone
> done this?
>
>
>
> 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.
>

Re: AW: [ADSM-L] 3592 Drive Encryption

[Wanda Prather]

I'm confused.

The 3592-J1A drives (the original 3592s) require an upgrade to support
encryption.
The 3592-E05 drives are now called TS1120 drives; I thought ALL those drives
shipped with encryption.
The question may be what type of library you have, and whether the library
requires a firmware upgrade for encryption support.

If you are going to run TSM-based encryption, I strongly recommend upgrading
to 5.5 first.  In 5.3/5.4, the TDP clients support "transparent" encryption;
you don't have to worry about key management, TSM generates random keys and
manages them for you.  Starting in 5.5, the basic clients work the same way,
with "Transparent" encryption using randomly generated keys stored in the
TSM DB.

IF you turn on client encryption, be sure to turn on client compression as
well.  Once the data is encrypted, the tape drives can't compress it
outboard.  The clients are smart enough to do compression before encryption,
if both are enabled.  (This will slow down your backups, and especially slow
down restores because of the cycles needed to decompress and decrypt.)

But I agree with Neil;  hardware encryption is faster and cleaner.  I would
double check on your drive support


On 1/9/08, Herrmann, Boris <[EMAIL PROTECTED]> wrote:
>
> Neil,
>
> thanks for your detailed information. I've checked with IBM support.
> Unfortunately our 3592-E05 Drives are not encryption capable. IBM support
> told me that we can purchase a feature code (with the result, that all our
> drives would be replaced with new one), but our management didn't want pay
> anything.
>
> They asked me, if there would be any other way to encrypt the data without
> any cost. I don't know any way except the TSM client encryption (but I think
> it's not pratically to encrypt every data on the client systems, or is it?).
> We make normal backups and archives, a lot of db2 api backups, TDP
> (Exchange, Domino, MSSQL) and Oracle RMAN backups. Every day we backup up
> about 3-5 TB.
>
> Does anyone have any other practical implementation of encrypting Volumes
> without hardware drive encryption?
>
> With kind regards,
> __
>
> Boris Herrmann
> Produktion / Heterogene Systeme
>
> ARAG IT GmbH
> ARAG Platz 1, 40472 Düsseldorf
>
> Tel:  +49 (0)211 964-1137
> Fax: +49 (0)211 964-1155
> [EMAIL PROTECTED]
> www.ARAG.de
>
>
> Geschäftsführer:  Ottmar Liebler, Hanno Petersen
> Sitz und Registergericht:  Düsseldorf,  HRB 10934
> USt-ID-Nr.:  DE 119 356 473
>
>
>
> -Ursprüngliche Nachricht-
> Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von
> Strand, Neil B.
> Gesendet: Montag, 7. Januar 2008 17:03
> An: ADSM-L@VM.MARIST.EDU
> Betreff: Re: [ADSM-L] 3592 Drive Encryption
>
>
> Boris,
>   Verify that the library and drives are capable - may need a firmware
> upgrade or feature code - check with IBM.  You will also want to ensure you
> have the latest Atape driver installed.
>
>   A logical library is either encryption capable or not - the drives in a
> logical library cannot be mixed.  If you implement library managed
> encryption, you have a great deal of flexibility over which volumes get
> encrypted and with which encryption keys they are encrypted with.
>
>   I strongly encourage you to set up at least two, redundant Encryption
> Key Managers (EKM) because if a drive is unable to get a key, you get no
> volume to read from or write to and things can grind to a halt quickly.
>   There are several IBM references including a Redbook on setting up the
> EKM.
>
>   You may consider first creating a logical library with one or two drives
> and then testing various configurations with a small number of volumes and
> data that can be lost if you mess up.  If you lose the encryption key, you
> lose the data that was saved with it - you have been warned, no key, no
> data.
>
>   I encrypt everyting that goes on tape (primary and copy pools) on the
> assumption that tape is easily transportable.  If a tape is ejected from the
> library (for any reason), all of the data is still protected by
> encryption.  There is negligible performance impact with encryption on these
> drives.
>
>   Plan on at least a 4 -6 week implementation and make sure you test and
> document your key and data recovery procedures and key changing procedures.
>
>   I choose to implement library managed rather than application managed
> because it offered flexibility to have the encryption component managed by
> our security team without having them learn TSM.  It also allows encryption
> of media outside of TSM so if we need to ship a tarfile on tape, it can be
> done securely with a minimum of fuss.  Library managed also allows you to
> specify which tapes get encrypted - a volser range or a single tape to be
> encrypted with a specific encryption key (that key could be shared with a
> business partner).
>
>
> Cheers,
> Neil Strand
> Storage Engineer - Legg Mason
> Baltimore, MD.
> (410) 580-7491
> Whatever you can do or bel

Re: AW: [ADSM-L] 3592 Drive Encryption

[David E Ehresman]

There are 3592-E05 drives which require an additional feature ($$) to
enable encryption.  We have six of them.

David

>>> Wanda Prather <[EMAIL PROTECTED]> 1/9/2008 11:46 AM >>>
I'm confused.

The 3592-J1A drives (the original 3592s) require an upgrade to support
encryption.
The 3592-E05 drives are now called TS1120 drives; I thought ALL those
drives
shipped with encryption.
The question may be what type of library you have, and whether the
library
requires a firmware upgrade for encryption support.

If you are going to run TSM-based encryption, I strongly recommend
upgrading
to 5.5 first.  In 5.3/5.4, the TDP clients support "transparent"
encryption;
you don't have to worry about key management, TSM generates random keys
and
manages them for you.  Starting in 5.5, the basic clients work the same
way,
with "Transparent" encryption using randomly generated keys stored in
the
TSM DB.

IF you turn on client encryption, be sure to turn on client compression
as
well.  Once the data is encrypted, the tape drives can't compress it
outboard.  The clients are smart enough to do compression before
encryption,
if both are enabled.  (This will slow down your backups, and especially
slow
down restores because of the cycles needed to decompress and decrypt.)

But I agree with Neil;  hardware encryption is faster and cleaner.  I
would
double check on your drive support


On 1/9/08, Herrmann, Boris <[EMAIL PROTECTED]> wrote:
>
> Neil,
>
> thanks for your detailed information. I've checked with IBM support.
> Unfortunately our 3592-E05 Drives are not encryption capable. IBM
support
> told me that we can purchase a feature code (with the result, that
all our
> drives would be replaced with new one), but our management didn't
want pay
> anything.
>
> They asked me, if there would be any other way to encrypt the data
without
> any cost. I don't know any way except the TSM client encryption (but
I think
> it's not pratically to encrypt every data on the client systems, or
is it?).
> We make normal backups and archives, a lot of db2 api backups, TDP
> (Exchange, Domino, MSSQL) and Oracle RMAN backups. Every day we
backup up
> about 3-5 TB.
>
> Does anyone have any other practical implementation of encrypting
Volumes
> without hardware drive encryption?
>
> With kind regards,
> __
>
> Boris Herrmann
> Produktion / Heterogene Systeme
>
> ARAG IT GmbH
> ARAG Platz 1, 40472 Düsseldorf
>
> Tel:  +49 (0)211 964-1137
> Fax: +49 (0)211 964-1155
> [EMAIL PROTECTED] 
> www.ARAG.de 
>
>
> Geschäftsführer:  Ottmar Liebler, Hanno Petersen
> Sitz und Registergericht:  Düsseldorf,  HRB 10934
> USt-ID-Nr.:  DE 119 356 473
>
>
>
> -Ursprüngliche Nachricht-
> Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag
von
> Strand, Neil B.
> Gesendet: Montag, 7. Januar 2008 17:03
> An: ADSM-L@VM.MARIST.EDU 
> Betreff: Re: [ADSM-L] 3592 Drive Encryption
>
>
> Boris,
>   Verify that the library and drives are capable - may need a
firmware
> upgrade or feature code - check with IBM.  You will also want to
ensure you
> have the latest Atape driver installed.
>
>   A logical library is either encryption capable or not - the drives
in a
> logical library cannot be mixed.  If you implement library managed
> encryption, you have a great deal of flexibility over which volumes
get
> encrypted and with which encryption keys they are encrypted with.
>
>   I strongly encourage you to set up at least two, redundant
Encryption
> Key Managers (EKM) because if a drive is unable to get a key, you get
no
> volume to read from or write to and things can grind to a halt
quickly.
>   There are several IBM references including a Redbook on setting up
the
> EKM.
>
>   You may consider first creating a logical library with one or two
drives
> and then testing various configurations with a small number of
volumes and
> data
 that can be lost if you mess up.  If you lose the encryption
key, you
> lose the data that was saved with it - you have been warned, no key,
no
> data.
>
>   I encrypt everyting that goes on tape (primary and copy pools) on
the
> assumption that tape is easily transportable.  If a tape is ejected
from the
> library (for any reason), all of the data is still protected by
> encryption.  There is negligible performance impact with encryption
on these
> drives.
>
>   Plan on at least a 4 -6 week implementation and make sure you test
and
> document your key and data recovery procedures and key changing
procedures.
>
>   I choose to implement library managed rather than application
managed
> because it offered flexibility to have the encryption component
managed by
> our security team without having them learn TSM.  It also allows
encryption
> of media outside of TSM so if we need to ship a tarfile on tape, it
can be
> done securely with a minimum of fuss.  Library managed also allows
you to
> specify which tapes get encrypted - a volser range or a single tape
to be
> encrypted with a specific encrypti

Re: AW: [ADSM-L] 3592 Drive Encryption

[Mahesh Tailor]

All new TS1120-E05 come with encryption capability out of the box.  You
can then use the Encryption Key Manager (EKM), which is a free download
from IBM , or use TSM encryption.   If you have multiple TSM server
sharing a library, you will need to use EKM for central management of
the keys.
 
Mahesh

>>> David E Ehresman <[EMAIL PROTECTED]> 1/9/2008 13:12 >>>
There are 3592-E05 drives which require an additional feature ($$) to
enable encryption.  We have six of them.

David

>>> Wanda Prather <[EMAIL PROTECTED]> 1/9/2008 11:46 AM >>>
I'm confused.

The 3592-J1A drives (the original 3592s) require an upgrade to support
encryption.
The 3592-E05 drives are now called TS1120 drives; I thought ALL those
drives
shipped with encryption.
The question may be what type of library you have, and whether the
library
requires a firmware upgrade for encryption support.

If you are going to run TSM-based encryption, I strongly recommend
upgrading
to 5.5 first.  In 5.3/5.4, the TDP clients support "transparent"
encryption;
you don't have to worry about key management, TSM generates random
keys
and
manages them for you.  Starting in 5.5, the basic clients work the
same
way,
with "Transparent" encryption using randomly generated keys stored in
the
TSM DB.

IF you turn on client encryption, be sure to turn on client
compression
as
well.  Once the data is encrypted, the tape drives can't compress it
outboard.  The clients are smart enough to do compression before
encryption,
if both are enabled.  (This will slow down your backups, and
especially
slow
down restores because of the cycles needed to decompress and decrypt.)

But I agree with Neil;  hardware encryption is faster and cleaner.  I
would
double check on your drive support


On 1/9/08, Herrmann, Boris <[EMAIL PROTECTED]> wrote:
>
> Neil,
>
> thanks for your detailed information. I've checked with IBM support.
> Unfortunately our 3592-E05 Drives are not encryption capable. IBM
support
> told me that we can purchase a feature code (with the result, that
all our
> drives would be replaced with new one), but our management didn't
want pay
> anything.
>
> They asked me, if there would be any other way to encrypt the data
without
> any cost. I don't know any way except the TSM client encryption (but
I think
> it's not pratically to encrypt every data on the client systems, or
is it?).
> We make normal backups and archives, a lot of db2 api backups, TDP
> (Exchange, Domino, MSSQL) and Oracle RMAN backups. Every day we
backup up
> about 3-5 TB.
>
> Does anyone have any other practical implementation of encrypting
Volumes
> without hardware drive encryption?
>
> With kind regards,
> __
>
> Boris Herrmann
> Produktion / Heterogene Systeme
>
> ARAG IT GmbH
> ARAG Platz 1, 40472 Düsseldorf
>
> Tel:  +49 (0)211 964-1137
> Fax: +49 (0)211 964-1155
> [EMAIL PROTECTED] 
> www.ARAG.de 
>
>
> Geschäftsführer:  Ottmar Liebler, Hanno Petersen
> Sitz und Registergericht:  Düsseldorf,  HRB 10934
> USt-ID-Nr.:  DE 119 356 473
>
>
>
> -Ursprüngliche Nachricht-
> Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im
Auftrag
von
> Strand, Neil B.
> Gesendet: Montag, 7. Januar 2008 17:03
> An: ADSM-L@VM.MARIST.EDU 
> Betreff: Re: [ADSM-L] 3592 Drive Encryption
>
>
> Boris,
>   Verify that the library and drives are capable - may need a
firmware
> upgrade or feature code - check with IBM.  You will also want to
ensure you
> have the latest Atape driver installed.
>
>   A logical library is either encryption capable or not - the drives
in a
> logical library cannot be mixed.  If you implement library managed
> encryption, you have a great deal of flexibility over which volumes
get
> encrypted and with which encryption keys they are encrypted with.
>
>   I strongly encourage you to set up at least two, redundant
Encryption
> Key Managers (EKM) because if a drive is unable to get a key, you
get
no
> volume to read from or write to and things can grind to a halt
quickly.
>   There are several IBM references including a Redbook on setting up
the
> EKM.
>
>   You may consider first creating a logical library with one or two
drives
> and then testing various configurations with a small number of
volumes and
> data
that can be lost if you mess up.  If you lose the encryption
key, you
> lose the data that was saved with it - you have been warned, no key,
no
> data.
>
>   I encrypt everyting that goes on tape (primary and copy pools) on
the
> assumption that tape is easily transportable.  If a tape is ejected
from the
> library (for any reason), all of the data is still protected by
> encryption.  There is negligible performance impact with encryption
on these
> drives.
>
>   Plan on at least a 4 -6 week implementation and make sure you test
and
> document your key and data recovery procedures and key changing
procedures.
>
>   I choose to implement library managed rather than application
managed
> because it offered flexibility to have the encryption com

Re: New Redbook and paper - TSM V5.4/5.5 Technical Guide

[Wanda Prather]

Thanks Charlotte!!

On 1/2/08, Charlotte Brooks <[EMAIL PROTECTED]> wrote:
>
> HI all
> check out new draft Redbook Tivoli Storage Manager V5.4 and V5.5 Technical
> Guide - describes the new features of these releases.
> http://www.redbooks.ibm.com/redpieces/abstracts/sg247447.html?Open
>
> Also, a paper on how to move the Library Manager in a library sharing
> environment - complete with some helpful scripts
> http://www.redbooks.ibm.com/redpieces/abstracts/redp0140.html?Open
>
> Regards, Charlotte
> Project Leader and Certified IT Specialist
> IBM System Storage Solutions, ITSO San Jose
> email: [EMAIL PROTECTED]
> Ph: (408)-354-6156 T/L 544-8217
> http://ibm.com/redbooks
>

Re: New Redbook and paper - TSM V5.4/5.5 Technical Guide

[Bell, Charles (Chip)]

I think there was a draft of a new Implementation Guide out there as well...

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Wanda Prather
Sent: Wednesday, January 09, 2008 1:10 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] New Redbook and paper - TSM V5.4/5.5 Technical Guide

Thanks Charlotte!!

On 1/2/08, Charlotte Brooks <[EMAIL PROTECTED]> wrote:
>
> HI all
> check out new draft Redbook Tivoli Storage Manager V5.4 and V5.5 Technical
> Guide - describes the new features of these releases.
> http://www.redbooks.ibm.com/redpieces/abstracts/sg247447.html?Open
>
> Also, a paper on how to move the Library Manager in a library sharing
> environment - complete with some helpful scripts
> http://www.redbooks.ibm.com/redpieces/abstracts/redp0140.html?Open
>
> Regards, Charlotte
> Project Leader and Certified IT Specialist
> IBM System Storage Solutions, ITSO San Jose
> email: [EMAIL PROTECTED]
> Ph: (408)-354-6156 T/L 544-8217
> http://ibm.com/redbooks
>

-
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.

Re: New Redbook and paper - TSM V5.4/5.5 Technical Guide

[Timothy Hughes]

Chip,

I only see the Fourth Edition (June 2006) Implementaion Guide (This
edition applies to IBM Tivoli Storage Manager Version 5.3.2.)
Is there a newer one that covers 5.5?


Thanks


Bell, Charles (Chip) wrote:

I think there was a draft of a new Implementation Guide out there as well...

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Wanda Prather
Sent: Wednesday, January 09, 2008 1:10 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] New Redbook and paper - TSM V5.4/5.5 Technical Guide

Thanks Charlotte!!

On 1/2/08, Charlotte Brooks <[EMAIL PROTECTED]> wrote:


HI all
check out new draft Redbook Tivoli Storage Manager V5.4 and V5.5 Technical
Guide - describes the new features of these releases.
http://www.redbooks.ibm.com/redpieces/abstracts/sg247447.html?Open

Also, a paper on how to move the Library Manager in a library sharing
environment - complete with some helpful scripts
http://www.redbooks.ibm.com/redpieces/abstracts/redp0140.html?Open

Regards, Charlotte
Project Leader and Certified IT Specialist
IBM System Storage Solutions, ITSO San Jose
email: [EMAIL PROTECTED]
Ph: (408)-354-6156 T/L 544-8217
http://ibm.com/redbooks




-
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.

Re: "Freezing" my Email backups and starting fresh

[Bell, Charles (Chip)]

OK, I followed through with your suggestions, in order. If I follow them, I
would not need to change the copy group retention to nolimit across the
board? Just asking...I would prefer not to have to retain everything forever.
:)

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Wanda Prather
Sent: Wednesday, January 09, 2008 10:22 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] "Freezing" my Email backups and starting fresh

The only way to guarantee that your stuff will not expire, is to change the
copy group retention to NOLIM/NOLIM/NOLIM/NOLIM.

SO here's what I would do:

Copy the domain EXCHANGE to a new domain EXCHANGE-FREEZE
Update the copy groups in that domain to verexist=NOLIM, retextra=NOLIM, etc
etc
Activate the policy set to pick up the changes
Rename your mail client to CLIENT-FREEZE
Update CLIENT-FREEZE to domain=EXCHANGE-FREEZE

That puts all the backups for the mail client into a domain where NOTHING
ever expires.

Re-register your client with its original name in the EXCHANGE domain, and
continue backing up with it.
Future backups will still be governed by the rules in the EXCHANGE comain,
but the stuff in the EXCHANGE-FREEZE domain will just sit there.

YOu will have to remember if somebody needs a restore of EXCHANGE stuff
prior to today, you'll need to get it from the CLIENT-FREEZE client.

There are alternatives, including a backupset and an export tape.  The
problem I have with those:  the data is on the tape, but the older backups
will continue to expire out of the TSM DB.  So, 6 months from now, you don't
have anyway to figure out what is ON the backupset or EXPORT tape.  This way
you can query the DB to see what is in there, if your lawyers need
something.

Wanda

On 1/9/08, Bell, Charles (Chip) <[EMAIL PROTECTED]> wrote:
>
> I just had a request from my boss via our legal dept. to freeze our email
> backups, but of course we want to continue our backups nightly going
> forward.
> What is the easiest way to do that? Our Exchange backups our managed
> through
> a domain called EXCHANGE, go straight to VTL, and are sent offsite on
> LTO2.
> Thanks in advance!
>
>
>
> God bless you!!!
>
> Chip Bell
> Network Engineer I
> IBM Tivoli Certified Deployment Professional (ITSM 5.2)
> Baptist Health System
> Birmingham, AL
> Office (205) 715-5106
> Pager (205) 817-0357
> Home (256) 739-0947
> Cell (256) 347-7294
>
>
>
>
>
>
> -
> 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.
>

Re: New Redbook and paper - TSM V5.4/5.5 Technical Guide

[Bell, Charles (Chip)]

You're probably right. But according to the IBM Redbooks Weekly Newsletter,
there was a revision in December. I haven't reviewed to see if it was a major
or minor revision...

http://www.redbooks.ibm.com/abstracts/sg245416.html?Open


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Timothy Hughes
Sent: Wednesday, January 09, 2008 1:34 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] New Redbook and paper - TSM V5.4/5.5 Technical Guide

Chip,

I only see the Fourth Edition (June 2006) Implementaion Guide (This
edition applies to IBM Tivoli Storage Manager Version 5.3.2.)
Is there a newer one that covers 5.5?


Thanks


Bell, Charles (Chip) wrote:
> I think there was a draft of a new Implementation Guide out there as
well...
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
> Wanda Prather
> Sent: Wednesday, January 09, 2008 1:10 PM
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: [ADSM-L] New Redbook and paper - TSM V5.4/5.5 Technical Guide
>
> Thanks Charlotte!!
>
> On 1/2/08, Charlotte Brooks <[EMAIL PROTECTED]> wrote:
>
>> HI all
>> check out new draft Redbook Tivoli Storage Manager V5.4 and V5.5 Technical
>> Guide - describes the new features of these releases.
>> http://www.redbooks.ibm.com/redpieces/abstracts/sg247447.html?Open
>>
>> Also, a paper on how to move the Library Manager in a library sharing
>> environment - complete with some helpful scripts
>> http://www.redbooks.ibm.com/redpieces/abstracts/redp0140.html?Open
>>
>> Regards, Charlotte
>> Project Leader and Certified IT Specialist
>> IBM System Storage Solutions, ITSO San Jose
>> email: [EMAIL PROTECTED]
>> Ph: (408)-354-6156 T/L 544-8217
>> http://ibm.com/redbooks
>>
>>
>
> -
> 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.
>

Re: New Redbook and paper - TSM V5.4/5.5 Technical Guide

[Timothy Hughes]

Ok, Yes your right it does say there was a revision on December 21. I
didn't review it either to see
if it covers TSM V5.5.

Thanks

Bell, Charles (Chip) wrote:

You're probably right. But according to the IBM Redbooks Weekly Newsletter,
there was a revision in December. I haven't reviewed to see if it was a major
or minor revision...

http://www.redbooks.ibm.com/abstracts/sg245416.html?Open


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Timothy Hughes
Sent: Wednesday, January 09, 2008 1:34 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] New Redbook and paper - TSM V5.4/5.5 Technical Guide

Chip,

I only see the Fourth Edition (June 2006) Implementaion Guide (This
edition applies to IBM Tivoli Storage Manager Version 5.3.2.)
Is there a newer one that covers 5.5?


Thanks


Bell, Charles (Chip) wrote:


I think there was a draft of a new Implementation Guide out there as


well...


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Wanda Prather
Sent: Wednesday, January 09, 2008 1:10 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] New Redbook and paper - TSM V5.4/5.5 Technical Guide

Thanks Charlotte!!

On 1/2/08, Charlotte Brooks <[EMAIL PROTECTED]> wrote:



HI all
check out new draft Redbook Tivoli Storage Manager V5.4 and V5.5 Technical
Guide - describes the new features of these releases.
http://www.redbooks.ibm.com/redpieces/abstracts/sg247447.html?Open

Also, a paper on how to move the Library Manager in a library sharing
environment - complete with some helpful scripts
http://www.redbooks.ibm.com/redpieces/abstracts/redp0140.html?Open

Regards, Charlotte
Project Leader and Certified IT Specialist
IBM System Storage Solutions, ITSO San Jose
email: [EMAIL PROTECTED]
Ph: (408)-354-6156 T/L 544-8217
http://ibm.com/redbooks




-
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.

Re: "Freezing" my Email backups and starting fresh

[Wanda Prather]

Yes, you change ALL the copy group retentions to NOLIM, but ONLY in the
EXCHANGE-FREEZE domain.  And the only client in that domain
is CLIENT-FREEZE, the original Exchange backup client.

So those backups are locked down, but everything else (including the new
registration of your Exchange client) follows regular rules.


On 1/9/08, Bell, Charles (Chip) <[EMAIL PROTECTED]> wrote:
>
> OK, I followed through with your suggestions, in order. If I follow them,
> I
> would not need to change the copy group retention to nolimit across the
> board? Just asking...I would prefer not to have to retain everything
> forever.
> :)
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
> Wanda Prather
> Sent: Wednesday, January 09, 2008 10:22 AM
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: [ADSM-L] "Freezing" my Email backups and starting fresh
>
> The only way to guarantee that your stuff will not expire, is to change
> the
> copy group retention to NOLIM/NOLIM/NOLIM/NOLIM.
>
> SO here's what I would do:
>
> Copy the domain EXCHANGE to a new domain EXCHANGE-FREEZE
> Update the copy groups in that domain to verexist=NOLIM, retextra=NOLIM,
> etc
> etc
> Activate the policy set to pick up the changes
> Rename your mail client to CLIENT-FREEZE
> Update CLIENT-FREEZE to domain=EXCHANGE-FREEZE
>
> That puts all the backups for the mail client into a domain where NOTHING
> ever expires.
>
> Re-register your client with its original name in the EXCHANGE domain, and
> continue backing up with it.
> Future backups will still be governed by the rules in the EXCHANGE comain,
> but the stuff in the EXCHANGE-FREEZE domain will just sit there.
>
> YOu will have to remember if somebody needs a restore of EXCHANGE stuff
> prior to today, you'll need to get it from the CLIENT-FREEZE client.
>
> There are alternatives, including a backupset and an export tape.  The
> problem I have with those:  the data is on the tape, but the older backups
> will continue to expire out of the TSM DB.  So, 6 months from now, you
> don't
> have anyway to figure out what is ON the backupset or EXPORT tape.  This
> way
> you can query the DB to see what is in there, if your lawyers need
> something.
>
> Wanda
>
> On 1/9/08, Bell, Charles (Chip) <[EMAIL PROTECTED]> wrote:
> >
> > I just had a request from my boss via our legal dept. to freeze our
> email
> > backups, but of course we want to continue our backups nightly going
> > forward.
> > What is the easiest way to do that? Our Exchange backups our managed
> > through
> > a domain called EXCHANGE, go straight to VTL, and are sent offsite on
> > LTO2.
> > Thanks in advance!
> >
> >
> >
> > God bless you!!!
> >
> > Chip Bell
> > Network Engineer I
> > IBM Tivoli Certified Deployment Professional (ITSM 5.2)
> > Baptist Health System
> > Birmingham, AL
> > Office (205) 715-5106
> > Pager (205) 817-0357
> > Home (256) 739-0947
> > Cell (256) 347-7294
> >
> >
> >
> >
> >
> >
> > -
> > 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.
> >
>

Re: "Freezing" my Email backups and starting fresh

[Bell, Charles (Chip)]

DOH! OK, you said copy group retention, I read copy storage pool retention.
Understood now. 

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Wanda Prather
Sent: Wednesday, January 09, 2008 2:09 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] "Freezing" my Email backups and starting fresh

Yes, you change ALL the copy group retentions to NOLIM, but ONLY in the
EXCHANGE-FREEZE domain.  And the only client in that domain
is CLIENT-FREEZE, the original Exchange backup client.

So those backups are locked down, but everything else (including the new
registration of your Exchange client) follows regular rules.


On 1/9/08, Bell, Charles (Chip) <[EMAIL PROTECTED]> wrote:
>
> OK, I followed through with your suggestions, in order. If I follow them,
> I
> would not need to change the copy group retention to nolimit across the
> board? Just asking...I would prefer not to have to retain everything
> forever.
> :)
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
> Wanda Prather
> Sent: Wednesday, January 09, 2008 10:22 AM
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: [ADSM-L] "Freezing" my Email backups and starting fresh
>
> The only way to guarantee that your stuff will not expire, is to change
> the
> copy group retention to NOLIM/NOLIM/NOLIM/NOLIM.
>
> SO here's what I would do:
>
> Copy the domain EXCHANGE to a new domain EXCHANGE-FREEZE
> Update the copy groups in that domain to verexist=NOLIM, retextra=NOLIM,
> etc
> etc
> Activate the policy set to pick up the changes
> Rename your mail client to CLIENT-FREEZE
> Update CLIENT-FREEZE to domain=EXCHANGE-FREEZE
>
> That puts all the backups for the mail client into a domain where NOTHING
> ever expires.
>
> Re-register your client with its original name in the EXCHANGE domain, and
> continue backing up with it.
> Future backups will still be governed by the rules in the EXCHANGE comain,
> but the stuff in the EXCHANGE-FREEZE domain will just sit there.
>
> YOu will have to remember if somebody needs a restore of EXCHANGE stuff
> prior to today, you'll need to get it from the CLIENT-FREEZE client.
>
> There are alternatives, including a backupset and an export tape.  The
> problem I have with those:  the data is on the tape, but the older backups
> will continue to expire out of the TSM DB.  So, 6 months from now, you
> don't
> have anyway to figure out what is ON the backupset or EXPORT tape.  This
> way
> you can query the DB to see what is in there, if your lawyers need
> something.
>
> Wanda
>
> On 1/9/08, Bell, Charles (Chip) <[EMAIL PROTECTED]> wrote:
> >
> > I just had a request from my boss via our legal dept. to freeze our
> email
> > backups, but of course we want to continue our backups nightly going
> > forward.
> > What is the easiest way to do that? Our Exchange backups our managed
> > through
> > a domain called EXCHANGE, go straight to VTL, and are sent offsite on
> > LTO2.
> > Thanks in advance!
> >
> >
> >
> > God bless you!!!
> >
> > Chip Bell
> > Network Engineer I
> > IBM Tivoli Certified Deployment Professional (ITSM 5.2)
> > Baptist Health System
> > Birmingham, AL
> > Office (205) 715-5106
> > Pager (205) 817-0357
> > Home (256) 739-0947
> > Cell (256) 347-7294
> >
> >
> >
> >
> >
> >
> > -
> > 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.
> >
>