Congratulations on learning from your DR experience.

The short answer is no.  If it isn't in the database, you cannot rebuild the
database from tapes.

There was as discussion on the list not long ago about the 'daily
procedure', the rough cut
was similar to what we use in our daily backup script:

backup stg diskdata copypool wait=y
backup stg tapedata copypool wait=y
move drmedia * wherest=courier wait=y --- DRM
backup devconfig
backup volhist
delete volhist type=all todate=today-62
delete volhist type=db todate=today-2
backup db dev=ltoclass1 scratch=y type=full wait=y
/* The move below doesn't do anything ususally, as the tape is still
mounted, that is why it is done again after expire inventory */
move drmedia * wherestate=mo rem=bulk wait=yes --- DRM
prepare wait=yes --- DRM
update stg diskdata hi=0 lo=0
/* Expire Inventory is done to (1) expire inventory ... duh, and (2) allow a
wait tiome for the migration to pretty much complete for diskdata to go to
tapepool */
expire inventory wait=yes
update stg diskdata hi=20 lo=3 cache=y
move drmedia * wherestate=courierr wait=yes --- DRM
move drmedia * wherestate=mo rem=bulk wait=yes --- DRM
move drmedia * wherest=notmo wait=yes rem=bulk --- DRM

All the entries with " --- DRM" after them are DRM related of course.

As ususal, YMMV, but does this help a little?
And if someone else has a better method, I am all ears! ... JC
> -----Original Message-----
> From: Marcel J.E. Mol [SMTP:marcel AT MESA DOT NL]
> Sent: Saturday, March 08, 2003 8:39 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Disaster recovery test
>
> Hello list,
>
> Last week we did a disaster recovery test and as always we learned a lot.
>
> For one thing we discoverd that the last database backup was made while
> the backup to the copypool was still running. As a result some files
> were not visable in the test environment (where of coarse we ony used
> the last database backup tapes and the copypool tapes), but all data
> must be on the last copypool tapes. Of coarse we will update the
> backup schedules so this will never happen again (famous last words)
> but I'm wondering what one can do when this would happen in a real
> disaster recovery?
>
> I determined which copypool volumes were written to after the database
> backup was made and tried to do a 'audit volume' on them. But this did
> not help. From the help audit volume I'm a bit confused what happens
> during an audit volume. The FROMDATE option says that the default date
> to audit from is TODAY. But the FROMDATE cannot be given when doing an
> audit volume <volume name>. So what exactly is checked for during
> a specific volume audit?
>
> Also will the audit volume recover files on the tape that are
> not in the database, or are there other ways to do that?
>
> -Marcel
> --
>      ======--------         Marcel J.E. Mol                MESA Consulting
> B.V.
>     =======---------        ph. +31-(0)6-54724868          P.O. Box 112
>     =======---------        marcel AT mesa DOT nl                 2630 AC
> Nootdorp
> __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands
> ____
>  They couldn't think of a number,           Linux user 1148  --
> counter.li.org
>     so they gave me a name!  -- Rupert Hine  --  www.ruperthine.com