Maybe another approach is to have two different nodenames configured (say, in 
separate DSM opt files) for the same node - Each registered on the TSM server 
with appropriate (long and short term) retention policies.

When you want to do a "long term" backup - run the backup specifying that you 
want to use the config file for the node with the longer retention.

Best Regards,
   =Adrian=


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
ritchi64
Sent: 21 June 2011 20:38
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] TSM policy

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 AT VM.MARIST DOT EDU] De la part
>> de Kelly J. Lipp Envoyi : 21 juin 2011 13:44 @ : ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On Behalf
> Of ritchi64
> Sent: Tuesday, June 21, 2011 11:33 AM
> To: ADSM-L AT VM.MARIST DOT 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 alainrichard AT hotmail DOT com via Backup Central.
>> |Forward SPAM to abuse AT backupcentral DOT com.
>> +--------------------------------------------------------------------
>> +--
>
> --
>> Met vriendelijke groeten/Kind Regards,
>
>> Remco Post
>> r.post AT plcs DOT 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 alainrichard AT hotmail DOT com via Backup Central. Forward
> |SPAM to abuse AT backupcentral DOT com.
> +---------------------------------------------------------------------
> +-
>
> +---------------------------------------------------------------------
> +-
> |This was sent by alainrichard AT hotmail DOT com via Backup Central. Forward
> |SPAM to abuse AT backupcentral DOT com.
> +---------------------------------------------------------------------
> +-

--
Met vriendelijke groeten/Kind Regards,

Remco Post
r.post AT plcs DOT nl

+----------------------------------------------------------------------
|This was sent by alainrichard AT hotmail DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------

DISCLAIMER

This message is confidential and intended solely for the use of the
individual or entity it is addressed to. If you have received it in
error, please contact the sender and delete the e-mail. Please note 
that we may monitor and check emails to safeguard the Council network
from viruses, hoax messages or other abuse of the Council’s systems.
To see the full version of this disclaimer please visit the following 
address: http://www.lewisham.gov.uk/AboutThisSite/EmailDisclaimer.htm

For advice and assistance about online security and protection from
internet threats visit the "Get Safe Online" website at
http://www.getsafeonline.org