Bacula-users

Re: [Bacula-users] File based backup - Large number of Volumes

2010-03-08 03:22:37
Subject: Re: [Bacula-users] File based backup - Large number of Volumes
From: Arno Lehmann <al AT its-lehmann DOT de>
To: bacula-users AT lists.sourceforge DOT net
Date: Mon, 08 Mar 2010 09:19:58 +0100
Hi Dan,

08.03.2010 00:39, Dan Langille wrote:
> On 3/7/2010 3:01 PM, Henrik Johansen wrote:
>> Hi,
>>
>> On 03/ 7/10 02:58 PM, Dan Langille wrote:
>>> I just set up a new SD for backing up to HDD.  The system can hande
>>> about 7TB of backup data.
>>>
>>> I don't see a good reason for putting all Volumes in the same directory,
>>> but I can see reasons for putting Volumes in different directories.
>>> This would require the creation of multiple Devices within the
>>> bacula-sd.conf file (one Device for each directory).
>> Your new SD uses ZFS on FreeBSD, right ? If so - why bother with
>> different directories ?
> 
> Well, sanity I suppose.  While I am a believer in letting Bacula worry 
> about Volumes, I'm now about to have 3+years of backups in one 
> directory.  I thought some structure might simplify things.

Personally, I disagree, as I use Bacula exclusively to manage disk 
volumes. I have no need to look at the filesystem(s) it uses, so I 
don't care for structure there.

> Do not take the following as proven.  It is what I've been thinking 
> about and testing with today.  I am not sure this is an ideal solution 
> at all.
> 
> But in order to achieve a hierarchy, it does complicate the 
> configuration files.  I want something like this
> 
> $ cd /zfs/bacula/volumes/
> $ ls
> alpha bravo charlie echo delta frank golf hotel india
> 
> ... where each directory listed above represents a Client.  All backups 
> for that client goes in there.
> 
> Thinking about this: it requires a Device per client, as taken from 
> bacula-sd.conf (vastly simplified to show the vital detail):
> 
> Device {
>    Name = zfs-alpha
>    Media Type = File

Use something like "Media Type = alphaFile".

>    Archive Device = /zfs/bacula/volumes/alpha
> }
> 
> Repeat the above in bacula-sd.conf, once per each Client.
> 
> We need similar things in bacula-dir.conf (once again, simplified and 
> omitting vital settings):
> 
> # Definiton of file storage device
> Storage {
>    Name       = MegaFile-alpha
>    Address    = kraken.example.org
>    Device     = zfs-alpha

Media type here, too.

> }
> 
> Then, in the job[s] for Client = alpha, you need something like this:
> 
> Job {
>    Name            = "alpha basic"
>    Client          = alpha
>    Storage         = MegaFile-alpha
> }
> 
> But to do all this, you need a Pool per client, otherwise Bacula can't 
> find them, and you'll see errors like this:
> 
> kraken-sd JobId 33438: Warning: Volume "FileAuto-0272" not on device 
> "MegaFile-beta" (/zfs/bacula/volumes/beta).
> kraken-sd JobId 33438: Marking Volume "FileAuto-0272" in Error in Catalog.
> 
> A job for Client alpha created Volume FileAuto-0272.  But it's at 
> /zfs/bacula/volumes/beta, where MegaFile-beta cannot see it.
> 
> This leads me to thinking I need a Pool per client for this scenario to 
> work properly.

A pool per client (probably even two or three, actually, for different 
retention times) would be the way to go.

Note that you could generate the client-specific configuration by 
script - use a template for the SD configuration and add in the client 
name using sed, for example. Similarly for the DIR configuration.

Then you only have to manage a number of client-specific configuration 
data files, all being passed through scripts that create the actual 
configuration data.

Cheers,

Arno

>>> How big is the disk array you're backing up to?  How do you have your
>>> Volumes arranged?
>> We have 3 SD's with 50 TB capacity per SD. All our volumes live in the
>> same ZFS filesystem(s) on those boxes.
>>
>> We store multiple jobs per volume to allow for concurrent jobs with a
>> limit on how large each volume can grow.
> 
> I allow any number of Jobs per Volume, with a maximum Volume size of 5GB.
> 


-- 
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
www.its-lehmann.de

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users