ADSM-L

Re: How Can I reduce the OffSitePool

2001-04-12 10:25:26
Subject: Re: How Can I reduce the OffSitePool
From: "Wayne T. Smith" <ADSM AT MAINE DOT EDU>
Date: Thu, 12 Apr 2001 10:26:07 -0400
Diana posts a great question, in part reading ...
> We are having problems with our DBsize and Recovery Log size. We are in a
> disk crunch.  So I have been looking for ways to reduce the # of files that
> our DB and Recover Log file keeps track of.
>
> Our OnSitePool and our OffSite pool are almost idential in the number of
> files that are contained in them.  We use this pool for DRM.  My thought is
> that if we TRULY have a DR situation we need only provide the last ACTIVE
> files to our clients.   I do not think that we need to provide 18
> generations of data files to our company is not producing our product!
> Therefore, if I could only produce offsitepool information that contained
> the last active file it would reduce the number of tapes useds, reduce the
> # of files managed, etc. and maybe help us
>
> Anyone know if this could be done or not or have any workarounds that would
> still fit into a DRM scenario?

So the problem, as you see it, is not enough disk space for the DB
and log, and you see the DR area as a good possibility for a work-
around?

I'll venture a few comments ...

DR is for your *SM disaster, not the clients'.  Optimally, you're doing
*SM DR backups/copies so that your clients expectations of what they
have backed up is unaffected. (If you recover from a *SM disaster
with only active files, the recovery capabilities of your clients is
substantially affected!)

If all those Inactive files are really unimportant to some portion of
your clients, then providing a policy or management class with fewer
or no Inactives might save substantial disk space.

A copy of a backed up file takes up less space in the *SM DB than
the original backup.  So if you were to attack this from the copypool
side, you'll do a lot more work than if you can omit some of the
original backup objects from the *SM DB.

Create a report of filespaces and the number of days since each
has had a backup started.  You might be surprised to find substantial
very old filespaces that your clients wouldn't mind deleting.
(Remember that files of a filespace are only changed to Inactive and
allowed to expire during a backup and that *SM never backs up a
filesystem that no longer exists!)

You're really trying to solve a hardware/resource problem with a
policy change.  Unless you have both DR and non-DR stgpools, the
DR area is not probably one where you can save disk.  If you omitted
all client data DR (copypools), and that saved you 20-25% of your
*SM DB, would that give you enough time to correct the hardware
problem?  (A serious policy change such as that should be made by
someone else (no matter who you are!)).

I think you'll find better result from looking seriously at your client
data retention policies and backup selection.  Get together with a few
of your largest (*SM DB-wise) clients and see if you can meet there
needs while excluding some of their files from backup.  Realizing that
some clients will *never* restore operating system files could have
significant effect on your disk space problem. Excluding "temp" files,
wherever you might find them could have a huge effect.

(This is a question to all) Does a DB dump and load have the
potential of making more space available?

Hope this addresses your problem a little and is helpful,
wayne

Wayne T. Smith                          ADSM AT Maine DOT edu
ADSM Technical Coordinator - UNET       University of Maine System
<Prev in Thread] Current Thread [Next in Thread>