Re: [Bacula-users] Deb packages for mariadb?

[Sven Hartge]

On 17.12.20 07:22, Daniel Rich wrote:

Does anyone know where I can find the packaging files for bacula? I 
cloned the git repo, but while it has the source for building the 
software it doesn’t have any of the packaging files (i.e. the debian 
directory and assorted files).


Since I can’t install the current binary packages without removing 
MariaDB and installing MySQL, it looks like building my own from source 
is the only way to go. And I really don’t want to have to run a manual 
install if I can build debian packages instead.




Debian provides up-to-date Bacula packages working with MariaDB via 
Buster-Backports.


The only downside of those package is they don't support S3 and the 
Docker-Plugin.


Grüße,
Sven.


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Deb packages for mariadb?

[Daniel Rich]

Does anyone know where I can find the packaging files for bacula? I cloned the 
git repo, but while it has the source for building the software it doesn’t have 
any of the packaging files (i.e. the debian directory and assorted files).

Since I can’t install the current binary packages without removing MariaDB and 
installing MySQL, it looks like building my own from source is the only way to 
go. And I really don’t want to have to run a manual install if I can build 
debian packages instead.

Dan Rich 
http://www.employees.org/~drich/
"Step up to red alert!" "Are you sure, sir?
It means changing the bulb in the sign..."
- Red Dwarf (BBC)
On Dec 9, 2020, 16:18 -0800, Daniel Rich , wrote:
> Alternatives could be used to specify what database to use, but I don’t know 
> that it can override dependencies that are hard-coded into the package spec. 
> The only solutions I know of is for either bacula-mysql to not depend on the 
> mysql packages, or to have a separate bacula-mariadb with the dependencies on 
> the MariaDB packages.
>
> I may take a stab at building my own packages this evening so I can move my 
> server over to a new box that is running Ubuntu 20.04 and MariaDB.
>
> Dan Rich 
> http://www.employees.org/~drich/
> "Step up to red alert!" "Are you sure, sir?
> It means changing the bulb in the sign..."
> - Red Dwarf (BBC)
> On Dec 9, 2020, 11:31 -0800, Phil Stracchino , wrote:
> > On 12/9/20 1:58 PM, Daniel Rich wrote:
> > > This might be a better question for bacula-devel, but are there plans to
> > > provide MariaDB packages in addition to the existing MySQL packages? The
> > > current bacula-mysql package fails to install on my Ubuntu 20.04 system
> > > with MariaDB due to the embedded mysql dependencies. I was hoping that
> > > there were some compatibility packages that would take care of this, but
> > > I haven’t been able to track any down.
> > >
> > > The following packages have unmet dependencies:
> > >  bacula-mysql : Depends: mysql-client but it is not going to be installed
> > >                 Depends: libmysqlclient20 (>= 5.7.11) but it is not
> > > installable
> >
> >
> > It seems to me like this is a problem that ought to be overcome by the
> > Debian alternatives system.
> >
> >
> >
> > --
> > Phil Stracchino
> > Babylon Communications
> > ph...@caerllewys.net
> > p...@co.ordinate.org
> > Landline: +1.603.293.8485
> > Mobile: +1.603.998.6958
> >
> >
> > ___
> > Bacula-users mailing list
> > Bacula-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bacula-users
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [BACULUM] Error 94 - Config validation error.Array ( [output] => JSON tool returned wrong exitcode

[Elias Pereira]

Thanks Marcin!!!

On Wed, Dec 16, 2020 at 9:42 PM Marcin Haba  wrote:

> Hello Elias,
>
> I am sorry. I forgot that I modified schedule files in Branch-11.0 to
> add support to the File Daemon scheduler.
>
> In attachment I am sending a valid patch adapted to 9.6.6.3. I also
> excluded PO files from it, because you use version installed from
> packages where PO files are not present.
>
> Good luck.
>
> Best regards,
> Marcin Haba (gani)
>
> On Wed, 16 Dec 2020 at 23:24, Elias Pereira  wrote:
> >
> > Hi Marcin,
> >
> > I had to change some paths of the patch because they do not match what I
> have installed.
> >
> > In the patch: gui/baculum/protected/API/Class/BaculaSetting.php
> > My installation:
> /usr/share/baculum/htdocs/protected/API/Class/BaculaSetting.php
> >
> > After change, I run with command: patch -p1 --dry-run <
> /root/bacula.patch
> >
> > Here the output,
> >
> > root@bacula:/usr/share# patch -p1 --dry-run < /root/bacula.patch
> > checking file baculum/htdocs/protected/API/Class/BaculaSetting.php
> > Hunk #1 FAILED at 327.
> > 1 out of 1 hunk FAILED
> > checking file baculum/htdocs/protected/Web/Lang/en/messages.po
> > checking file baculum/htdocs/protected/Web/Lang/ja/messages.po
> > checking file baculum/htdocs/protected/Web/Lang/pl/messages.po
> > checking file baculum/htdocs/protected/Web/Lang/pt/messages.po
> > checking file baculum/htdocs/protected/Web/Lang/ru/messages.po
> > checking file baculum/htdocs/protected/Web/Portlets/DirectiveSchedule.php
> > Hunk #1 FAILED at 516.
> > 1 out of 1 hunk FAILED
> > checking file baculum/htdocs/protected/Web/Portlets/DirectiveSchedule.tpl
> > Hunk #1 FAILED at 427.
> > 1 out of 1 hunk FAILED
> > root@bacula:/usr/share#
> >
> > Any idea?
> >
> >
> >
> > On Wed, Dec 16, 2020 at 9:56 AM Elias Pereira 
> wrote:
> >>
> >> Hello Marcin,
> >>
> >> Thanks!!!
> >>
> >> I tried to apply the patch with the command below, but without success.
> >>
> >> patch -ruN < bacula.patch
> >>
> >> On Wed, Dec 16, 2020 at 12:19 AM Marcin Haba 
> wrote:
> >>>
> >>> Hello Elias,
> >>>
> >>> Yes, of course. Here you can find the patch:
> >>>
> >>>
> https://www.bacula.org/git/cgit.cgi/bacula/patch/?id=cae80886c1871522d9dce4771a71c47ddd40d268
> >>>
> >>> It should be compatible with 9.6.6.3.
> >>>
> >>> Best regards,
> >>> Marcin Haba (gani)
> >>>
> >>> On Tue, 15 Dec 2020 at 15:08, Elias Pereira 
> wrote:
> >>> >
> >>> > Hello Marcin, thanks for the answer!!!
> >>> >
> >>> > I'm using 9.6.6.3 version.
> >>> >
> >>> > Would you have a patch to apply in this version?
> >>> >
> >>> > On Tue, Dec 15, 2020 at 1:50 AM Marcin Haba 
> wrote:
> >>> >>
> >>> >> Hello Elias,
> >>> >>
> >>> >> Thanks for reporting this problem.
> >>> >>
> >>> >> For the schedule error it is a bug that will be fixed in next
> version 11.0.
> >>> >>
> >>> >> For the screenshot, setting sun-sat range does the same as option
> 'Run
> >>> >> every day of week' does in Baculum. From this reason the interface
> >>> >> switches the 'Day of week' setting from sun-sat range to 'Run every
> >>> >> day of week' as on the screenshot.
> >>> >>
> >>> >> Best regards,
> >>> >> Marcin Haba (gani)
> >>> >>
> >>> >> On Tue, 15 Dec 2020 at 02:09, Elias Pereira 
> wrote:
> >>> >> >
> >>> >> > hello,
> >>> >> >
> >>> >> > I set up a schedule to run every hour from Sun to Sat, but it
> seems that the settings are not saved correctly. In bacula-dir.conf is as
> below:
> >>> >> >
> >>> >> > Schedule {
> >>> >> >   Name = "SC_dockerhost1-diaria"
> >>> >> >   Run = Pool="Diaria-NAS" Level="Full" Storage="FreeNAS1"
> Messages="Standard" sun-sat
> >>> >> > }
> >>> >> >
> >>> >> > Via baculum appears as in the image below. If I set the day of
> week again it saves, but if I view the schedule again, it appears again as
> in the image.
> >>> >> >
> >>> >> > img:
> >>> >> > https://ibb.co/F8hgSsv
> >>> >> >
> >>> >> > If I set up a job with this schedule, the error below occurs:
> >>> >> >
> >>> >> > Error 94 - Config validation error.Array ( [output] => JSON tool
> returned wrong exitcode. Output:bacula-dir: ERROR TERMINATION at lex.c:876
> Config error: expected a name, got T_EOL: Standard : line 463, col 78 of
> file /tmp/config_oBsVjy Run = Pool="Diaria-NAS" Level="Full"
> Storage="FreeNAS1" Messages="Standard" 14-Dec 22:04 bacula-dir: ERROR
> TERMINATION at lex.c:876 Config error: expected a name, got T_EOL: Standard
> : line 463, col 78 of file /tmp/config_oBsVjy Run = Pool="Diaria-NAS"
> Level="Full" Storage="FreeNAS1" Messages="Standard" [exitcode] => 82 )
> >>> >> >
> >>> >> >
> >>> >> > --
> >>> >> > Elias Pereira
> >>> >> > ___
> >>> >> > Bacula-users mailing list
> >>> >> > Bacula-users@lists.sourceforge.net
> >>> >> > https://lists.sourceforge.net/lists/listinfo/bacula-users
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> "Greater love hath no man than this, that a man lay down his life
> for
> >>> >> his friends." Jesus Christ
> >>> >>
> >>> >> "Większej miłości nikt nie ma 

Re: [Bacula-users] [BACULUM] Error 94 - Config validation error.Array ( [output] => JSON tool returned wrong exitcode

[Marcin Haba]

Hello Elias,

I am sorry. I forgot that I modified schedule files in Branch-11.0 to
add support to the File Daemon scheduler.

In attachment I am sending a valid patch adapted to 9.6.6.3. I also
excluded PO files from it, because you use version installed from
packages where PO files are not present.

Good luck.

Best regards,
Marcin Haba (gani)

On Wed, 16 Dec 2020 at 23:24, Elias Pereira  wrote:
>
> Hi Marcin,
>
> I had to change some paths of the patch because they do not match what I have 
> installed.
>
> In the patch: gui/baculum/protected/API/Class/BaculaSetting.php
> My installation: 
> /usr/share/baculum/htdocs/protected/API/Class/BaculaSetting.php
>
> After change, I run with command: patch -p1 --dry-run < /root/bacula.patch
>
> Here the output,
>
> root@bacula:/usr/share# patch -p1 --dry-run < /root/bacula.patch
> checking file baculum/htdocs/protected/API/Class/BaculaSetting.php
> Hunk #1 FAILED at 327.
> 1 out of 1 hunk FAILED
> checking file baculum/htdocs/protected/Web/Lang/en/messages.po
> checking file baculum/htdocs/protected/Web/Lang/ja/messages.po
> checking file baculum/htdocs/protected/Web/Lang/pl/messages.po
> checking file baculum/htdocs/protected/Web/Lang/pt/messages.po
> checking file baculum/htdocs/protected/Web/Lang/ru/messages.po
> checking file baculum/htdocs/protected/Web/Portlets/DirectiveSchedule.php
> Hunk #1 FAILED at 516.
> 1 out of 1 hunk FAILED
> checking file baculum/htdocs/protected/Web/Portlets/DirectiveSchedule.tpl
> Hunk #1 FAILED at 427.
> 1 out of 1 hunk FAILED
> root@bacula:/usr/share#
>
> Any idea?
>
>
>
> On Wed, Dec 16, 2020 at 9:56 AM Elias Pereira  wrote:
>>
>> Hello Marcin,
>>
>> Thanks!!!
>>
>> I tried to apply the patch with the command below, but without success.
>>
>> patch -ruN < bacula.patch
>>
>> On Wed, Dec 16, 2020 at 12:19 AM Marcin Haba  wrote:
>>>
>>> Hello Elias,
>>>
>>> Yes, of course. Here you can find the patch:
>>>
>>> https://www.bacula.org/git/cgit.cgi/bacula/patch/?id=cae80886c1871522d9dce4771a71c47ddd40d268
>>>
>>> It should be compatible with 9.6.6.3.
>>>
>>> Best regards,
>>> Marcin Haba (gani)
>>>
>>> On Tue, 15 Dec 2020 at 15:08, Elias Pereira  wrote:
>>> >
>>> > Hello Marcin, thanks for the answer!!!
>>> >
>>> > I'm using 9.6.6.3 version.
>>> >
>>> > Would you have a patch to apply in this version?
>>> >
>>> > On Tue, Dec 15, 2020 at 1:50 AM Marcin Haba  wrote:
>>> >>
>>> >> Hello Elias,
>>> >>
>>> >> Thanks for reporting this problem.
>>> >>
>>> >> For the schedule error it is a bug that will be fixed in next version 
>>> >> 11.0.
>>> >>
>>> >> For the screenshot, setting sun-sat range does the same as option 'Run
>>> >> every day of week' does in Baculum. From this reason the interface
>>> >> switches the 'Day of week' setting from sun-sat range to 'Run every
>>> >> day of week' as on the screenshot.
>>> >>
>>> >> Best regards,
>>> >> Marcin Haba (gani)
>>> >>
>>> >> On Tue, 15 Dec 2020 at 02:09, Elias Pereira  wrote:
>>> >> >
>>> >> > hello,
>>> >> >
>>> >> > I set up a schedule to run every hour from Sun to Sat, but it seems 
>>> >> > that the settings are not saved correctly. In bacula-dir.conf is as 
>>> >> > below:
>>> >> >
>>> >> > Schedule {
>>> >> >   Name = "SC_dockerhost1-diaria"
>>> >> >   Run = Pool="Diaria-NAS" Level="Full" Storage="FreeNAS1" 
>>> >> > Messages="Standard" sun-sat
>>> >> > }
>>> >> >
>>> >> > Via baculum appears as in the image below. If I set the day of week 
>>> >> > again it saves, but if I view the schedule again, it appears again as 
>>> >> > in the image.
>>> >> >
>>> >> > img:
>>> >> > https://ibb.co/F8hgSsv
>>> >> >
>>> >> > If I set up a job with this schedule, the error below occurs:
>>> >> >
>>> >> > Error 94 - Config validation error.Array ( [output] => JSON tool 
>>> >> > returned wrong exitcode. Output:bacula-dir: ERROR TERMINATION at 
>>> >> > lex.c:876 Config error: expected a name, got T_EOL: Standard : line 
>>> >> > 463, col 78 of file /tmp/config_oBsVjy Run = Pool="Diaria-NAS" 
>>> >> > Level="Full" Storage="FreeNAS1" Messages="Standard" 14-Dec 22:04 
>>> >> > bacula-dir: ERROR TERMINATION at lex.c:876 Config error: expected a 
>>> >> > name, got T_EOL: Standard : line 463, col 78 of file 
>>> >> > /tmp/config_oBsVjy Run = Pool="Diaria-NAS" Level="Full" 
>>> >> > Storage="FreeNAS1" Messages="Standard" [exitcode] => 82 )
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Elias Pereira
>>> >> > ___
>>> >> > Bacula-users mailing list
>>> >> > Bacula-users@lists.sourceforge.net
>>> >> > https://lists.sourceforge.net/lists/listinfo/bacula-users
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> "Greater love hath no man than this, that a man lay down his life for
>>> >> his friends." Jesus Christ
>>> >>
>>> >> "Większej miłości nikt nie ma nad tę, jak gdy kto życie swoje kładzie
>>> >> za przyjaciół swoich." Jezus Chrystus
>>> >
>>> >
>>> >
>>> > --
>>> > Elias Pereira
>>>
>>>
>>>
>>> --
>>> "Greater love hath no man than this, that a man lay down his life for
>>> 

Re: [Bacula-users] [BACULUM] Error 94 - Config validation error.Array ( [output] => JSON tool returned wrong exitcode

[Elias Pereira]

Hi Marcin,

I had to change some paths of the patch because they do not match what I
have installed.

In the patch: gui/baculum/protected/API/Class/BaculaSetting.php
My installation:
/usr/share/baculum/htdocs/protected/API/Class/BaculaSetting.php

After change, I run with command: patch -p1 --dry-run < /root/bacula.patch

Here the output,

root@bacula:/usr/share# patch -p1 --dry-run < /root/bacula.patch
checking file baculum/htdocs/protected/API/Class/BaculaSetting.php
Hunk #1 FAILED at 327.
1 out of 1 hunk FAILED
checking file baculum/htdocs/protected/Web/Lang/en/messages.po
checking file baculum/htdocs/protected/Web/Lang/ja/messages.po
checking file baculum/htdocs/protected/Web/Lang/pl/messages.po
checking file baculum/htdocs/protected/Web/Lang/pt/messages.po
checking file baculum/htdocs/protected/Web/Lang/ru/messages.po
checking file baculum/htdocs/protected/Web/Portlets/DirectiveSchedule.php
Hunk #1 FAILED at 516.
1 out of 1 hunk FAILED
checking file baculum/htdocs/protected/Web/Portlets/DirectiveSchedule.tpl
Hunk #1 FAILED at 427.
1 out of 1 hunk FAILED
root@bacula:/usr/share#

Any idea?



On Wed, Dec 16, 2020 at 9:56 AM Elias Pereira  wrote:

> Hello Marcin,
>
> Thanks!!!
>
> I tried to apply the patch with the command below, but without success.
>
> patch -ruN < bacula.patch
>
> On Wed, Dec 16, 2020 at 12:19 AM Marcin Haba  wrote:
>
>> Hello Elias,
>>
>> Yes, of course. Here you can find the patch:
>>
>>
>> https://www.bacula.org/git/cgit.cgi/bacula/patch/?id=cae80886c1871522d9dce4771a71c47ddd40d268
>>
>> It should be compatible with 9.6.6.3.
>>
>> Best regards,
>> Marcin Haba (gani)
>>
>> On Tue, 15 Dec 2020 at 15:08, Elias Pereira  wrote:
>> >
>> > Hello Marcin, thanks for the answer!!!
>> >
>> > I'm using 9.6.6.3 version.
>> >
>> > Would you have a patch to apply in this version?
>> >
>> > On Tue, Dec 15, 2020 at 1:50 AM Marcin Haba 
>> wrote:
>> >>
>> >> Hello Elias,
>> >>
>> >> Thanks for reporting this problem.
>> >>
>> >> For the schedule error it is a bug that will be fixed in next version
>> 11.0.
>> >>
>> >> For the screenshot, setting sun-sat range does the same as option 'Run
>> >> every day of week' does in Baculum. From this reason the interface
>> >> switches the 'Day of week' setting from sun-sat range to 'Run every
>> >> day of week' as on the screenshot.
>> >>
>> >> Best regards,
>> >> Marcin Haba (gani)
>> >>
>> >> On Tue, 15 Dec 2020 at 02:09, Elias Pereira 
>> wrote:
>> >> >
>> >> > hello,
>> >> >
>> >> > I set up a schedule to run every hour from Sun to Sat, but it seems
>> that the settings are not saved correctly. In bacula-dir.conf is as below:
>> >> >
>> >> > Schedule {
>> >> >   Name = "SC_dockerhost1-diaria"
>> >> >   Run = Pool="Diaria-NAS" Level="Full" Storage="FreeNAS1"
>> Messages="Standard" sun-sat
>> >> > }
>> >> >
>> >> > Via baculum appears as in the image below. If I set the day of week
>> again it saves, but if I view the schedule again, it appears again as in
>> the image.
>> >> >
>> >> > img:
>> >> > https://ibb.co/F8hgSsv
>> >> >
>> >> > If I set up a job with this schedule, the error below occurs:
>> >> >
>> >> > Error 94 - Config validation error.Array ( [output] => JSON tool
>> returned wrong exitcode. Output:bacula-dir: ERROR TERMINATION at lex.c:876
>> Config error: expected a name, got T_EOL: Standard : line 463, col 78 of
>> file /tmp/config_oBsVjy Run = Pool="Diaria-NAS" Level="Full"
>> Storage="FreeNAS1" Messages="Standard" 14-Dec 22:04 bacula-dir: ERROR
>> TERMINATION at lex.c:876 Config error: expected a name, got T_EOL: Standard
>> : line 463, col 78 of file /tmp/config_oBsVjy Run = Pool="Diaria-NAS"
>> Level="Full" Storage="FreeNAS1" Messages="Standard" [exitcode] => 82 )
>> >> >
>> >> >
>> >> > --
>> >> > Elias Pereira
>> >> > ___
>> >> > Bacula-users mailing list
>> >> > Bacula-users@lists.sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/bacula-users
>> >>
>> >>
>> >>
>> >> --
>> >> "Greater love hath no man than this, that a man lay down his life for
>> >> his friends." Jesus Christ
>> >>
>> >> "Większej miłości nikt nie ma nad tę, jak gdy kto życie swoje kładzie
>> >> za przyjaciół swoich." Jezus Chrystus
>> >
>> >
>> >
>> > --
>> > Elias Pereira
>>
>>
>>
>> --
>> "Greater love hath no man than this, that a man lay down his life for
>> his friends." Jesus Christ
>>
>> "Większej miłości nikt nie ma nad tę, jak gdy kto życie swoje kładzie
>> za przyjaciół swoich." Jezus Chrystus
>>
>
>
> --
> Elias Pereira
>


-- 
Elias Pereira
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula windows backup really slow

[Satvinder Singh]

Tried that on the latest kernel but no change. So reverted back.

 


Satvinder Singh / Operations Manager
ssi...@celerium.com / Cell: 703-989-8030

Celerium
Office: 703-418-6315
www.celerium.com 

       



On 12/16/20, 9:16 AM, "Josh Fisher"  wrote:

The message has originated from an External Source. Please use caution when 
opening attachments, clicking links, or responding to this email.

On 12/16/20 9:12 AM, Satvinder Singh wrote:
> You disabled on the bacula VM? I tried on th windows VMs but that didn’t 
help.
>
>   


Yes. On the interface used by bacula-sd.


>
>
> Satvinder Singh / Operations Manager
> ssi...@celerium.com / Cell: 703-989-8030
>
> Celerium
> Office: 703-418-6315
> 
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.celerium.com%2Fdata=04%7C01%7Cssingh%40celerium.com%7Ccd02aed71d6a4f34e71f08d8a1cd2ed4%7Cae3f7f428b694faeaf693c125dee806d%7C0%7C0%7C637437249932745509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=BjCizAwsY7XF0Eg%2BQsT%2F5i8hkbNgfQkY2FPQuE9O%2BH0%3Dreserved=0
 

>
>      
   
>
>
> On 12/16/20, 9:09 AM, "Josh Fisher"  wrote:
>
>  The message has originated from an External Source. Please use 
caution when opening attachments, clicking links, or responding to this email.
>
>  The same happened to me. I posted here on August 5 about debugging 
it. I
>  believe it to be a bug in virtio-net or in the bridge code that can 
in
>  some cases cause failures when a physical NIC (or at least igb 
driver)
>  with some combination of offloading enabled is attached to the same
>  bridge as a virtio-net device. I found that disabling generic receive
>  offload, TCP  segmentation offload, and generic segmentation offload 
on
>  the physical NIC made the problem go away.
>
>  I never found the time to experiment further to see if it was one
>  offload feature in particular or some combination that caused the 
issue.
>  In any case, the error is a rare occurrence, because I could never
>  trigger the issue with iperf, or with an incremental backup. Only a 
full
>  backup large enough to run for at least half an hour would fail. With
>  those offloading features disabled on the SD's interface I haven't 
had a
>  Bacula job failure in months.
>
>
>  On 12/16/20 8:44 AM, Satvinder Singh wrote:
>  > HI what I ended up doing was rolling back to a previous kernel 
version on Bacula VM and that resolved the issue, still trying to figure out 
what in the kernel update could have caused the issue.
>  >
>  > Thanks
>  >
>  >   
>  >
>  >
>  > Satvinder Singh / Operations Manager
>  > ssi...@celerium.com / Cell: 703-989-8030
>  >
>  > Celerium
>  > Office: 703-418-6315
>  > http://www.celerium.com/ 
>  >
>  >      
   
>  >
>  >
>  > On 12/16/20, 8:42 AM, "Josh Fisher"  wrote:
>  >
>  >  The message has originated from an External Source. Please 
use caution when opening attachments, clicking links, or responding to this 
email.
>  >
>  >  I'm late answering this, but I suggest trying again with some 
TCP
>  >  offloading features disabled on the interface used by SD.
>  >
>  >  /sbin/ethtool -K ethX tso off gso off gro off
>  >
>  >  There are indeed buggy drivers that fail to properly support 
the
>  >  (virtual?) hardware offload features, including at least some 
version(s)
>  >  of virtio-net, as I discovered and wrote about in my August 5 
2020 post
>  >  here. Keep in mind that Bacula, of necessity, taxes the 
network for long
>  >  periods of time, often for hours. It reveals network issues 
that a few
>  >  seconds or minutes of iperf cannot. (In 

Re: [Bacula-users] Bacula windows backup really slow

[Satvinder Singh]

You disabled on the bacula VM? I tried on th windows VMs but that didn’t help.

 


Satvinder Singh / Operations Manager
ssi...@celerium.com / Cell: 703-989-8030

Celerium
Office: 703-418-6315
www.celerium.com 

       



On 12/16/20, 9:09 AM, "Josh Fisher"  wrote:

The message has originated from an External Source. Please use caution when 
opening attachments, clicking links, or responding to this email.

The same happened to me. I posted here on August 5 about debugging it. I
believe it to be a bug in virtio-net or in the bridge code that can in
some cases cause failures when a physical NIC (or at least igb driver)
with some combination of offloading enabled is attached to the same
bridge as a virtio-net device. I found that disabling generic receive
offload, TCP  segmentation offload, and generic segmentation offload on
the physical NIC made the problem go away.

I never found the time to experiment further to see if it was one
offload feature in particular or some combination that caused the issue.
In any case, the error is a rare occurrence, because I could never
trigger the issue with iperf, or with an incremental backup. Only a full
backup large enough to run for at least half an hour would fail. With
those offloading features disabled on the SD's interface I haven't had a
Bacula job failure in months.


On 12/16/20 8:44 AM, Satvinder Singh wrote:
> HI what I ended up doing was rolling back to a previous kernel version on 
Bacula VM and that resolved the issue, still trying to figure out what in the 
kernel update could have caused the issue.
>
> Thanks
>
>   
>
>
> Satvinder Singh / Operations Manager
> ssi...@celerium.com / Cell: 703-989-8030
>
> Celerium
> Office: 703-418-6315
> 
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.celerium.com%2Fdata=04%7C01%7Cssingh%40celerium.com%7C72b60245b6ed4725a05608d8a1cc38a9%7Cae3f7f428b694faeaf693c125dee806d%7C0%7C0%7C637437245799143239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=mS6Km9T1Ui5vYPRU0KvULQPZph2COMUmw0mJtUcXWB4%3Dreserved=0
 

>
>      
   
>
>
> On 12/16/20, 8:42 AM, "Josh Fisher"  wrote:
>
>  The message has originated from an External Source. Please use 
caution when opening attachments, clicking links, or responding to this email.
>
>  I'm late answering this, but I suggest trying again with some TCP
>  offloading features disabled on the interface used by SD.
>
>  /sbin/ethtool -K ethX tso off gso off gro off
>
>  There are indeed buggy drivers that fail to properly support the
>  (virtual?) hardware offload features, including at least some 
version(s)
>  of virtio-net, as I discovered and wrote about in my August 5 2020 
post
>  here. Keep in mind that Bacula, of necessity, taxes the network for 
long
>  periods of time, often for hours. It reveals network issues that a 
few
>  seconds or minutes of iperf cannot. (In fact, I think virtio 
developers
>  should consider using bacula-fd in a VM in their 
destructive/performance
>  testing.)
>
>
>  On 12/8/20 2:55 PM, Satvinder Singh wrote:
>  > Hi,
>  >
>  > I have been testing out bacula for past few weeks. I have setup 
jobs for linux and windows clients (server 2016 and server 2019). The linux 
backups are running well, with almost gigabit speeds as we have a gigabit 
backbone network. But then windows backups are extremely slow averaging around 
65kbps. I have tested the network connectivity between the backup server and 
clients using iperf and there is no issue there I see speeds of over 700mbps. I 
have also tried disabling VSS and enabling Spool Data but no change. I have 
also tried the Maximum Network Buffer Size = 32768 on the client but still no 
change. There is no firewall running on the windows machine.
>  >
>  > Has anyone seen this any help is greatly appreciated.
>  >
>  > Thanks
>  > Satvinder
>  >
>  > Disclaimer: This message is intended only for the use of the 

Re: [Bacula-users] Bacula windows backup really slow

[Josh Fisher]

On 12/16/20 9:12 AM, Satvinder Singh wrote:

You disabled on the bacula VM? I tried on th windows VMs but that didn’t help.

  



Yes. On the interface used by bacula-sd.





Satvinder Singh / Operations Manager
ssi...@celerium.com / Cell: 703-989-8030

Celerium
Office: 703-418-6315
www.celerium.com 

        



On 12/16/20, 9:09 AM, "Josh Fisher"  wrote:

 The message has originated from an External Source. Please use caution 
when opening attachments, clicking links, or responding to this email.

 The same happened to me. I posted here on August 5 about debugging it. I
 believe it to be a bug in virtio-net or in the bridge code that can in
 some cases cause failures when a physical NIC (or at least igb driver)
 with some combination of offloading enabled is attached to the same
 bridge as a virtio-net device. I found that disabling generic receive
 offload, TCP  segmentation offload, and generic segmentation offload on
 the physical NIC made the problem go away.

 I never found the time to experiment further to see if it was one
 offload feature in particular or some combination that caused the issue.
 In any case, the error is a rare occurrence, because I could never
 trigger the issue with iperf, or with an incremental backup. Only a full
 backup large enough to run for at least half an hour would fail. With
 those offloading features disabled on the SD's interface I haven't had a
 Bacula job failure in months.


 On 12/16/20 8:44 AM, Satvinder Singh wrote:
 > HI what I ended up doing was rolling back to a previous kernel version 
on Bacula VM and that resolved the issue, still trying to figure out what in the 
kernel update could have caused the issue.
 >
 > Thanks
 >
 >   
 >
 >
 > Satvinder Singh / Operations Manager
 > ssi...@celerium.com / Cell: 703-989-8030
 >
 > Celerium
 > Office: 703-418-6315
 > 
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.celerium.com%2Fdata=04%7C01%7Cssingh%40celerium.com%7C72b60245b6ed4725a05608d8a1cc38a9%7Cae3f7f428b694faeaf693c125dee806d%7C0%7C0%7C637437245799143239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=mS6Km9T1Ui5vYPRU0KvULQPZph2COMUmw0mJtUcXWB4%3Dreserved=0
 

 >
 >        
 
 >
 >
 > On 12/16/20, 8:42 AM, "Josh Fisher"  wrote:
 >
 >  The message has originated from an External Source. Please use 
caution when opening attachments, clicking links, or responding to this email.
 >
 >  I'm late answering this, but I suggest trying again with some TCP
 >  offloading features disabled on the interface used by SD.
 >
 >  /sbin/ethtool -K ethX tso off gso off gro off
 >
 >  There are indeed buggy drivers that fail to properly support the
 >  (virtual?) hardware offload features, including at least some 
version(s)
 >  of virtio-net, as I discovered and wrote about in my August 5 2020 
post
 >  here. Keep in mind that Bacula, of necessity, taxes the network for 
long
 >  periods of time, often for hours. It reveals network issues that a 
few
 >  seconds or minutes of iperf cannot. (In fact, I think virtio 
developers
 >  should consider using bacula-fd in a VM in their 
destructive/performance
 >  testing.)
 >
 >
 >  On 12/8/20 2:55 PM, Satvinder Singh wrote:
 >  > Hi,
 >  >
 >  > I have been testing out bacula for past few weeks. I have setup 
jobs for linux and windows clients (server 2016 and server 2019). The linux backups 
are running well, with almost gigabit speeds as we have a gigabit backbone network. 
But then windows backups are extremely slow averaging around 65kbps. I have tested 
the network connectivity between the backup server and clients using iperf and there 
is no issue there I see speeds of over 700mbps. I have also tried disabling VSS and 
enabling Spool Data but no change. I have also tried the Maximum Network Buffer Size 
= 32768 on the client but still no change. There is no firewall running on the 
windows machine.
 >  >
 >  > Has anyone seen this any help is greatly 

Re: [Bacula-users] Bacula windows backup really slow

[Josh Fisher]

The same happened to me. I posted here on August 5 about debugging it. I 
believe it to be a bug in virtio-net or in the bridge code that can in 
some cases cause failures when a physical NIC (or at least igb driver) 
with some combination of offloading enabled is attached to the same 
bridge as a virtio-net device. I found that disabling generic receive 
offload, TCP  segmentation offload, and generic segmentation offload on 
the physical NIC made the problem go away.


I never found the time to experiment further to see if it was one 
offload feature in particular or some combination that caused the issue. 
In any case, the error is a rare occurrence, because I could never 
trigger the issue with iperf, or with an incremental backup. Only a full 
backup large enough to run for at least half an hour would fail. With 
those offloading features disabled on the SD's interface I haven't had a 
Bacula job failure in months.



On 12/16/20 8:44 AM, Satvinder Singh wrote:

HI what I ended up doing was rolling back to a previous kernel version on 
Bacula VM and that resolved the issue, still trying to figure out what in the 
kernel update could have caused the issue.

Thanks

  


Satvinder Singh / Operations Manager
ssi...@celerium.com / Cell: 703-989-8030

Celerium
Office: 703-418-6315
www.celerium.com 

        



On 12/16/20, 8:42 AM, "Josh Fisher"  wrote:

 The message has originated from an External Source. Please use caution 
when opening attachments, clicking links, or responding to this email.

 I'm late answering this, but I suggest trying again with some TCP
 offloading features disabled on the interface used by SD.

 /sbin/ethtool -K ethX tso off gso off gro off

 There are indeed buggy drivers that fail to properly support the
 (virtual?) hardware offload features, including at least some version(s)
 of virtio-net, as I discovered and wrote about in my August 5 2020 post
 here. Keep in mind that Bacula, of necessity, taxes the network for long
 periods of time, often for hours. It reveals network issues that a few
 seconds or minutes of iperf cannot. (In fact, I think virtio developers
 should consider using bacula-fd in a VM in their destructive/performance
 testing.)


 On 12/8/20 2:55 PM, Satvinder Singh wrote:
 > Hi,
 >
 > I have been testing out bacula for past few weeks. I have setup jobs for 
linux and windows clients (server 2016 and server 2019). The linux backups are 
running well, with almost gigabit speeds as we have a gigabit backbone network. 
But then windows backups are extremely slow averaging around 65kbps. I have tested 
the network connectivity between the backup server and clients using iperf and 
there is no issue there I see speeds of over 700mbps. I have also tried disabling 
VSS and enabling Spool Data but no change. I have also tried the Maximum Network 
Buffer Size = 32768 on the client but still no change. There is no firewall 
running on the windows machine.
 >
 > Has anyone seen this any help is greatly appreciated.
 >
 > Thanks
 > Satvinder
 >
 > Disclaimer: This message is intended only for the use of the individual 
or entity to which it is addressed and may contain information which is 
privileged, confidential, proprietary, or exempt from disclosure under applicable 
law. If you are not the intended recipient or the person responsible for 
delivering the message to the intended recipient, you are strictly prohibited from 
disclosing, distributing, copying, or in any way using this message. If you have 
received this communication in error, please notify the sender and destroy and 
delete any copies you may have received.
 >
 > ___
 > Bacula-users mailing list
 > Bacula-users@lists.sourceforge.net
 > 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fbacula-usersdata=04%7C01%7Cssingh%40celerium.com%7C595332eab7cc42f889b508d8a1c86337%7Cae3f7f428b694faeaf693c125dee806d%7C0%7C0%7C637437229783126282%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=e%2B0fn47BXfAsPsquHN7jtbdAOyjfNjLuZGtXrjL8ROE%3Dreserved=0

Disclaimer: This message is intended only for the use of the individual or 
entity to which it is addressed and may contain information which is 
privileged, confidential, proprietary, or exempt from disclosure under 
applicable law. If you are not the intended recipient or the person responsible 
for delivering the message to the intended recipient, you are strictly 
prohibited from disclosing, distributing, copying, or in any way using this 
message. If you have received this communication in error, please notify the 
sender and 

Re: [Bacula-users] Bacula windows backup really slow

[Satvinder Singh]

HI what I ended up doing was rolling back to a previous kernel version on 
Bacula VM and that resolved the issue, still trying to figure out what in the 
kernel update could have caused the issue.

Thanks

 


Satvinder Singh / Operations Manager
ssi...@celerium.com / Cell: 703-989-8030

Celerium
Office: 703-418-6315
www.celerium.com 

       



On 12/16/20, 8:42 AM, "Josh Fisher"  wrote:

The message has originated from an External Source. Please use caution when 
opening attachments, clicking links, or responding to this email.

I'm late answering this, but I suggest trying again with some TCP
offloading features disabled on the interface used by SD.

/sbin/ethtool -K ethX tso off gso off gro off

There are indeed buggy drivers that fail to properly support the
(virtual?) hardware offload features, including at least some version(s)
of virtio-net, as I discovered and wrote about in my August 5 2020 post
here. Keep in mind that Bacula, of necessity, taxes the network for long
periods of time, often for hours. It reveals network issues that a few
seconds or minutes of iperf cannot. (In fact, I think virtio developers
should consider using bacula-fd in a VM in their destructive/performance
testing.)


On 12/8/20 2:55 PM, Satvinder Singh wrote:
> Hi,
>
> I have been testing out bacula for past few weeks. I have setup jobs for 
linux and windows clients (server 2016 and server 2019). The linux backups are 
running well, with almost gigabit speeds as we have a gigabit backbone network. 
But then windows backups are extremely slow averaging around 65kbps. I have 
tested the network connectivity between the backup server and clients using 
iperf and there is no issue there I see speeds of over 700mbps. I have also 
tried disabling VSS and enabling Spool Data but no change. I have also tried 
the Maximum Network Buffer Size = 32768 on the client but still no change. 
There is no firewall running on the windows machine.
>
> Has anyone seen this any help is greatly appreciated.
>
> Thanks
> Satvinder
>
> Disclaimer: This message is intended only for the use of the individual 
or entity to which it is addressed and may contain information which is 
privileged, confidential, proprietary, or exempt from disclosure under 
applicable law. If you are not the intended recipient or the person responsible 
for delivering the message to the intended recipient, you are strictly 
prohibited from disclosing, distributing, copying, or in any way using this 
message. If you have received this communication in error, please notify the 
sender and destroy and delete any copies you may have received.
>
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fbacula-usersdata=04%7C01%7Cssingh%40celerium.com%7C595332eab7cc42f889b508d8a1c86337%7Cae3f7f428b694faeaf693c125dee806d%7C0%7C0%7C637437229783126282%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=e%2B0fn47BXfAsPsquHN7jtbdAOyjfNjLuZGtXrjL8ROE%3Dreserved=0

Disclaimer: This message is intended only for the use of the individual or 
entity to which it is addressed and may contain information which is 
privileged, confidential, proprietary, or exempt from disclosure under 
applicable law. If you are not the intended recipient or the person responsible 
for delivering the message to the intended recipient, you are strictly 
prohibited from disclosing, distributing, copying, or in any way using this 
message. If you have received this communication in error, please notify the 
sender and destroy and delete any copies you may have received.

___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula windows backup really slow

[Josh Fisher]

I'm late answering this, but I suggest trying again with some TCP 
offloading features disabled on the interface used by SD.


/sbin/ethtool -K ethX tso off gso off gro off

There are indeed buggy drivers that fail to properly support the 
(virtual?) hardware offload features, including at least some version(s) 
of virtio-net, as I discovered and wrote about in my August 5 2020 post 
here. Keep in mind that Bacula, of necessity, taxes the network for long 
periods of time, often for hours. It reveals network issues that a few 
seconds or minutes of iperf cannot. (In fact, I think virtio developers 
should consider using bacula-fd in a VM in their destructive/performance 
testing.)



On 12/8/20 2:55 PM, Satvinder Singh wrote:

Hi,

I have been testing out bacula for past few weeks. I have setup jobs for linux 
and windows clients (server 2016 and server 2019). The linux backups are 
running well, with almost gigabit speeds as we have a gigabit backbone network. 
But then windows backups are extremely slow averaging around 65kbps. I have 
tested the network connectivity between the backup server and clients using 
iperf and there is no issue there I see speeds of over 700mbps. I have also 
tried disabling VSS and enabling Spool Data but no change. I have also tried 
the Maximum Network Buffer Size = 32768 on the client but still no change. 
There is no firewall running on the windows machine.

Has anyone seen this any help is greatly appreciated.

Thanks
Satvinder

Disclaimer: This message is intended only for the use of the individual or 
entity to which it is addressed and may contain information which is 
privileged, confidential, proprietary, or exempt from disclosure under 
applicable law. If you are not the intended recipient or the person responsible 
for delivering the message to the intended recipient, you are strictly 
prohibited from disclosing, distributing, copying, or in any way using this 
message. If you have received this communication in error, please notify the 
sender and destroy and delete any copies you may have received.

___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users



___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [BACULUM] Error 94 - Config validation error.Array ( [output] => JSON tool returned wrong exitcode

[Elias Pereira]

Hello Marcin,

Thanks!!!

I tried to apply the patch with the command below, but without success.

patch -ruN < bacula.patch

On Wed, Dec 16, 2020 at 12:19 AM Marcin Haba  wrote:

> Hello Elias,
>
> Yes, of course. Here you can find the patch:
>
>
> https://www.bacula.org/git/cgit.cgi/bacula/patch/?id=cae80886c1871522d9dce4771a71c47ddd40d268
>
> It should be compatible with 9.6.6.3.
>
> Best regards,
> Marcin Haba (gani)
>
> On Tue, 15 Dec 2020 at 15:08, Elias Pereira  wrote:
> >
> > Hello Marcin, thanks for the answer!!!
> >
> > I'm using 9.6.6.3 version.
> >
> > Would you have a patch to apply in this version?
> >
> > On Tue, Dec 15, 2020 at 1:50 AM Marcin Haba  wrote:
> >>
> >> Hello Elias,
> >>
> >> Thanks for reporting this problem.
> >>
> >> For the schedule error it is a bug that will be fixed in next version
> 11.0.
> >>
> >> For the screenshot, setting sun-sat range does the same as option 'Run
> >> every day of week' does in Baculum. From this reason the interface
> >> switches the 'Day of week' setting from sun-sat range to 'Run every
> >> day of week' as on the screenshot.
> >>
> >> Best regards,
> >> Marcin Haba (gani)
> >>
> >> On Tue, 15 Dec 2020 at 02:09, Elias Pereira  wrote:
> >> >
> >> > hello,
> >> >
> >> > I set up a schedule to run every hour from Sun to Sat, but it seems
> that the settings are not saved correctly. In bacula-dir.conf is as below:
> >> >
> >> > Schedule {
> >> >   Name = "SC_dockerhost1-diaria"
> >> >   Run = Pool="Diaria-NAS" Level="Full" Storage="FreeNAS1"
> Messages="Standard" sun-sat
> >> > }
> >> >
> >> > Via baculum appears as in the image below. If I set the day of week
> again it saves, but if I view the schedule again, it appears again as in
> the image.
> >> >
> >> > img:
> >> > https://ibb.co/F8hgSsv
> >> >
> >> > If I set up a job with this schedule, the error below occurs:
> >> >
> >> > Error 94 - Config validation error.Array ( [output] => JSON tool
> returned wrong exitcode. Output:bacula-dir: ERROR TERMINATION at lex.c:876
> Config error: expected a name, got T_EOL: Standard : line 463, col 78 of
> file /tmp/config_oBsVjy Run = Pool="Diaria-NAS" Level="Full"
> Storage="FreeNAS1" Messages="Standard" 14-Dec 22:04 bacula-dir: ERROR
> TERMINATION at lex.c:876 Config error: expected a name, got T_EOL: Standard
> : line 463, col 78 of file /tmp/config_oBsVjy Run = Pool="Diaria-NAS"
> Level="Full" Storage="FreeNAS1" Messages="Standard" [exitcode] => 82 )
> >> >
> >> >
> >> > --
> >> > Elias Pereira
> >> > ___
> >> > Bacula-users mailing list
> >> > Bacula-users@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/bacula-users
> >>
> >>
> >>
> >> --
> >> "Greater love hath no man than this, that a man lay down his life for
> >> his friends." Jesus Christ
> >>
> >> "Większej miłości nikt nie ma nad tę, jak gdy kto życie swoje kładzie
> >> za przyjaciół swoich." Jezus Chrystus
> >
> >
> >
> > --
> > Elias Pereira
>
>
>
> --
> "Greater love hath no man than this, that a man lay down his life for
> his friends." Jesus Christ
>
> "Większej miłości nikt nie ma nad tę, jak gdy kto życie swoje kładzie
> za przyjaciół swoich." Jezus Chrystus
>


-- 
Elias Pereira
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users