On Sat, Jul 18, 2009 at 6:03 AM, ict Mapper ict department<i...@mapperlithography.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@lists.sourceforge.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
