ADSM-L

[ADSM-L] TSM policy

2011-06-21 14:57:43
Subject: [ADSM-L] TSM policy
From: ritchi64 <tsm-forum AT BACKUPCENTRAL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 21 Jun 2011 11:32:08 -0700
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 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.
+----------------------------------------------------------------------