[Wlug] bacula

[John Stoffel]

Mike> Thanks a bunch.  I had found this out 5 minutes after my first
Mike> email, but your examples will come in handy i'm sure!

No problem.  Bacula is good, the manual is excellent for what it is,
but the config files are Baroque... Kern's style I guess. 

Mike> i have a 35/70Gb DLT drive with IV tapes, but I am only getting
Mike> less than 30 gigs' per tape.

How is the tape drive hooked up to the system, and how fast is the
system you're running on?  Can you share some details on a completed
job maybe?  

Mike> my bacula-sd.conf lists " Media Type = DLT"....if this is not
Mike> accurate, could bacula think I have only a 15/30Gb drive?
Mike> Should it read DTL7000 or something?

Nah, doesn't really matter.  

Mike> Also, does bacula compress naturally or do i have to tell it too?

I'm not aware of Bacula compressing data from the client when sending
it to the tape drive unless you explicitly enable it.  And it's
generally not worth doing.  

The key thing with DLT is to push data to the drive at a high enough
rate to keep it from shoe-shining.  That both wears down the drive,
and kills performance/storage capacity.  Since the native speed is
5MB/s, you really really really wnat to be able to push 10MB/s to the
drive to let it compress the data well.  Unfortunately, that can be
hard to do, esp if you have lots of small files to backup.  

Also, check your dmesg output to see how the drive is detected and at
what speed it's running. 

When you put a tape into the drive, does the compression light come on
as well?  

There's a known limitation (performance bottleneck actually) where
Bacula uses transactions for inserting records into the DB one at a
time.  If they could insert more records at a time, performance would
go up since the transaction overhead would be amortized across more
INSERTS.

Also, which DB are you using?  And which version of Bacula?  The
newest released version I think (and I'd have to check) now uses
sqlite3 as the default DB, which has a big performance loss compared
to older 1.36.x versions which defaulted to sqlite which had better
performance.

Now one of the things I did to speed up my backups was to put my DB
onto another host, since my tape drive and data were all one one
system, so adding mysql updates ontop of that really just brought it
down to it's knees.  

Anyway, more data on your backups and how well they currently run
would be good.  

On my system, I get around 24gb to 68gb per tape, so it's certainly
possible to get more data on there, esp since I'm using a dual CPU
Xeon 550mhz box to do my backups.  Old and not very fast.

John