TSM/HSM

2011-06-21 Thread D'Antonio III, Vincent E (N-Aerotek)
Good Morning,
I am adding a new LTO3, 3310 library for use with HSM to replace the current 
LTO2 library.

The question I have is can you add a second library for use by HSM so I can 
migrate the data off the LTO2's to the new LTO3's?

If yes, what are the best practices to do so?

Thanks
Vince


TSM policy

2011-06-21 Thread ritchi64
hello group,

I have to implement TSM server. The client actual policy is keep everything 
for 2 months and a month copy for a year (standart) and 3 or 5 years fore some 
spicial request.

What will be te best way to do that without using to much tape. TSM server is 
6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on tape 
(to much).

+--
|This was sent by alainrich...@hotmail.com via Backup Central.
|Forward SPAM to ab...@backupcentral.com.
+--


Re: TSM policy

2011-06-21 Thread Richard Sims
Use the TSM Archive function for exceptional data retention which does not 
constitute regular backups.

   Richard Sims


Re: TSM/HSM

2011-06-21 Thread Remco Post
On 21 jun 2011, at 17:04, D'Antonio III, Vincent E (N-Aerotek) wrote:

 Good Morning,
 I am adding a new LTO3, 3310 library for use with HSM to replace the current 
 LTO2 library.
 
 The question I have is can you add a second library for use by HSM so I can 
 migrate the data off the LTO2's to the new LTO3's?
 
 If yes, what are the best practices to do so?
 

def libr lto3lib
def path ...
def dr ...
def dev lto3dev devt=lto libr=lto3lib
def stg lto3pool lto3dev maxscr=1000 
upd stg lto2pool next=lto3pool reclaimstg=lto3pool

and the migrate and/or reclaim the lto2pool

for details, RTFM :)

 Thanks
 Vince

-- 
Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622


Re: TSM policy

2011-06-21 Thread Remco Post
On 21 jun 2011, at 17:45, ritchi64 wrote:

 hello group,
 
 I have to implement TSM server. The client actual policy is keep everything 
 for 2 months and a month copy for a year (standart) and 3 or 5 years fore 
 some spicial request.
 
 What will be te best way to do that without using to much tape. TSM server is 
 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on tape 
 (to much).
 

if you have to ask these questions for such a large environment, I'd suggest 
finding a real TSM specialist. Somebody who is not afraid to tell the customer 
what sensible backup policies are, and what the difference between a backup and 
an archive is.

 +--
 |This was sent by alainrich...@hotmail.com via Backup Central.
 |Forward SPAM to ab...@backupcentral.com.
 +--

-- 
Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622


TSM policy

2011-06-21 Thread ritchi64
Humm!
What about the policy at your site? Can you share something useful?


On 21 jun 2011, at 19:45, remco wrote:

if you have to ask these questions for such a large environment, I'd suggest 
finding a real TSM specialist. Somebody who is not afraid to tell the 
customer what sensible backup policies are, and what the difference between a 
backup and an archive is.

 +--
 |This was sent by alainrich...@hotmail.com via Backup Central.
 |Forward SPAM to ab...@backupcentral.com.
 +--

--
Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl


On 21 jun 2011, at 17:45, ritchi64 wrote:

 hello group,

 I have to implement TSM server. The client actual policy is keep everything 
 for 2 months and a month copy for a year (standart) and 3 or 5 years fore 
 some spicial request.

 What will be te best way to do that without using to much tape. TSM server is 
 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on tape 
 (to much).


+--
|This was sent by alainrich...@hotmail.com via Backup Central.
|Forward SPAM to ab...@backupcentral.com.
+--


Re: TSM policy

2011-06-21 Thread Kelly J. Lipp
What Remco is saying that the discussion is much more complicated than the
simple strategy they are currently using.  If they have so much data on tape
now, keeping the same strategy will keep too much data on tape in the future
too.  So something must change.  Keeping a month end copy doesn't really
address the business requirements for archive.  A more complete conversation
that includes stake holders and compliance folks is required to narrow the
data down.

And since you are now using TSM the typical keep the month end stuff just
doesn't really play as TSM doesn't work like the old product did.  Trying to
implement that strategy with TSM is very costly in both time and resources
and still doesn't yield anything truly useful to the business.

It's a back to the drawing board of determining actual business requirements
before trying to implement.  It's there where additional expertise is
useful.

Kelly J. Lipp
Elbert Colorado
719-531-5574

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
ritchi64
Sent: Tuesday, June 21, 2011 11:33 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] TSM policy

Humm!
What about the policy at your site? Can you share something useful?


On 21 jun 2011, at 19:45, remco wrote:

if you have to ask these questions for such a large environment, I'd
suggest finding a real TSM specialist. Somebody who is not afraid to tell
the customer what sensible backup policies are, and what the difference
between a backup and an archive is.

 +--
 |This was sent by alainrich...@hotmail.com via Backup Central.
 |Forward SPAM to ab...@backupcentral.com.
 +--

--
Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl


On 21 jun 2011, at 17:45, ritchi64 wrote:

 hello group,

 I have to implement TSM server. The client actual policy is keep
everything for 2 months and a month copy for a year (standart) and 3 or 5
years fore some spicial request.

 What will be te best way to do that without using to much tape. TSM server
is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on
tape (to much).


+--
|This was sent by alainrich...@hotmail.com via Backup Central.
|Forward SPAM to ab...@backupcentral.com.
+--


Deduplication and Collocation

2011-06-21 Thread Mark Mooney
Hello,

I had a student ask me today What happens if you have collocation turned on 
for a storage pool that you are deduplicating?  I did not know what to answer 
because in my mind I thought well, if the data is collocated then I need to 
have a copy of that data on that client's tape, otherwise I am going to be 
mounting another client's tape to get back a de-duped piece of data which would 
negate the collocation

I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added 
client side dedup as well (which I also have questions about)

Can anyone shed some light on this?

Thanks!
Mooney



Re: Deduplication and Collocation

2011-06-21 Thread Andrew Carlson
Tape pools are not de-duped, so that is not a consideration.

On Tue, Jun 21, 2011 at 13:17, Mark Mooney mmoo...@aisconsulting.net wrote:
 Hello,

 I had a student ask me today What happens if you have collocation turned on 
 for a storage pool that you are deduplicating?  I did not know what to 
 answer because in my mind I thought well, if the data is collocated then I 
 need to have a copy of that data on that client's tape, otherwise I am going 
 to be mounting another client's tape to get back a de-duped piece of data 
 which would negate the collocation

 I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added 
 client side dedup as well (which I also have questions about)

 Can anyone shed some light on this?

 Thanks!
 Mooney





-- 
Andy Carlson
---
Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License: $8.95/month,
The feeling of seeing the red box with the item you want in it:Priceless.


Re: Deduplication and Collocation

2011-06-21 Thread Huebschman, George J.
Doesn't it undup when it goes to tape?
Or am I still living in 5.5 and thinking in VTL dedup?

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Mark Mooney
Sent: Tuesday, June 21, 2011 2:17 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Deduplication and Collocation

Hello,

I had a student ask me today What happens if you have collocation
turned on for a storage pool that you are deduplicating?  I did not
know what to answer because in my mind I thought well, if the data is
collocated then I need to have a copy of that data on that client's
tape, otherwise I am going to be mounting another client's tape to get
back a de-duped piece of data which would negate the collocation

I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they
added client side dedup as well (which I also have questions about)

Can anyone shed some light on this?

Thanks!
Mooney


IMPORTANT:  E-mail sent through the Internet is not secure. Legg Mason 
therefore recommends that you do not send any confidential or sensitive 
information to us via electronic mail, including social security numbers, 
account numbers, or personal identification numbers. Delivery, and or timely 
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends 
that you do not send time sensitive 
or action-oriented messages to us via electronic mail.

This message is intended for the addressee only and may contain privileged or 
confidential information. Unless you are the intended recipient, you may not 
use, copy or disclose to anyone any information contained in this message. If 
you have received this message in error, please notify the author by replying 
to this message and then kindly delete the message. Thank you.


Re: Deduplication and Collocation

2011-06-21 Thread Mark Mooney
So data is deduplicated in a disk storage pool but when it is written to tape 
the entire reconstructed file is written out?  Is this the same for file device 
classes?


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Andrew 
Carlson
Sent: Tuesday, June 21, 2011 8:22 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Deduplication and Collocation

Tape pools are not de-duped, so that is not a consideration.

On Tue, Jun 21, 2011 at 13:17, Mark Mooney mmoo...@aisconsulting.net wrote:
 Hello,

 I had a student ask me today What happens if you have collocation turned on 
 for a storage pool that you are deduplicating?  I did not know what to 
 answer because in my mind I thought well, if the data is collocated then I 
 need to have a copy of that data on that client's tape, otherwise I am going 
 to be mounting another client's tape to get back a de-duped piece of data 
 which would negate the collocation

 I'm looking at the redbooks for this but I only see 6.1 and in 6.2 
 they added client side dedup as well (which I also have questions 
 about)

 Can anyone shed some light on this?

 Thanks!
 Mooney





--
Andy Carlson
---
Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License: $8.95/month, The 
feeling of seeing the red box with the item you want in it:Priceless.


TSM policy

2011-06-21 Thread ritchi64
Ok then, I will add some detail to the case,

The client as a 10 years restore service level that said, he can restore 
everything that was present every night for 2 months. After that, he can 
restore only the files that were present at the first friday of the month for a 
year.

Two years ago a TSM specialist replace old backup software by TSM. he use keep 
everything for 400 days to comply with the client service level. Now we got 2 
PB of data on tape. And it's getting worse with more and more VMware machine.

Now we like to move closer to the service level ask by the client and/or slim 
the backup process weight. And yes, in some case, we use archive but it's not 
suit for every Recherche depatment who work on long time data, stop and restart 
some year after. Destroying data by mistake and not knowing for year that they 
still need it.


-Message d'origine-
De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part de Kelly 
J. Lipp
Envoyi : 21 juin 2011 13:44
@ : ADSM-L@VM.MARIST.EDU
Objet : Re: [ADSM-L] TSM policy

What Remco is saying that the discussion is much more complicated than the
simple strategy they are currently using.  If they have so much data on tape
now, keeping the same strategy will keep too much data on tape in the future
too.  So something must change.  Keeping a month end copy doesn't really
address the business requirements for archive.  A more complete conversation
that includes stake holders and compliance folks is required to narrow the
data down.

And since you are now using TSM the typical keep the month end stuff just
doesn't really play as TSM doesn't work like the old product did.  Trying to
implement that strategy with TSM is very costly in both time and resources
and still doesn't yield anything truly useful to the business.

It's a back to the drawing board of determining actual business requirements
before trying to implement.  It's there where additional expertise is
useful.

Kelly J. Lipp
Elbert Colorado
719-531-5574

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
ritchi64
Sent: Tuesday, June 21, 2011 11:33 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] TSM policy

Humm!
What about the policy at your site? Can you share something useful?


On 21 jun 2011, at 19:45, remco wrote:

if you have to ask these questions for such a large environment, I'd
suggest finding a real TSM specialist. Somebody who is not afraid to tell
the customer what sensible backup policies are, and what the difference
between a backup and an archive is.

 +--
 |This was sent by alainrich...@hotmail.com via Backup Central.
 |Forward SPAM to ab...@backupcentral.com.
 +--

--
Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl


On 21 jun 2011, at 17:45, ritchi64 wrote:

 hello group,

 I have to implement TSM server. The client actual policy is keep
everything for 2 months and a month copy for a year (standart) and 3 or 5
years fore some spicial request.

 What will be te best way to do that without using to much tape. TSM server
is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on
tape (to much).


+--
|This was sent by alainrich...@hotmail.com via Backup Central.
|Forward SPAM to ab...@backupcentral.com.
+--

+--
|This was sent by alainrich...@hotmail.com via Backup Central.
|Forward SPAM to ab...@backupcentral.com.
+--


Re: Deduplication and Collocation

2011-06-21 Thread Prather, Wanda
Dedup only works in TSM storage pools that reside on disk (specifically 
devtype=FILE pools).

If you have data that goes to a dedup pool, then gets migrated off to tape, it 
is reduped (rehydrated, reinflated, whatever you want to call it.)

So collocation will still be in effect for that pool.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark 
Mooney
Sent: Tuesday, June 21, 2011 2:17 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Deduplication and Collocation

Hello,

I had a student ask me today What happens if you have collocation turned on 
for a storage pool that you are deduplicating?  I did not know what to answer 
because in my mind I thought well, if the data is collocated then I need to 
have a copy of that data on that client's tape, otherwise I am going to be 
mounting another client's tape to get back a de-duped piece of data which would 
negate the collocation

I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added 
client side dedup as well (which I also have questions about)

Can anyone shed some light on this?

Thanks!
Mooney


Re: Deduplication and Collocation

2011-06-21 Thread Prather, Wanda
If it is a file device class with dedup turned off, yes.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark 
Mooney
Sent: Tuesday, June 21, 2011 2:29 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Deduplication and Collocation

So data is deduplicated in a disk storage pool but when it is written to tape 
the entire reconstructed file is written out?  Is this the same for file device 
classes?


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Andrew 
Carlson
Sent: Tuesday, June 21, 2011 8:22 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Deduplication and Collocation

Tape pools are not de-duped, so that is not a consideration.

On Tue, Jun 21, 2011 at 13:17, Mark Mooney mmoo...@aisconsulting.net wrote:
 Hello,

 I had a student ask me today What happens if you have collocation turned on 
 for a storage pool that you are deduplicating?  I did not know what to 
 answer because in my mind I thought well, if the data is collocated then I 
 need to have a copy of that data on that client's tape, otherwise I am going 
 to be mounting another client's tape to get back a de-duped piece of data 
 which would negate the collocation

 I'm looking at the redbooks for this but I only see 6.1 and in 6.2 
 they added client side dedup as well (which I also have questions
 about)

 Can anyone shed some light on this?

 Thanks!
 Mooney





--
Andy Carlson
---
Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License: $8.95/month, The 
feeling of seeing the red box with the item you want in it:Priceless.


Re: Deduplication and Collocation

2011-06-21 Thread Kelly J. Lipp
And that's why storage pool planning is very important.  The less re-duping,
hydrating, inflating you do the better.  Client data to a non-deduped (I
guess that would be a duped) pool that migrates to a deduped pool.  But
backup stgpool before the migration happens to avoid the re.

This is where I expect I'll be corrected: as long as the backup stg happens
before the deduplication process on the file devtype storage pool the
reduping won't have to happen. (we weren't really talking about collocated
copy pools were we?)

But then you wouldn't have a file devtype pool migrating to tape very often
anyway would you?  And if you did, that would only be in an emergency
situation (i.e., you ran out of room on disk).  And in that case why would
you collocate?

Ah, the words of someone that used to think he knew what he was talking
about!

Kelly J. Lipp
Elbert Colorado
719-531-5574


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Prather, Wanda
Sent: Tuesday, June 21, 2011 12:27 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Deduplication and Collocation

Dedup only works in TSM storage pools that reside on disk (specifically
devtype=FILE pools).

If you have data that goes to a dedup pool, then gets migrated off to tape,
it is reduped (rehydrated, reinflated, whatever you want to call it.)

So collocation will still be in effect for that pool.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Mark Mooney
Sent: Tuesday, June 21, 2011 2:17 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Deduplication and Collocation

Hello,

I had a student ask me today What happens if you have collocation turned on
for a storage pool that you are deduplicating?  I did not know what to
answer because in my mind I thought well, if the data is collocated then I
need to have a copy of that data on that client's tape, otherwise I am going
to be mounting another client's tape to get back a de-duped piece of data
which would negate the collocation

I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they
added client side dedup as well (which I also have questions about)

Can anyone shed some light on this?

Thanks!
Mooney


Re: Deduplication and Collocation

2011-06-21 Thread Mark Mooney
Cool, Thanks :)  I have questions about client dedup.  Do you know of any 
redbook detail on that?

Thanks,
Mooney

Prather, Wanda wprat...@icfi.com wrote:


Dedup only works in TSM storage pools that reside on disk (specifically 
devtype=FILE pools).

If you have data that goes to a dedup pool, then gets migrated off to tape, it 
is reduped (rehydrated, reinflated, whatever you want to call it.)

So collocation will still be in effect for that pool.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark 
Mooney
Sent: Tuesday, June 21, 2011 2:17 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Deduplication and Collocation

Hello,

I had a student ask me today What happens if you have collocation turned on 
for a storage pool that you are deduplicating?  I did not know what to answer 
because in my mind I thought well, if the data is collocated then I need to 
have a copy of that data on that client's tape, otherwise I am going to be 
mounting another client's tape to get back a de-duped piece of data which would 
negate the collocation

I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added 
client side dedup as well (which I also have questions about)

Can anyone shed some light on this?

Thanks!
Mooney



Re: Deduplication and Collocation

2011-06-21 Thread Prather, Wanda
https://www-304.ibm.com/support/docview.wss?context=SSGSG7lang=allrs=2077wv=1loc=en_UScs=UTF-8uid=swg27018576q1=tste_webcastdc=DA410

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark 
Mooney
Sent: Tuesday, June 21, 2011 2:53 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Deduplication and Collocation

Cool, Thanks :)  I have questions about client dedup.  Do you know of any 
redbook detail on that?

Thanks,
Mooney

Prather, Wanda wprat...@icfi.com wrote:


Dedup only works in TSM storage pools that reside on disk (specifically 
devtype=FILE pools).

If you have data that goes to a dedup pool, then gets migrated off to tape, it 
is reduped (rehydrated, reinflated, whatever you want to call it.)

So collocation will still be in effect for that pool.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark 
Mooney
Sent: Tuesday, June 21, 2011 2:17 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Deduplication and Collocation

Hello,

I had a student ask me today What happens if you have collocation turned on 
for a storage pool that you are deduplicating?  I did not know what to answer 
because in my mind I thought well, if the data is collocated then I need to 
have a copy of that data on that client's tape, otherwise I am going to be 
mounting another client's tape to get back a de-duped piece of data which would 
negate the collocation

I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added 
client side dedup as well (which I also have questions about)

Can anyone shed some light on this?

Thanks!
Mooney


Re: TSM policy

2011-06-21 Thread Remco Post
On 21 jun 2011, at 20:32, ritchi64 wrote:

 Ok then, I will add some detail to the case,
 
 The client as a 10 years restore service level that said, he can restore 
 everything that was present every night for 2 months. After that, he can 
 restore only the files that were present at the first friday of the month for 
 a year.
 

this is typical for customers who've never heard of TSM.

 Two years ago a TSM specialist replace old backup software by TSM. he use 
 keep everything for 400 days to comply with the client service level. Now 
 we got 2 PB of data on tape. And it's getting worse with more and more VMware 
 machine.
 

That was some lousy TSM specialist, or a typical sales job... giving the 
customer what he asks for rather than what he needs.

 Now we like to move closer to the service level ask by the client and/or slim 
 the backup process weight. And yes, in some case, we use archive but it's not 
 suit for every Recherche depatment who work on long time data, stop and 
 restart some year after. Destroying data by mistake and not knowing for year 
 that they still need it.
 

indeed, we have now some detail, but by a long stretch not enough de design a 
proper solution. There are so many variables, that I have no idea where to 
begin. You'll probably need a few weeks of TSM architect/engineer just to 
design the policies and select the right tools for the job.

 
 -Message d'origine-
 De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part de 
 Kelly J. Lipp
 Envoyi : 21 juin 2011 13:44
 @ : ADSM-L@VM.MARIST.EDU
 Objet : Re: [ADSM-L] TSM policy
 
 What Remco is saying that the discussion is much more complicated than the
 simple strategy they are currently using.  If they have so much data on tape
 now, keeping the same strategy will keep too much data on tape in the future
 too.  So something must change.  Keeping a month end copy doesn't really
 address the business requirements for archive.  A more complete conversation
 that includes stake holders and compliance folks is required to narrow the
 data down.
 
 And since you are now using TSM the typical keep the month end stuff just
 doesn't really play as TSM doesn't work like the old product did.  Trying to
 implement that strategy with TSM is very costly in both time and resources
 and still doesn't yield anything truly useful to the business.
 
 It's a back to the drawing board of determining actual business requirements
 before trying to implement.  It's there where additional expertise is
 useful.
 
 Kelly J. Lipp
 Elbert Colorado
 719-531-5574
 
 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
 ritchi64
 Sent: Tuesday, June 21, 2011 11:33 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: [ADSM-L] TSM policy
 
 Humm!
 What about the policy at your site? Can you share something useful?
 
 
 On 21 jun 2011, at 19:45, remco wrote:
 
 if you have to ask these questions for such a large environment, I'd
 suggest finding a real TSM specialist. Somebody who is not afraid to tell
 the customer what sensible backup policies are, and what the difference
 between a backup and an archive is.
 
 +--
 |This was sent by alainrich...@hotmail.com via Backup Central.
 |Forward SPAM to ab...@backupcentral.com.
 +--
 
 --
 Met vriendelijke groeten/Kind Regards,
 
 Remco Post
 r.p...@plcs.nl
 
 
 On 21 jun 2011, at 17:45, ritchi64 wrote:
 
 hello group,
 
 I have to implement TSM server. The client actual policy is keep
 everything for 2 months and a month copy for a year (standart) and 3 or 5
 years fore some spicial request.
 
 What will be te best way to do that without using to much tape. TSM server
 is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on
 tape (to much).
 
 
 +--
 |This was sent by alainrich...@hotmail.com via Backup Central.
 |Forward SPAM to ab...@backupcentral.com.
 +--
 
 +--
 |This was sent by alainrich...@hotmail.com via Backup Central.
 |Forward SPAM to ab...@backupcentral.com.
 +--

-- 
Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622


Re: TSM policy

2011-06-21 Thread Kelly J. Lipp
Makes perfect sense.  However, as you've observed, the cost is too high.
What is required now is a rationalization of the data.  Clearly (at least to
those outside the business) not all of the stuff captured in a backup may be
required in the future.  You mention VMs.  Most of what's in a VM container
isn't useful from a business standpoint.  What that means is you must start
to use the TSM archive function to parry out just the data in those VMs that
you must keep for a long time.  This is not easy!  It means actually
understanding the data itself and how it applies to the long term retention
requirements based on business needs or compliance with regulations.
Sometimes this can be done based on file types: for instance all MS Word
documents must be kept for seven years.  Sometimes it can be by server: all
of the data on this machine, except OS stuff, must be kept for five years.

There really isn't an inexpensive and efficient way to do this otherwise.
You can certainly archive everything forever, but you already know what that
costs.

There is not a simple answer to your original question.  You must step back
and take a different approach.  The reason the original approach has worked
so far is the amount of data you had up until now was reasonable.  Now the
amount is unreasonable.  The problem is simple.  The solution is not.

Sometimes having a 50 mile expert work with you to analyze the data and
teach the organization how archiving should work is the only way to get it
done.  I know that's what Remco had in mind.  He and I have worked together
for years!  Again, having that expert is difficult and it requires a
commitment on your organization's part to achieve real change.  The
definition of insanity is doing the same thing over and over and expecting
different results...

Kelly J. Lipp
Elbert Colorado
719-531-5574


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
ritchi64
Sent: Tuesday, June 21, 2011 12:32 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] TSM policy

Ok then, I will add some detail to the case,

The client as a 10 years restore service level that said, he can restore
everything that was present every night for 2 months. After that, he can
restore only the files that were present at the first friday of the month
for a year.

Two years ago a TSM specialist replace old backup software by TSM. he use
keep everything for 400 days to comply with the client service level. Now
we got 2 PB of data on tape. And it's getting worse with more and more
VMware machine.

Now we like to move closer to the service level ask by the client and/or
slim the backup process weight. And yes, in some case, we use archive but
it's not suit for every Recherche depatment who work on long time data, stop
and restart some year after. Destroying data by mistake and not knowing for
year that they still need it.


-Message d'origine-
De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part de
Kelly J. Lipp
Envoyi : 21 juin 2011 13:44
@ : ADSM-L@VM.MARIST.EDU
Objet : Re: [ADSM-L] TSM policy

What Remco is saying that the discussion is much more complicated than the
simple strategy they are currently using.  If they have so much data on tape
now, keeping the same strategy will keep too much data on tape in the future
too.  So something must change.  Keeping a month end copy doesn't really
address the business requirements for archive.  A more complete conversation
that includes stake holders and compliance folks is required to narrow the
data down.

And since you are now using TSM the typical keep the month end stuff just
doesn't really play as TSM doesn't work like the old product did.  Trying to
implement that strategy with TSM is very costly in both time and resources
and still doesn't yield anything truly useful to the business.

It's a back to the drawing board of determining actual business
requirements
before trying to implement.  It's there where additional expertise is
useful.

Kelly J. Lipp
Elbert Colorado
719-531-5574

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
ritchi64
Sent: Tuesday, June 21, 2011 11:33 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] TSM policy

Humm!
What about the policy at your site? Can you share something useful?


On 21 jun 2011, at 19:45, remco wrote:

if you have to ask these questions for such a large environment, I'd
suggest finding a real TSM specialist. Somebody who is not afraid to tell
the customer what sensible backup policies are, and what the difference
between a backup and an archive is.

 +--
 |This was sent by alainrich...@hotmail.com via Backup Central.
 |Forward SPAM to ab...@backupcentral.com.
 +--

--
Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl


On 21 jun 2011, at 17:45, ritchi64 wrote:

 

Re: Deduplication and Collocation

2011-06-21 Thread Paul Zarnowski
Even if a FILE devclass has dedup turned on, when the data is migrated, 
reclaimed, or backed up (backup stgpool) to tape, then the files are 
reconstructed from their pieces.

You cannot dedup on DISK stgpools.
DISK implies random access disk - e.g., devclass DISK.
FILE implies serial access disk - e.g., devclass FILE.

But I think there is still an open question about collocation and 
deduplication.  Deduplication must be done using FILE stgpools, but FILE 
stgpools CAN use collocation.  I don't know what happens in this case.

..Paul

At 02:38 PM 6/21/2011, Prather, Wanda wrote:
If it is a file device class with dedup turned off, yes.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark 
Mooney
Sent: Tuesday, June 21, 2011 2:29 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Deduplication and Collocation

So data is deduplicated in a disk storage pool but when it is written to tape 
the entire reconstructed file is written out?  Is this the same for file 
device classes?



--
Paul ZarnowskiPh: 607-255-4757
Manager, Storage Services Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801Em: p...@cornell.edu


Re: Deduplication and Collocation

2011-06-21 Thread Mark Mooney
Thank you Wanda!  Much Appreciated!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Prather, Wanda
Sent: Tuesday, June 21, 2011 9:09 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Deduplication and Collocation

https://www-304.ibm.com/support/docview.wss?context=SSGSG7lang=allrs=2077wv=1loc=en_UScs=UTF-8uid=swg27018576q1=tste_webcastdc=DA410

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark 
Mooney
Sent: Tuesday, June 21, 2011 2:53 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Deduplication and Collocation

Cool, Thanks :)  I have questions about client dedup.  Do you know of any 
redbook detail on that?

Thanks,
Mooney

Prather, Wanda wprat...@icfi.com wrote:


Dedup only works in TSM storage pools that reside on disk (specifically 
devtype=FILE pools).

If you have data that goes to a dedup pool, then gets migrated off to tape, it 
is reduped (rehydrated, reinflated, whatever you want to call it.)

So collocation will still be in effect for that pool.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark 
Mooney
Sent: Tuesday, June 21, 2011 2:17 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Deduplication and Collocation

Hello,

I had a student ask me today What happens if you have collocation turned on 
for a storage pool that you are deduplicating?  I did not know what to answer 
because in my mind I thought well, if the data is collocated then I need to 
have a copy of that data on that client's tape, otherwise I am going to be 
mounting another client's tape to get back a de-duped piece of data which would 
negate the collocation

I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added 
client side dedup as well (which I also have questions about)

Can anyone shed some light on this?

Thanks!
Mooney



TSM policy

2011-06-21 Thread ritchi64
Ok then remco,

1- What do you think about using two TSM instance on the same backup server. 
One for every day short term retention and an other one for the long term once 
a month.

2- Somebody suggest only one instance but use the undelete option for long term 
retention. I think it will get lot more unneeded data.



On 21 jun 2011, at 21:32, remco wrote:


On 21 jun 2011, at 20:32, ritchi64 wrote:

 Ok then, I will add some detail to the case,

 The client as a 10 years restore service level that said, he can
 restore everything that was present every night for 2 months. After
 that, he can restore only the files that were present at the first
 friday of the month for a year.


this is typical for customers who've never heard of TSM.

 Two years ago a TSM specialist replace old backup software by TSM. he
 use keep everything for 400 days to comply with the client service
 level. Now we got 2 PB of data on tape. And it's getting worse with
 more and more VMware machine.


That was some lousy TSM specialist, or a typical sales job... giving the 
customer what he asks for rather than what he needs.

 Now we like to move closer to the service level ask by the client
 and/or slim the backup process weight. And yes, in some case, we use
 archive but it's not suit for every Recherche depatment who work on
 long time data, stop and restart some year after. Destroying data by
 mistake and not knowing for year that they still need it.


indeed, we have now some detail, but by a long stretch not enough de design a 
proper solution. There are so many variables, that I have no idea where to 
begin. You'll probably need a few weeks of TSM architect/engineer just to 
design the policies and select the right tools for the job.


 -Message d'origine-
 De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part
 de Kelly J. Lipp Envoyi : 21 juin 2011 13:44 @ : ADSM-L@VM.MARIST.EDU
 Objet : Re: [ADSM-L] TSM policy

 What Remco is saying that the discussion is much more complicated
 than the
 simple strategy they are currently using.  If they have so much data
 on tape now, keeping the same strategy will keep too much data on tape
 in the future too.  So something must change.  Keeping a month end
 copy doesn't really address the business requirements for archive.  A
 more complete conversation that includes stake holders and compliance
 folks is required to narrow the data down.

 And since you are now using TSM the typical keep the month end
 stuff just
 doesn't really play as TSM doesn't work like the old product did.
 Trying to implement that strategy with TSM is very costly in both time
 and resources and still doesn't yield anything truly useful to the
 business.

 It's a back to the drawing board of determining actual business
 requirements
 before trying to implement.  It's there where additional expertise is
 useful.

 Kelly J. Lipp
 Elbert Colorado
 719-531-5574

 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf
 Of ritchi64
 Sent: Tuesday, June 21, 2011 11:33 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: [ADSM-L] TSM policy

 Humm!
 What about the policy at your site? Can you share something useful?


 On 21 jun 2011, at 19:45, remco wrote:

 if you have to ask these questions for such a large environment, I'd
 suggest finding a real TSM specialist. Somebody who is not afraid to
 tell the customer what sensible backup policies are, and what the
 difference between a backup and an archive is.

 +
 +--
 |This was sent by alainrich...@hotmail.com via Backup Central.
 |Forward SPAM to ab...@backupcentral.com.
 +
 +--

 --
 Met vriendelijke groeten/Kind Regards,

 Remco Post
 r.p...@plcs.nl


 On 21 jun 2011, at 17:45, ritchi64 wrote:

 hello group,

 I have to implement TSM server. The client actual policy is keep
 everything for 2 months and a month copy for a year (standart) and 3
 or 5 years fore some spicial request.

 What will be te best way to do that without using to much tape. TSM
 server
 is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of
 data on tape (to much).


 +-
 +-
 |This was sent by alainrich...@hotmail.com via Backup Central. Forward
 |SPAM to ab...@backupcentral.com.
 +-
 +-

 +-
 +-
 |This was sent by alainrich...@hotmail.com via Backup Central. Forward
 |SPAM to ab...@backupcentral.com.
 +-
 +-

--
Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl

+--
|This was sent by alainrich...@hotmail.com via Backup Central.
|Forward SPAM to 

Re: TSM policy

2011-06-21 Thread Remco Post
On 21 jun 2011, at 21:38, ritchi64 wrote:

 Ok then remco,
 
 1- What do you think about using two TSM instance on the same backup server. 
 One for every day short term retention and an other one for the long term 
 once a month.
 

10 days at 1250 euro/day plus expenses and you'll find out ;-) Seriously, I 
have no thoughts on this whatsoever, frankly because I only know about 1% of 
the story, which is for me just enough to tell you that I have not enough 
information to have any thoughts.


 2- Somebody suggest only one instance but use the undelete option for long 
 term retention. I think it will get lot more unneeded data.
 

If that somebody suggests that undelete is some TSM feature, I'd like to hear 
from that somebody and explain to me how that works. ;-)

 
 
 On 21 jun 2011, at 21:32, remco wrote:
 
 
 On 21 jun 2011, at 20:32, ritchi64 wrote:
 
 Ok then, I will add some detail to the case,
 
 The client as a 10 years restore service level that said, he can
 restore everything that was present every night for 2 months. After
 that, he can restore only the files that were present at the first
 friday of the month for a year.
 
 
 this is typical for customers who've never heard of TSM.
 
 Two years ago a TSM specialist replace old backup software by TSM. he
 use keep everything for 400 days to comply with the client service
 level. Now we got 2 PB of data on tape. And it's getting worse with
 more and more VMware machine.
 
 
 That was some lousy TSM specialist, or a typical sales job... giving the 
 customer what he asks for rather than what he needs.
 
 Now we like to move closer to the service level ask by the client
 and/or slim the backup process weight. And yes, in some case, we use
 archive but it's not suit for every Recherche depatment who work on
 long time data, stop and restart some year after. Destroying data by
 mistake and not knowing for year that they still need it.
 
 
 indeed, we have now some detail, but by a long stretch not enough de design a 
 proper solution. There are so many variables, that I have no idea where to 
 begin. You'll probably need a few weeks of TSM architect/engineer just to 
 design the policies and select the right tools for the job.
 
 
 -Message d'origine-
 De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part
 de Kelly J. Lipp Envoyi : 21 juin 2011 13:44 @ : ADSM-L@VM.MARIST.EDU
 Objet : Re: [ADSM-L] TSM policy
 
 What Remco is saying that the discussion is much more complicated
 than the
 simple strategy they are currently using.  If they have so much data
 on tape now, keeping the same strategy will keep too much data on tape
 in the future too.  So something must change.  Keeping a month end
 copy doesn't really address the business requirements for archive.  A
 more complete conversation that includes stake holders and compliance
 folks is required to narrow the data down.
 
 And since you are now using TSM the typical keep the month end
 stuff just
 doesn't really play as TSM doesn't work like the old product did.
 Trying to implement that strategy with TSM is very costly in both time
 and resources and still doesn't yield anything truly useful to the
 business.
 
 It's a back to the drawing board of determining actual business
 requirements
 before trying to implement.  It's there where additional expertise is
 useful.
 
 Kelly J. Lipp
 Elbert Colorado
 719-531-5574
 
 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf
 Of ritchi64
 Sent: Tuesday, June 21, 2011 11:33 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: [ADSM-L] TSM policy
 
 Humm!
 What about the policy at your site? Can you share something useful?
 
 
 On 21 jun 2011, at 19:45, remco wrote:
 
 if you have to ask these questions for such a large environment, I'd
 suggest finding a real TSM specialist. Somebody who is not afraid to
 tell the customer what sensible backup policies are, and what the
 difference between a backup and an archive is.
 
 +
 +--
 |This was sent by alainrich...@hotmail.com via Backup Central.
 |Forward SPAM to ab...@backupcentral.com.
 +
 +--
 
 --
 Met vriendelijke groeten/Kind Regards,
 
 Remco Post
 r.p...@plcs.nl
 
 
 On 21 jun 2011, at 17:45, ritchi64 wrote:
 
 hello group,
 
 I have to implement TSM server. The client actual policy is keep
 everything for 2 months and a month copy for a year (standart) and 3
 or 5 years fore some spicial request.
 
 What will be te best way to do that without using to much tape. TSM
 server
 is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of
 data on tape (to much).
 
 
 +-
 +-
 |This was sent by alainrich...@hotmail.com via Backup Central. Forward
 |SPAM to ab...@backupcentral.com.
 

Re: TSM policy

2011-06-21 Thread Prather, Wanda
 What do you think about using two TSM instance on the same backup server. 
 One for every day short term retention and an other one for the long term 
 once a month.

I have a customer who does that, because they were bought by a non-US parent 
company that REQUIREs them to keep a monthly backup forever.  It works.

-One instance does incrementals with max 60 day retention.
-The 2nd instance does an incremental, not a full, on the last weekend of every 
month.  Making the monthly an incremental is the trick to keeping the DB and 
the backup store a (sort of) reasonable size.  With the monthly incremental, 
you can still restore any client to the point in time, without actually having 
to back up all that data again.

I didn't architect that solution, and my hat is off to the person who did; it 
meets the requirements imposed on the organization.

I still don't recommend it.  The truly best solution would be to set up the 
correct type of archiving software (not TSM archiving), so that the necessary 
email and documents are saved for eons in a way that is not dependent on the 
original hostname, not dependent on the original media, and properly indexed 
and searchable (and not limited to the file name for searches). 

Trouble is, that takes commitment by the company (and a lot of work and expense 
up front) to actually implement good records management practices.  Most 
companies won't do that work in the short term, even though they would be 
better off in the long term.