ADSM-L

Re: Retention Request Problem

2005-07-15 12:56:39
Subject: Re: Retention Request Problem
From: "Miller, Ryan" <Miller.Ryan AT PRINCIPAL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 15 Jul 2005 11:56:27 -0500
We have had to do several 'saves' like this for similar issues, we have
used a variety solutions but it sounds like the easiest thing for you
would be to create a new domain.  The problem with this, or any other
solution, short of restoring all data prior to June 15th and then
archiving it again, is that you will have data after June 15th, this
could be a real issue with your customers legal console.  But I think
once you explain the difficulties and huge difference in admin costs,
they should come around, like ours did.

We have created the new domain like you suggested and we built one
management class, the default (named "Forever_retain"), with all 4
parameters set to 'nolimit'.  When you move a node into this domain, the
node will not be able to find ANY of it's previous defined management
classes, assuming you don't currently have a class named
"Forever_retain", and will forced to use the default and therefore not
expire any data on the node.  This of course is the easiest and
quickest, it however does create some issues, if you continue to backup
to this node, all future files will be bound to the forever retention.
I would suggest you create a new node in the current domain for
continued backups, it just means you have 2 places for possible future
restores.  

You can move this node back to the original domain once the legal issues
are resolved and if the original management classes still exist, data
will once again expire according to them. That helps a little.  Or you
can simply decide the data is obsolete and delete the whole node.

Ryan Miller
 
Principal Financial Group
 
Tivoli Certified Consultant
Tivoli Storage Manager v4.1


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Sam Sheppard
Sent: Friday, July 15, 2005 11:07 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Retention Request Problem

Our main customer is having some potential legal problems and has made
the following request:

"I am requesting that all File Server Backups taken prior to June 15,
2005 be preserved pending further instructions."

My immediate response was 'easier said than done'.  I'm not clear on
what the effect would be of changing the retention policies of retain
extra and retain only copy to 'nolimit'.  I'm assuming such a change
would affect all existing inactive copies and prevent them from rolling
off.  Or would it only affect subsequent backups?

Also, since all clients in a domain are not necessarily going to be
under this edict (I find out later this morning), could I create a new
domain with 'nolimit' policy, move the affected clients to it and expect
the new policy (same management class name) to be picked up by the
inactive files on the next backup?

I'm hoping that after today's meeting where the difficulties of
complying to this kind of 'get in your time machine and make a June 15
archive' request are made clear that I won't have the problem.  But I
can't be sure.  At minimum, I'm hoping that the scope can be limited
since we're talking over 200 clients and 4-5 TB of data.

Thanks
Sam Sheppard
San Diego Data Processing Corp.
(858)-581-9668


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to Connect AT principal DOT com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

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