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:[EMAIL PROTECTED] > Sent: Saturday, March 08, 2003 8:39 AM > To: [EMAIL PROTECTED] > 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 > =======--------- [EMAIL PROTECTED] 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
