I'm a little late to the party, but...
Since our company works for state government agencies and has data in 18
states, we've had to keep a few factors in mind.
1. Period of time that we can be sued after contract expires - In some
states (kansas for example) a business entity can be sued for up to 5 years
past the expiration date on a contract. Local regulations very widely on a
state-by-state basis.
2. Errors and Ommisions Insurance requirements - Since we're a publicly
traded company, there are some types of data we need to keep for a specific
period of time (evidence of security breach/forensic data, etc) as
stipulated by our insurance carrier.
3. Because we also perform financial transactions, we keep this data up to 5
years, as specified by the legal department. The financial transactional
data is backed up daily, and duplicated to tape(s) which are moved offsite
every two months, then rotated pulled from rotation and moved to archive
status.
4. Our company document retention policy is very strict on how long emails
can be kept. Email data is kept for 2 months. This is a legal issue as any
company can be subopenaed for /ALL/ documentation, emails, and data by a
court UNLESS the company has a document retention policy and can point to it
and say "We cannot provide data that is older than NNN months due to this
internal policy."
My only suggestion would be to check local laws and regulations and make
sure that your within the guidelines set there, and to make sure that your
backups follow whatever internal policies (driven by SOX, HIPAA, or whatever
your company deals with) and size the backup retention levels accordingly.
It takes awhile to come up with policies that fit within the guidelines,
makes all business units happy and does't kill your yearly IT budget with
tape cartridges! :)
HTH,
-Jeff
On 1/13/05 8:36 PM, "Eric Ljungblad" <Eric.Ljungblad AT CopleyPress DOT com>
wrote:
> Our company also backs up the same type of data:
> Exchange email backups are only held for 30days for legal reasons unknown to
> myself.
>
> SQL, on NT, Lawson / HP UNIX / Oracle on HP
>
> All others go like this:
>
> Exchange = 30 days
>
> NT-Daily = 30 days
> NT-Weekly = 3 Months
> NT-Monthly = 1 year
> NT-Yearly = 7 years or Infinity
>
> HP-Daily = 30 days
> HP-Weekly = 3 Months
> HP-Monthly = 1 year
> HP-Yearly = Inifinity 30 + years
>
> I setup a separate media pool and schedules for each of these -
> Barcodes somewhat match these schedules, that makes it simple to
> Separate what tapes have what data on them
>
> NTD100 - NTD201
> NTW100 - NTW201
> NTM100 - NTY201
> NTY100 - NTY201
> HPD100 - HPD201
> HPW100 - HPW201
> HPM100 - HPM201
> HPY100 - HPY201
> EXC100 - EXC201
>
>
>
>
>
>
> Eric Ljungblad
> Computer Operator
> Copley Information Services
> Eric.Ljungblad AT copleypress DOT com
> (858) 729-8010
>
> -----Original Message-----
> From: Dave Markham [mailto:dave.markham AT fjserv DOT net]
> Sent: Wednesday, January 12, 2005 6:49 AM
> To: Hindle, Greg
> Cc: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] Backup retention Standards?
>
> Hindle, Greg wrote:
>
>> Hello,
>> I am in the process of re-evaluating our companies backup retention
>> policies. I wanted to get feedback from others who use Netbackup as to
>> what they use in their own environments. What I need to know is how
>> frequently you backup certain files and how long do you keep them
>> before expiring those backups? We have mixture of applications and
>> platforms here so any insight to what your setup is would be great. In
>> particular SQL, ORACLE, EXCHANGE, Financial Applications, user data,
>> Peoplesoft applications, Windows servers, Unix servers etc.
>>
>> Thanks in advance,
>> Greg
>>
>>
>>
>>
>>>>> The information contained in this e-mail transmission is
>> privileged and/or confidential intended solely for the exclusive use
>> of the individual addressee. If you are not the intended addressee you
>> are hereby notified that any retention, disclosure or other use is
>> strictly prohibited. If you have received this notification in error,
>> please immediately contact the sender and delete the material.
>
> I have various customers and sometimes the requirements differ but i try
> and keep a best practice. I mostly deal with solaris so will explain
> what i do
>
> I have a policy for OS files, one for application and one for databases
> which each contain the same schedule information but different file and
> client lists for the application and database policies.
>
> I keep cumulative incremental backups for 1 week and normally leave
> those tapes in the jukebox unless they get full ( monitored via a script )
> Weekly full backups are removed and stored in a fireproof safe and
> retained for 4 weeks in netbackup
> Monthly full backups run every 4 weeks and expire in 3 months. Again
> removed after running
> Quarterly backups are run every 3 months and kept for 1 year. Again
> removed after running
> Yearly backups are run every year and retained for 5 years. Again
> removed after running.
>
> This may be excessive but seems to work quite well.
>
> In addition to above i do the following
>
> Have a log_archive policy which is a user_archive and i run a cron job
> on each machine to find log locations of type file only and issue a
> bparchive withe the list. These i keep for 7 years or infinity depending
> on setup. The logs are archived and so removed after use.
>
> I also have a DR ( disaster recovery ) policy which various from
> customer to customer. The latest one i have done is an InlineTapeCopy of
> the each schedule. I have this taken offsite daily as its written to a
> different tape pool. I retain these for 2 weeks before they return to
> site and into the scratch pool.
>
> hope this helps
> Thanks
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
|
