ADSM-L

Re: Space Rec. of offiste copy pools

1997-07-21 10:50:59
Subject: Re: Space Rec. of offiste copy pools
From: Tom Denier <tom AT STAFF.UDC.UPENN DOT EDU>
Date: Mon, 21 Jul 1997 10:50:59 -0400
With some workloads it is possible to reduce reclamation processing
enourmously by segregating certain files into separate storage pools.
My site's workload is a good example. We use an API client to back up
Oracle databases. These backups account for most of the workload,
from the standpoint of either number of gigabytes of data arriving each
day or number of gigabytes of data in the storage pool. These backups
consistently expire within three weeks of their creation. We also
backup a typical population of ordinary Unix files. Most of these backups
have a considerably longer lifetime than the Oracle database backups.
It turns out that nearly all of our reclamation activity results from
mixing the two types of files on the same tape. Each day ADSM writes
some tapes containing mostly database backups with a small admixture of
ordinary Unix files. About three weeks later the database backups expire
and reclamation processing is needed to move the ordinary file backups
to other volumes. If we segregated the two types of backups into separate
storage pools the Oracle database backup pool would never need
reclamation; tapes would become completely empty about three weeks after
they were written. The ordinary file pool would still need some reclamation,
but it would be relatively infrequent because of the long lifetime of a
typical Unix file backup.

With some workloads it is possible to reduce reclamation activity by
careful use of inclue/exclude files to keep useless backups of frequently
changed files from getting into the ADSM storage pools in the first
place. My site excludes a variety of files that have specialized backup
mechanisms from the ordinary file backups. These include the files
containing the contents of Oracle databases (these would be recreated
using the API client mentioned above if need be), the files containing
the ADSM database (we run BACKUP DB commands regularly), and the files
containing the disk storage pool (we run BACKUP STGPOOL commands
regularly). We also exclude files that change so often that day-old
backups aren't useful (such as the ADSM recovery log). We also exclude
some directories used for temporary work files of various types.
I have heard of sites that exclude shell history files. The usefullness
of backing us such files is debatable, and each such file changes
whenever its owner logs on. I have also heard of sites that exclude
Web browser cache files. Many Web browsers maintain a cache directory
containing copies of recently accessed files, so that they can display
them immediately if the browser user requests them again. The cost of
losing the cached files is relatively low (they can always be fetched
from a Web server again), and excluding them can prevent backups of
tens of megabytes of frequently changed files for each browser user.
<Prev in Thread] Current Thread [Next in Thread>