It might be a good idea to create an offsite pool. This really means
very little in terms of anything but the netbackup media catalog. If
you have a scratch pool defined, unassigned/expired media will go to
the scratch pool and your onsite and offsite pools will pull from it
as needed. It would also make your robot pull list something simple
like:

vmquery -b -pn offsite | awk '($3 !~ /NONE/) { print }'

(prints a list of media in the offsite pool that are in the robot)

Pools are really a logical thing for admin convinience and it'd
simplify things greatly to make use of them.

The only thing that would make this not quite work for you is if you
are picking and choosing which jobs to send offsite in some manner
that isn't predictable ahead of time.

-Charlie

On 4/19/05, Kevin Freels <KFreels AT askjeeves DOT com> wrote:
> Mark (and others),
> 
> Actually, I received more than a couple responses that suggested using
> "bpdbjobs -all_columns" and then parsing from that. I have written the
> first cut of a perl program that takes the output of that command and
> presents it in an abridged and formatted manner. Still a couple more
> things to do to refine it, but I think I'm on my way to what I need.
> 
> The problem with using the bpimage method is that some of the different
> policies use tapes from the same pool. I don't have specific "offsite"
> pools for tapes; the offsite tapes come from the same pools as the
> onsite tapes, but they're rotated out for 90 days. So I needed a way to
> search through the details of each full backup (as opposed to
> incremental) to determine which tapes had been used and then report that
> to me. I have been doing it manually with reading the "details" from the
> Activity Monitor, but we've added quite a few systems and policies, and
> it was quickly increasing the time required to derive which tapes to
> pull.
> 
> However, I do *really* appreciate the offer for the "breadboard" and all
> the other responses from the others on the list (you guys ROCK!). I'll
> be happy to share what I have written when I am satisfied with it, too.
> 
> ....k
> -=-=-=-
> 
> -----Original Message-----
> From: Mark.Donaldson AT cexp DOT com [mailto:Mark.Donaldson AT cexp DOT com]
> Sent: Tuesday, April 19, 2005 2:16 PM
> To: Kevin Freels; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] Email reports
> 
> I've got the feeling you're overthinking this.  I don't think you have
> to worry about the bpdbjobs output to get the media information for a
> backup.
> Especially for offsite purposes.
> 
> A typical offsite backup just writes the images to a tape that belongs
> to a volume pool intended for offsites.  After that, it's simply a
> matter of ejecting all tapes in that pool, boxing & sending.
> 
> When you talk about getting information for job/host, is it more useful
> to get info by policy & host?  If so, you might want to look at the
> "bpimagelist" command with the "-media" option.  This is an excellent
> way to identify the media associated with a particular set of clients,
> policies, etc.
> 
> SAGE: bpimagelist [-media] [-l|-L|-U|-idonly]
>            [-d mm/dd/yyyy HH:MM:SS] [-e mm/dd/yyyy HH:MM:SS] [-hoursago
> hours]
>            [-keyword "keyword phrase"]
>            [-client client_name] [-server server_name]
>            [-backupid backup_id] [-option option_name]
>            [-policy policy_name] [-pt policy_type]
>            [-rl retention_level]
>            [-sl sched_label] [-st sched_type]
> 
> If you can supply some more details, I might be able to breadboard
> something together if you get stuck.
> 
> -M
> 
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>