[Bacula-users] Fwd: SD : partition full => all jobs fail

[John D. <dre...@gm...>]

---------- Forwarded message ----------
From: John Drescher <dre...@gm...>
Date: Sat, Jun 9, 2012 at 7:40 PM
Subject: Re: [Bacula-users] SD : partition full => all jobs fail
To: ONeill Jack <jac...@ya...>


On Sat, Jun 9, 2012 at 8:46 AM, ONeill Jack <jac...@ya...> wrote:
> Hello,
>
> We use Bacula 5.0.1 packages on Ubuntu 10.04.
> We have a partition for each client, let's say /backup/client1 and
> /backup/client2, where volumes are stored.
> When /backup/client1 is full, Jobs for all clients are stuck "waiting for
> storage", thus a problem on client1 (backup volume file gets too big) makes
> /all/ backups for /all/ clients fail...
>
> And even if we make space available again on /backup/client1, we do have to
> restart bacula-sd service to get backups working again.
>
> So my questions are :
> - is this a bug ? a normal behaviour ?

Its expected behavior.

> - is there a way to keep Jobs for client2 working while /backup/client2 is
> full ?

Enable concurrent jobs.
>
> I had a little look at Bacula's Changelog but didn't find anything (just the
> firsts lines after 5.0.x, I didn't read all lines between 5.0.0 and 5.2.6,
> there are too many changes and descriptions are not explicit sometimes...)
> And there are too many messages in the list since 5.0.x for me to find a
> thread related to this problem.
> So sorry if this is a known problem...
>
> Regards,
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bacula-users mailing list
> Bac...@li...
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>



--
John M. Drescher


-- 
John M. Drescher