ADSM-L

Re: ADSM Database size

2015-10-04 18:03:07
Subject: Re: ADSM Database size
From: Wayne T. Smith [SMTP:wts AT MAIL.CAPS.MAINE DOT EDU]
To: ADSM-L AT VM.MARIST DOT EDU
Richard wrote, in part..
>      We in the implementation stages of our ADSM installation on an IBM
>      RS/6000 SP with multiple vendor clients.  We have been told by an
ADSM
>      consultant, that we have to allow space for the ADSM database.  The
>      size of the ADSM database is proportional to the size of the data we
>      are backing up by 10%.  Therefore, if we have a terabyte of data, we
>      need an ADSM database the size of 100GB.
>
>      Is this true?  What is the ADSM database storing and why does it
take
>      up so much space?  Are we being told this for performance reasons,
or
>      is this a hard and fast requirement?

My tape farm has 200G and DB is less than 3G.  With an ADSM V3 server,
I might expect the DB to be smaller.

The ADSM server uses 3 sets of disk: DB, LOG and storage pools.

DB has a bunch of minor stuff, but is mostly entries for backed up
objects (files).  V3 allows for some clustering of these entries, but
recognizing 500-700 bytes per object should give you a good estimate.
Remember that a file on a client machine may have several versions on
your backup server, depending on your backup policies.

How much LOG is required is a mystery to me, but may be a function of
how many things run at once, how many objects might exist in any file
system, and how long you go between EXPIRE INVENTORY invocations.  My
LOG is currently about 400M, with peak usage of about 275M.

Of course, completely filling DB or LOG is not good, so allow plenty of
room for expansion and plan on periodically expanding because of usage.
Since a broken DB or LOG is *very*bad*, protect yourself from any
single disk failure (with RAID or ADSM mirroring).

Storage pools can also be a significant user of disk space.  In
general, backing up directly to tape is not good, either in
performance or flexability. I have 2 2.3G disk storage pools, but will
probably expand at least one of these since current daily backup and
tape reclamation (we reclaim tapes to the disk pools) fills each more
frequently than we'd like. More tape drives and a robot might mean you
could get away with smaller disk storage pool space.

We do not mirror our storage pool disk, but then we do only backups and
not archive, where a loss might be more costly.

Hope this helps,
wayne

Wayne T. Smith                            adsm AT adsm.caps.maine DOT edu
ADSM Technical Coordinator   UNET (formerly CAPS) - U Maine System
<Prev in Thread] Current Thread [Next in Thread>