On Wed, 12 Feb 2003, Donaldson, Mark wrote:

> It all depends.
>
> For one environment I run, we run 1 month retentions.  This is because the
> only need for backups is disaster recovery, not historical data retention.
> We really could get by on a lesser retention period.
>
> For another environment, with much development, there is frequently the need
> to recover code from months ago.  This is because some developer realizes
> that the version deleted months ago is the only one that really works and
> the need to abandon months of changes and revert.  For these environments, I
> have a much longer retention period.

Running off on a tangent...

Ideally, for these types of scenarios, it'd be best for the developers
to be using a proper version control system.  That way, they'd have all
the versions of their files available to them, and you'd only have to
worry about DR situations to recover the version control repository.

Of course, getting one's environment out of the habit of using their
"backup" solution as a crude version control system is sometimes a
non-trivial proposition.  I've occasionally found issues with people not
wanting to take responsibility for versioning (checking in / checking
out) their work.  Another nice thing about using a version control
system for version control is that the files are checkpointed *exactly*
when the developers choose to version them.

Other postive effects of this are that you've infinite retention for
every version of each file ever committed to the repository itself,
you've a basic audit trail for all the changes made to your files, /and/
the developers themselves can revert to older versions of the files
without involving person responsible for backups to restore the files
(or without them having to invoke backup restores themselves). What's
left as the task for the backup admin is to maintain the integrity of
the version control repository; that's a smaller headache to manage, and
one that doesn't require long retention times.

This practice also goes a long way to CYA when, inevitably, some
developer nukes an important file and fails to recognize this until
after your expiration window has passed.

-brian.