ADSM-L

Re: Backup DB

1995-12-15 17:14:06
Subject: Re: Backup DB
From: Bill Colwell <BColwell AT CCLINK.DRAPER DOT COM>
Date: Fri, 15 Dec 1995 22:14:06 GMT
In <bitnet.adsm-l%ADSM-L%95121514031703 AT VM.MARIST DOT EDU>, KL2 AT cu.nih 
DOT gov (Bob Klein) writes:
>That's most unfortunate and considerably reduces the usefulness
>of doing DB incremental backups.  I don't understand what would
>be the difficulty of providing an option such NEW=YES,NO (NO
>being the default) which would allow appends of incremental
>backups.  All backup products that I am aware of allow for
>appending incremental backups onto a single tape.
>
>------------------------------------------------------------------
>Robert P. Klein                          KL2 AT CU.NIH DOT GOV
>Phone: 301-496-7400                      Fax: 301-496-6905
>Mail:  DCRT/CFB/ETS, 12A/1033, 12 SOUTH DR MSC 5607,
>       BETHESDA, MD 20892-5607
>------------------------------------------------------------------
>
>== Original Message ==
>
>> Using the VOLUMENAMES parameter allows the administrator to specify the
>> volume to which a DB backup will be written, but any previous backup
>> on this volume will be overwritten.  We do not currently provide a
>> means to append a new DB backup after an existing backup.
>>
>> Dave Cannon
>> ADSM Development

Another feature in version 2 is devicetype=file which allows the server to
dynamically allocate and write to MVS sequential disk files.  This is how I
make ADSM do its incremental DB dumps.  After the dump is complete, my console
automation product does an HSM backup and the HSM migration of the
incremental file.  Of course, HSM does uses the whole tape.  If you are using
HSM, you undoubtedly are off-siting its tapes, and have it integrated into
the disaster recovery plans, so you will have the ADSM incrementals offsite
too!

I don't think ADSM sould allow appending to a previous incremental backup file.
This operation more like DB2 than anything else I can compare it to, and
DB2 doesn't allow appends (on MVS).  It probably has something to do with
the close relationship between taking the incremental and resetting the
recovery log usage.

Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550
<Prev in Thread] Current Thread [Next in Thread>