Bacula-users

Re: [Bacula-users] Maximum Volume Bytes

2011-05-20 16:24:49
Subject: Re: [Bacula-users] Maximum Volume Bytes
From: Phil Stracchino <alaric AT metrocast DOT net>
To: bacula-users AT lists.sourceforge DOT net
Date: Fri, 20 May 2011 16:21:24 -0400
On 05/20/11 13:48, Mike Seda wrote:
> Hi All,
> I'm currently setting up a disk-based storage pool in Bacula and am 
> wondering what I should set "Maximum Volume Bytes" to. I was thinking of 
> setting it to "100G", but am just wondering if this is sane.

"It depends."

There are various ways to control usage of disk-based volumes.  Maximum
volume bytes is not necessarily the best one.  If you do choose to do it
that way, there are a variety of factors to take into account that can
influence your choice of volume size.  Smaller volumes waste less space
is some of the jobs in them are purged.  Larger volumes make for faster
backups because there are less volume changes.  If you ever need to copy
volumes to another medium, you pretty much need the volumes not to be
larger than the medium.

I personally find that it is more useful, rather than fixing the size of
volumes, to limit their use duration or the number of jobs they can
hold, so that rather than being arbitrary chunks of storage, a volume is
tied to a specific job or jobs, and can be freed when those jobs are
purged without hanging onto any space that is no longer in use, but
can't be recovered until the last job on the volume is purged.


> I'm also storing these file volumes on ZFS (v28 w/ dedup=on), and am 
> wondering if smaller volumes will dedup better than larger ones. I'm 
> curious to see what others are doing to take advantage of dedup-enabled 
> ZFS storage w/ Bacula.

I have not experimented with ZFS deduplication.  ZFS deduplication is
implemented at block level, so the size of the file is unlikely to make
a great deal of difference.


-- 
  Phil Stracchino, CDK#2     DoD#299792458     ICBM: 43.5607, -71.355
  alaric AT caerllewys DOT net   alaric AT metrocast DOT net   phil AT 
co.ordinate DOT org
  Renaissance Man, Unix ronin, Perl hacker, SQL wrangler, Free Stater
                 It's not the years, it's the mileage.

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users