ADSM-L

Re: [ADSM-L] TSM policy

2011-06-21 15:51:55
Subject: Re: [ADSM-L] TSM policy
From: "Kelly J. Lipp" <kellyjlipp AT YAHOO DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 21 Jun 2011 12:45:53 -0600
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 AT VM.MARIST DOT EDU] On Behalf Of
ritchi64
Sent: Tuesday, June 21, 2011 12:32 PM
To: ADSM-L AT VM.MARIST DOT 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 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.
+----------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>