On Thu, Jul 05, 2007 at 10:35:21AM -0400, Chris Hoogendyk wrote:
> The one thing that is annoying is that on /var/mail an incremental is
> essentially the same as a full. Those mail files (one per account) are
> just like a database file -- add or remove one message and you have to
> back up the whole file. It would be interesting to write a wrapper to do
> incremental mail dumps sort of like the sql database programs that do
> incremental dumps. I wonder if there would be any demand for such a
> thing. It could get a little messy, and would probably require the
> Application API. In our case, we have about 1200 accounts/files. It
> would require reading headers and doing proper locking so as not to
> collide with the mail programs.

Yes, I think there would be demand for that (there are a lot of
application-specific things that could use better backups).  And yes, it
will be a lot easier after the Application API is in place :)

> I'm guessing that for those changers where it's all tied up in one scsi
> address, and/or where there are multiple drives in a library, it might
> be desirable to have changer handle it. Then my case becomes the special
> case -- the changer is set up in sgen.conf and has a scsi device
> address, and the tape drive is set up in st.conf and is /dev/rmt/1 -- so
> the changer does not know how the drive got set up. This special case
> might require the changer to look somewhere else, e.g. amanda.conf, to
> find out. But, then, couldn't it also tell somehow if there had been an
> override? Or does that get too messy?

That's basically the answer -- the current changer interface has no
provision for passing along overrides, and adding one would potentially
break a lot of custom changer scripts.  You've hit the nail on the head
as to why changers provide devices to Amanda, rather than leaving her to
use tapedev.

> Ok, maybe we just need to document that when someone overrides tapedev
> they should also override tpchanger if they have one.

See the attached patch.

Dustin

-- 
        Dustin J. Mitchell
        Storage Software Engineer, Zmanda, Inc.
        http://www.zmanda.com/

sf-2227-r1.patch
Description: amanda.8.patch