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