If you want to prevent ADSM from using some tapes, just assign then a status of
Private
with

update libvolume libname volname status=private

ADSM will not now use this volume. You will have to keep track of what you have
written to these tapes yourselves.

On the point of archives, what you need to do is to create a new storage pool,
copygroup and management class, and then when you do am archive specify use the
ARCHMC flag on the archive. So for instance, if the management class is called
oneoff_mc, the command could be

dsmc archive archmc=oneoff_mc / /usr ....

This will make a full archive of all of the filesystems listed into the
management class oneoff_mc. If you are doing this, then the copygroup must be
of type archive. Is is possible to point the copygroup to your primary storage
pool. The fact that it is backed up to a different management class and
copygroup means that the backup will be fenced from any archives/backups to
your default management class. This will effectivly secure the archive. It is
possible to use this management class for multiple archives, provided that you
have the retention set on the copygroup to keep the number of archive copies to
what you require.

Peter Gathercole
Open System Consultant

tim hartman wrote:

> I have had the same situation as you. We only have one server being backed
> up with ADSM. Full Incremental is a nice policy for most restores but
> sometimes you want to have a complete point in time for disaster recovery.
> I tried making a copy pool. I figured I could copy the default storage pool
> to another pool and remove those tapes. The only way I could get that to
> work would be to define a disk pool and make the tape drive a copy pool.
> The we have our single server set up is to use  the tape drive as the
> default storage pool. SO, no luck there.
> Then I found tapeutil. A tape drive command utility that lets me mount
> media in my robot tape drive. I schedule a cron job to do full backups with
> two cartridges in my magstar 3570 tape drive. The only drawback to this
> setup is that ADSM may not know that these two cartridges are being used
> for this . ADSM may try to use them as scratch. I suspect that I will have
> to assign these two cartridges a separate pool to prevent accidental use.
> As you can see. ADSM is very powerful, if you do things the ADSM WAY.
> Otherwise, you have to make it up as you go along. I would be interested in
> what kind of solutions you may devise.
>
> -----Original Message-----
> From:   David E Shapiro [SMTP:shapi003 AT MC.DUKE DOT EDU]
> Sent:   Wednesday, August 12, 1998 7:14 PM
> To:     ADSM-L AT VM.MARIST DOT EDU
> Subject:        FULL BACKUPS?
>
> I need to do a full back of my servers.  I use solaris and sunos.  I know
> how to do incrementals (type incremental at the dsmc prompt, but full does
> not work.  It seems like something you should be able to do easily.  What
> am I missing?