Hello James,

There are two things that "worry" me about your proposed setup are:

1. 1 Job per Volume.  If you have lots (thousands) of jobs you will have
     lots of Volumes, and today, Bacula is not really efficient about
     managing many thousands of volumes.  Why not store multiple
     jobs in a single volume?  I see little or no downside.  Yes,
     there are interleaved blocks,
     but restoring from disk is fast and unless you have really short
     restore SLAs, I see only disadvantages to 1 job per volume.

2. Over many years, I have learned that anytime you start doing
    things that are not standard or normal (especially many such as
     you propose), you increase the chances of running into bad
     problems.  Why put allocation
     units way up?  Especially with one job per volume, you will
     just waste disk, and gain little or nothing, furthermore, you
     probably will stress the OS with big memory requirements.

You don't mention it, but I recommend that you consider using Virtual 
Autochangers, either Bacula's built-in version, which I prefer or the 
Virtual Disk changer that a lot of the community prefers.  Either one 
should simplify SD Device management especially if you want to run 
multiple-simultaneous jobs, which seems to me necessary given it seems 
that you have some big backup requirements.

Whatever you decide, good luck.

Kern

On 09/02/2013 04:32 AM, James Harper wrote:
> In the past for setting up disk based backups I've used multiple physical 
> disks each with a  single sd device on them and limited each device to a 
> single job at a time, and each fd backing up to its own pool, with one device 
> per job. This minimises seeks and fragmentation etc but does mean I'm making 
> guesses about what client to back up to which disk to balance occupancy and 
> workload.
>
> I'm setting up a new server for backups now with 4 x 3TB disks and am 
> thinking about the best parameters for filesystems. I'd like for multiple 
> jobs to be able to run at once (still one volume per job) and with all the SD 
> data sitting on one giant partition on RAID5 to maximise storage use.
>
> I think I should be able to tweak the sd media filesystem to best suit this 
> and minimise fragmentation. The parameters I'm looking at are:
> . large allocation unit - maybe up to 1MB
> . high commit time to maximise the case of streaming writes. Up to 30 seconds 
> should be acceptable, provided a sync is done at the conclusion of each job
> . data in writeback mode (eg no ordering of data writes, only metadata is 
> journaled, on the basis that on a power failure the current backup is 
> considered dead anyway).
>
> Anything else I should be considering? Does any of the above sound like a 
> recipe for disaster?
>
> Thanks
>
> James
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users