At 06:47 AM 5/24/96 -0500, you wrote:
>
>Frank,
>        Yes, you need to look at this in a different perspective.  For backups,
>ADSM uses version control (keep _n_ copies of a file if it's active
>regardless of how old it is - active = exists on the client as of the
>last backup) and a combination of version and retention period control
>for inactive files (files no longer on the server as of the last ADSM
>incremental backup).  If you're at all familiar with SMS on MVS, it's
>very similar to the way an SMS Management Class works (backup frequency
>/ # backups ds exists / # backups ds deleted / retain days only backup /
>retain days extra backup).  Over time, as files expire and tapes become
>partially full, these tapes are merged as part of reclamation
>processing.  One factor to consider in setting up your ADSM environment
>is whether or not to enable collocation  Enabling collocation tells ADSM
>to keep each client's data on separate tapes.  With collocation
>disabled, ADSM tries to fill each tape before writing to a new tape.
>The upside to using collocation is that each client's data is on a
>separate set of tapes which can speed up restores significantly. The
>downside to collocation - more tapes are used, more tape mounts, more
>background processing (tape reclamation).  Things to keep in mind when
>deciding this are client size, tape capacity, etc.  Also, you can use
>collocation for some clients and not for others by setting up separate
>storagepools.
>        This type of incremental backup philosophy takes some getting used to
>as it differs radically from traditional backup methodologies.  I can
>tell you from experience that we've used ADSM to do more than a few full
>client (Netware, OS/2, NT, etc.) recoveries and full file system
>recoveries (AIX, HPUX, Ultrix) over the past 2.5 years and it hasn't
>failed us yet.
>
>Tim Pittson
>tpittson AT himail.hcc DOT com
>
>>----------
>>From:  Frank Rehor[SMTP:Frank.Rehor AT CLOROX DOT COM]
>>Sent:  Thursday, May 23, 1996 8:10 PM
>>To:    Multiple recipients of list ADSM-L
>>Subject:       Incremental vs Full Backups
>>
>>We are in the process of implementing ADSM for the first time in our
>>shop
>>and I'm trying to clear up some confusion on our part re: backups.  We
>>come from a mainframe environment where we do weekly 'full' backups of
>>datasets (backup all files in the shop) and daily 'incrementals'
>>(backup
>>only files changed since the last backup).  If we need to recover our
>>system we restore the latest backup of a dataset which is, at most,
>>only a
>>week old.
>>
>>In ADSM we see only incremental backups.  Granted the first backup is
>>truly
>>a 'Full' since nothing has been backed up prior.  If a file does not
>>get
>>updated periodically it won't be backed up again.  The concern is how
>>long
>>we must keep backups to guarantee there being an available means to
>>recover
>>a file that, e.g., may be read only or updated very infrequently.
>>
>>Any feedback would be helpful.  Do we need to look at this from a
>>totally
>>different perspective than the mainframe world?
>>
>
Any clue with Collocation enables why a second tape mount during the backup
of a
file system even though the first tape was nowhere near full.  As a matter of
fact it was less than 1% full.  It was my intention to put a clients data on
separate tapes but I have backed down since I came across this problem.  At the
time I was doing this I had IBM support on the phone with me and he had no
clue as
to why.