On Sat, Jul 18, 2009 at 6:03 AM, ict Mapper ict
department<ict AT mapperlithography DOT com> wrote:
> Bacula version: (26 July 2008) x86_64-pc-linux-gnu debian 4.0
> backup unit/changer: HP storageworks MSL2024 LTO3
>
> Hello,
>
> We have a real weird problem. Tapes are not fully written. But this is not in 
> all cases. The problem seems to concentrate around our monthly backups.
> When the tapes are labelled (by barcode) and being put in the "monthly" pool 
> and written to, the tapes  are only filled up for not even 300 GB sometimes.
> Sometimes not even more then slightly over 200GB and the next tape is loaded. 
> A too less amount anyway. While running backups of the same files (both
> full backups) (only in this case the weekly backup) the tapes are filled up 
> easily for like 500 GB, sometimes even more then 600.
>
> What is tried until now:
>
> - labelling the tapes and putting them in the weekly pool first.
>  later changing them over to the monthly pool and setting the
>  retention period to that of a month again. -> No help...
>
> - labelling the tapes and putting them in the weekly pool first.
>  later changing them over to the monthly pool but leaving the
>  retention period of the tapes alone until the backup finished.
>  -> No help...
>
> - Changing weekly tapes that was written to in normal amounts
>  earlier during the weekly backup with tapes that have only
>  ever been used for the weekly backup -> that helped...
>
> So we can deduct that the problem does not lie in the retention period. The 
> problem does not have to do with (not on it's own) in which pool the tapes are
> placed directly after labelling. However, if the tapes written to from the 
> weekly full backup jobs are later used for the monthly jobs then it works 
> fine.
>
> We backup multiple servers to one big set of tapes + a mysql dump of the 
> bacula catalog db and mark the last used tape: used.
> The configuration is done per server (in separate files) where a: backup job 
> is mentioned, a restore job is mentioned, the fileset
> is mentioned and a mention of the schedule directive which looks in another 
> file. In this other file is determined: to which pool
> should written, if a full or incremental job should be written and at which 
> moment jobs start.
>
> The baculadir.conf file points to the server specific files. Also to files 
> holding the pool definitions.
>
> If there is any part of the configuration that is interesting, let me know 
> and i will send it.
>
>
> I hope someone has an idea what could be causing this problem.
>

http://www.mail-archive.com/bacula-users AT lists.sourceforge DOT 
net/msg36461.html

That looked like a hardware problem to me. Did you try filling a tape
with tar or dd?

Other than that are there any errors in your bacula logs for these jobs?

-- 
John M. Drescher

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users