I thought this was the cheap 'do it with tsm and'-standard, this is how i
implement TSM a lot, people don't want to pay a lot for a proper archiving
solutions and tsm archiving is a killer for storage so what we do is create
two nodes for each server (a nodename and a nodename_monthly) and do a
monthly incremental on the same TSM server.
Sure, the first backups doubles the storage but it's much better than full
archives every month, nobody has a 100% changerate on fileservers so it
saves a lot of space on tape, and with deduped filepools it's great because
the dedupe works across nodes so the bulk get's deduped with great ratio's.


On Wed, Jun 22, 2011 at 12:18 PM, Davis, Adrian <
Adrian.Davis AT lewisham.gov DOT uk> wrote:

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