Another thing you can do, if you data base is small, is to send your backups
to a devclass of FILE on disk; just make sure it is NOT the same physical
disk as your data base, or you haven't accomplished anything!  It even works
for triggered backups; for devclass FILE, ADSM just creates a DB backup name
for you when it creates the output file to a "scratch" volume.

I have done this and set up the devclass so the output with to a networked
drive that was physically attached to another NT server, but mapped as a
drive to my ADSM server.  (You have to dink around with NT permissions, but
it works.)

That saved me tape handling, and also got the ADSM DB backup off the ADSM
server machine to another location for DR purposes.

Just an idea...

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************





> -----Original Message-----
> From: Nick Cassimatis [SMTP:nickpc AT US.IBM DOT COM]
> Sent: Wednesday, January 05, 2000 10:37 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: dbbackups on the same volume
>
> If you REALLY want to do this (remember, the ADSM Developers designed ADSM
> to not work this way), you can backup your ADSM Database to a file on a
> cartridge (I know this works with an OS/2 controller, I'd assume it would
> work the same with an NT machine).
>
> backup db type=full devt=file vol=F:\cartridgename1a\dbbackupfull.dbb
> backup db type=incr devt=file vol=F:\cartridgename1a\dbbackupincr1.dbb
>
> 'F:' being the drive the jukebox appears as from the NT machine
> 'cartridgename1' begin the cartridge name, 'a' begin side A  (This depends
> on how you format your media)
>
> This will not work with triggered backups, as they need to go to scratch
> volumes.  Also, you definately want each full backup to go to a new
> cartridge, so automating this gets rather difficult, unless you want to
> create schedules for 2-3 weeks worth of database backups.
>
> Again, really consiter all the implications of having a weeks (or however
> many days) worth of database backups on one cartridge.  You may decide the
> ability to recover your server to the latest possible date may be worth
> "wasting" a few cartridges.
>
> Nick Cassimatis
> nickpc AT us.ibm DOT com
>
> If you don't have the time to do it right the first time, where will you
> find the time to do it again?