RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-Transfer-Encoding:
8bit
Sender:
Records Management Program <[log in to unmask]>
Subject:
From:
"McDaniel, Glenda" <[log in to unmask]>
Date:
Wed, 7 Feb 2007 13:48:45 -0600
Content-Type:
text/plain; charset="us-ascii"
MIME-Version:
1.0
Reply-To:
Records Management Program <[log in to unmask]>
Parts/Attachments:
text/plain (128 lines)
This is an excellent response.  It is important that the process be
documented in the IT Disaster Recovery Plan and referenced in your
Business Continuity Plan for Records Management.  Additionally, among
the many systems and applications that IT will be recovering during a
disaster, be sure that your systems, servers, applications, etc. are
listed with the correct Recovery Time Objectives (RTO) and Recovery
Point Objectives (RPO).

Glenda McDaniel, CPO
Director of Business Services
Oklahoma State Regents for Higher Education
655 Research Parkway, Suite 200
Oklahoma City, OK  73104
405-225-9457
405-225-9207 fax


-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On
Behalf Of Larry Medina
Sent: Wednesday, February 07, 2007 10:25 AM
To: [log in to unmask]
Subject: Re: Disaster Recovery Process Documentation

On 2/7/07, Newth, Kimberly <[log in to unmask]> wrote:
Here are some thoughts for consideration.

I have a question that relates to process documentation for disaster
> recovery.  Here's my scenario:
>
> I have finally convinced someone in my company that changing the media

> type of their records from paper to image is of benefit.  I am 
> preparing a process for the conversion and storage of the imaged 
> records in EMC Documentum.  I have permission to destroy said paper 
> records after the images have completed a QC process.  Documentum is 
> backed up incrementally every evening by IT, and there is a full 
> backup once a week.


Make sure you understand  what "backed up" means, in terms of the media
it's written to, and if it's also "mirrored" or otherwise replicated
elsewhere on-site or offsite as well.  Sometimes when IT says backed up,
they may mean something a bit different than what you're thinking in RIM
terms.

Another BIG ISSUE is where are these incremental backups stored and how
are they managed?  In the event of a catastrophic failure, if they
needed to go back to the weekly full backup 5-6 days later, you could
stand to lose a weeks worth of changes, and that could be substantial...
not only in volume, but in terms of what the content changes represent.

Backup tapes are stored offsite in a secure facility.


I think a combination of RIM and Risk Management need to make this
determination.  Does it meet the requirements of NFPA 232, 13 and 75?
Have you seen the contract in terms of services provided?  Are the
vehicles that transport the media environmentally sound to protect
against drastic changes in temperature and humidity and shock during
transport?  Is your media stored commingled with that of other firms?
How is it tracked from pickup to storage to delivery?  Is it far enough
away from your principal place of business that it wouldn't be involved
in an event that may involve your facility?  Do they know who to release
data to in the event of a disaster, and do you have multiple contact
names? Do you have a "Business Associates Agreement" in force in the
contract that ensure proper protection of your media and its content
from mishandling or exposure to others?

Depending on the types of data stored in your system (contracts,
purchase orders, other financial data,  agreements with major customers,
personnel, medical, etc.) some of the above are critical for you (or
more to the point, your organization) to know in terms of privacy
protection, compliance with HIPAA, GLBA, FISMA, SOX, and other
obligations for managing the data.

I know
> that if something bad happens and the Documentum server goes down that

> IT can restore it, but I don't know the nitty gritty details of such a

> process


You can only say you KNOW THIS if they have actually done it in an
exercise and proven they can, and how long it will take.  I can tell you
that I was personally involved in an incident with an ECM system where a
decision was made to perform this exercise on a 4 day weekend, and the
results were "eye opening" to IT.  The system was taken down at 6pm on a
Thursday and full reload and restart began 4 hours later.  At 6am on
Tuesday, they were at 84% restore...

.  Now here's my question.  Do I need to sit down with IT
> personnel & hash out an actual process for DR recovery of these 
> records should the worst happen?  Or can I rely on the fact that I 
> know IT has covered their bases with their own processes, and that is
sufficient?


Not only should any DR plans be formally recorded, they should be
periodically exercised... a minimum of once annually, and it's not a bad
idea for one of those to be unannounced.  You should find out WHO has
the responsibility for disaster response in your organization... it may
be a shared responsibility, but SOME SINGLE organization has full
responsibility.  At minimum, with respect to the Documentum system, you
should know (by position title and name) who the first, second and third
contact are for reinstating of the system in the event of a catastrophic
failure.

I would really appreciate hearing from any of you folks out  there who
> have any comments, or suggestions, thanks!


That's all I've got (for starters) =)

Larry

--
Larry Medina
Danville, CA
RIM Professional since 1972

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance

ATOM RSS1 RSS2