On Sat, Apr 19, 2003 at 11:23:18AM -0400, Jeremy L. Mordkoff wrote:
> Right now, I lock all databases before calling amdump and unlock them
> after. However, my dumps take 6 hours and the database only takes at
> most 30 minutes. I only have one tape drive. Is there a way I can create
> my own dumper that could do the lock/dump/unlock and therefore only lock
> the db for 30 minutes? 


Depending on whether you use dump or tar, write a wrapper script around
the backup program.  It could be a fairly simple shell script, but it
will take some analysis of the command lines tar or dump are called with.
Check in your /tmp/amanda logs, the actual arguments are there.

Basic procedure, supposing tar.

Configure your amanda to use not /usr/local/bin/tar (or what ever), but
a copy specific for amanda.  I copy the real tar to /usr/local/libexec/amgtar
because that is where many of the amanda programs not intended for users to
execute from the command line reside.  Run at least one dump using the relocated
tar.  Or if your comfort level is high, proceed.

Now rename your "amgtar" to something like ".amgtar" or amgtar.real.

Write your shell script (your wrapper), calling it amgtar or whatever amanda 
expects.

The shell script should look through the arguments.  Remember I said you would 
have
to analyze the arguments amanda sends to your backup program.  You will be 
interested
in two parts, what is being backed up (call it the source) and where the 
results are
going (call it the destination).

The wrapper should then logically do:

   if (source is NOT one of my databases)
   then
        call amgtar.real with all the original arguments ( can be given as 
"${@}" ,
                                                           including the '"'s)
   else
        if (destination is /dev/null)
        then
                call amgtar.real with all the original arguments (same as above)
        else
                lock the database
                call amgtar.real as above
                save the exit status
                unlock the database
                exit saved_status
        fi
   fi


Note, the reason for the check for /dev/null is that during the estimate phases
the backup program is called and the output is discarded.  I don't think you 
will
need to lock the database during those phases.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)