ADSM-L

Re: [ADSM-L] Backup schedule syntax?

2007-11-08 09:40:21
Subject: Re: [ADSM-L] Backup schedule syntax?
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 8 Nov 2007 09:36:50 -0500
On Nov 8, 2007, at 8:41 AM, Joni Moyer wrote:

Hi Richard,

Is there a way to backup the server and keep all data for 7 years?
That
is the main goal of this.  They need their servers backed up
monthly and
they wanted a full backup for legal purposes.  I'm open to any
suggestions.  I just need something that works and keeps the files
for 7
years.

Hi, Joni -

When a department specifies a requirement to retain data for "legal
purposes", the management on your side of the equation should see a
"red flag" and perceive the need to step in to mediate
specifications, given that it's a substantial corporate issue
requiring precise (legal) definitions to be fully satisfied.  This is
to say that you as a technician should not be left in the position of
having to guess what's really needed.  If this has the potential for
serious legal action and subpoenas down the road, there could be
enormous pressure upon you as an individual if they can't get at
precisely the data they thought was being retained.  You could be
left "holding the bag" years from now - with all attendant legal
consequences - if data needed is not retrievable and you are the
responsible technologist.

Keeping all data for seven years does not necessarily mean performing
an Archive.  What needs to be done depends upon the nature of the
system and the *overall* requirements for data assurance.  If it's a
daily-use system seeing typical file churn, having conventional daily
backups as well as wanting to retain data long-term, the issue may be
more complex.  Archive would be good if it's a static system, without
files churn; otherwise my vanilla inclination would be to go for
conventional incremental with prolonged retention, to avoid multiple
copies of unchanged files.  Your organization needs to be provisioned
with whatever additional hardware (tapes, cells) and software may be
necessary to meet the needs.

I would STRONGLY recommend going over this with your management.  One
thing that really needs to be meticulously defined is what they mean
by "all data".  Does that mean just application data (the common
case); or does it mean every byte of data on the computer system
(extreme case)?  And does "all data" mean that the legal requirements
expect the capture even transient files which come and go during the
day and would not be captured by conventional overnight backups?
(Imagine litigation which results in substantial penalties for having
failed to preserve all files as required by whatever law or
imposition pertains.)  Further, the participants need to agree on the
extremities to which this data retention must be taken, as in how
many assurance copies, both onsite and offsite (to guard against
local site disaster).  Keep in mind that errors in perception by the
requiring department do not necessarily protect any downstream
department from culpability in failing to meet the legal requirement:
they may tell you that a monthly capture is what's needed, but that
may not meet the actual requirement.

The needs may call for more serious measures than originally
anticipated, such as real-time backups by IBM Tivoli Continuous Data
Protection for Files (http://www.ibm.com/software/tivoli/products/
continuous-data-protection/) or assured retention by IBM System
Storage Archive Manager
(http://www.ibm.com/software/tivoli/products/storage-mgr-data-reten/).

So, I would say to stop, and go into conference with your management,
to whatever level is commensurate with the seriousness of the
apparent requirement.  A casual recommendation from a low-level
manager who mulls it over for a minute or two is insufficient: it's a
situation which needs to be well thought out.  If you haven't seen
any specifications passed down from your company's legal department,
who should have reviewed and interpreted this for technological
satisfaction, be suspicious and ask questions.  Keep in mind that you
need to protect yourself as well as the data.  Get the requirements
in writing, and don't lose that document.  These "save the data"
requirements may sometimes be rather trivial at the outset, but then
circumstances can later develop where things become much more serious
(think Enron).

   Richard Sims  at Boston University

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