Problem solved!
Steve Ellis pointed that there was a problem with my stinit command.
As you'll all notice below (my original message/post), the first output of
stinit is identifying /dev/nst0 and /dev/nst0l as mode 0 and 1, respectively.
But this output is not correct, it's a bug in version 0.9
Tobias Brink writes:
> So I still don't know how to proceed. Apart from that I will try to
> upgrade my director and sd to 5.0.2 as soon as Debian backports are
> available and see if the problem goes away. I will also re-run the
> DiskToCatalog after my next differential backup and see if some
It's default is 0 since you do no normally do not want to limit how
much is written to the tape.
In bconsole
* llist volumes pool=yourpool
MediaId: 121
VolumeName: B004
Slot: 0
PoolId: 12
MediaType: X10
FirstWritten: 2010-03-30 09:55:0
On Wed, Sep 1, 2010 at 3:12 PM, Rodrigo Ferraz
wrote:
> Hi John. No software compression is enabled in bacula. Files are basically
> compressible files, such as MS Office, engineer drawings, images, text files,
> etc. Just a fraction of them are compressed files (.ZIP and .RAR), not more
> than
Hi John. No software compression is enabled in bacula. Files are basically
compressible files, such as MS Office, engineer drawings, images, text files,
etc. Just a fraction of them are compressed files (.ZIP and .RAR), not more
than 5%.
Regarding your second comment I guess it could be the cas
> Yes John, they are LTO-3 tapes.
>
Is your data already compressed (.zip, .bz2, .7z, .mpeg ...)? Or is
software compression enabled?
If not I am not sure. Bacula does not directly control the drive. It
relies on the OS to tell it that the tape is full. Well actually this
process is not even that
Yes John, they are LTO-3 tapes.
-Mensagem original-
De: John Drescher [mailto:dresche...@gmail.com]
Enviada em: quarta-feira, 1 de setembro de 2010 15:04
Para: Rodrigo Ferraz
Cc: Brian Debelius; bacula-users
Assunto: Re: [Bacula-users] RES: RES: LTO-3 tape not compressing data/premature
On Wed, Sep 1, 2010 at 1:49 PM, Rodrigo Ferraz
wrote:
> Hello Brian
>
> Nothing at all. The only Maximum' statements i could find in config files are
> these:
>
> [r...@br01 /etc/bacula]# grep -i maximum * | grep -v "#"
> bacula-dir.conf: Maximum Concurrent Jobs = 5
> bacula-fd.conf: Maximum Co
Hello Steve
Thanks. Tapeinfo output is on my first message (as well as other
troubleshooting info). It says 'DataCompEnabled: yes'.
Cheers,
Rodrigo
-Mensagem original-
De: Steve Ellis [mailto:el...@brouhaha.com]
Enviada em: quarta-feira, 1 de setembro de 2010 14:48
Para: bacula-users@l
Hello Brian
Nothing at all. The only Maximum' statements i could find in config files are
these:
[r...@br01 /etc/bacula]# grep -i maximum * | grep -v "#"
bacula-dir.conf: Maximum Concurrent Jobs = 5
bacula-fd.conf: Maximum Concurrent Jobs = 1
bacula-sd.conf: Maximum Concurrent Jobs = 1
bacula
On 9/1/2010 7:09 AM, Brian Debelius wrote:
>Is Maximum Volume Bytes set in the catalog for these tapes?
>
> On 9/1/2010 9:15 AM, Rodrigo Ferraz wrote:
>> Certainly. The schedule comprises 6 different tapes, between monthly and
>> weekly pools, and the problem is exactly the same with all of
On 8/25/2010 2:51 AM, Niccolo Rigacci wrote:
> On Wed, Aug 25, 2010 at 11:09:29AM +0200, Niccolo Rigacci wrote:
>>
>> I just installed Bat on Windows Server 2003, I tried both
>> win32bacula-5.0.2.exe and win32bacula-5.0.3.exe, but the result
>> is always the same: the "Jobs Run" pane remains empty
Hi All,
A quick question (hopefully) regarding bacula's choice of tapes within a
given pool. I began using bacula recently and found that some of the
time, bacula will begin writing to a tape/volume within a given pool,
before the previous (still appendable) tape is full. This isn't really
an
Is Maximum Volume Bytes set in the catalog for these tapes?
On 9/1/2010 9:15 AM, Rodrigo Ferraz wrote:
> Certainly. The schedule comprises 6 different tapes, between monthly and
> weekly pools, and the problem is exactly the same with all of them.
>
> Rodrigo
>
> -Mensagem original-
> D
Il 31/08/2010 21.00, Marco Lertora ha scritto:
Marco Lertora wrote:
Il 31/08/2010 17.27, Bill Arlofski ha scritto:
On 08/31/10 08:44, Marco Lertora wrote:
Hi!
I've the same problem! anyone found a solution?
I have 3 concurrent jobs, which backup from different fd to the sam
Certainly. The schedule comprises 6 different tapes, between monthly and weekly
pools, and the problem is exactly the same with all of them.
Rodrigo
-Mensagem original-
De: John Drescher [mailto:dresche...@gmail.com]
Enviada em: quarta-feira, 1 de setembro de 2010 10:07
Para: Rodrigo Fe
> We've been facing this problem for a while and unfortunately we are still
> unable to find an effective solution, so any help would be greatly
> appreciated.
>
> The problem: bacula is only filling LTO-3 until exactly 394.38 GB and not
> going any further a single byte. Looks like tape compres
Daniel Bareiro wrote:
> Hi, Joseph.
>
> On Thursday, 12 August 2010 20:00:29 +,
> Joseph L. Casale wrote:
>
> > I've been following this thread in hopes of uncovering the reason why
> > the op would even compile himself for a platform that has precompiled
> > binaries available (lets forgo th
Hello
We've been facing this problem for a while and unfortunately we are still
unable to find an effective solution, so any help would be greatly appreciated.
The problem: bacula is only filling LTO-3 until exactly 394.38 GB and not going
any further a single byte. Looks like tape compression
19 matches
Mail list logo
