On Tue, Aug 16, 2011 at 12:39 AM, Lyn Amery <lyn AT gaiaresources.com DOT au>
wrote:
>
> Hi all,
>
> I'm just getting started with Bacula and wondering about the best strategy
> for setting up file storage naming. Is there a best practice, perhaps,
> or do people have suggestions?
>
> I have about 15 systems to back up to about 8 TB of disk. I know
> that I could create a single volume - labelled say, BIG - or I
> could go to the other extreme and have a a daily volume for each
> system, e.g. ServerA_Monday, ServerB_Tuesday. I was thinking of either
> one for each system (ServerA, ServerB, etc) or by using "Use Volume Once",
> having something like ServerA001, ServerA002, ServerB001, etc. My only
> reasoning for this is to try and keep things simple. Is there any
> advantage to having lots of small files as compared to a few large ones?
>
> Thanks for any feedback.
>
> Cheers,
> Lyn
I'm becoming a big fan of using vchanger to provide a virtual tape
library. I was originally using vchanger to make it easier to manage
storage on USB drives for offsite rotations, but I'm actually going to
start configuring my normal backups to use it too. Basically, I set a
maximum volume size and maximum number of volumes in the pool. For
instance, if I have a tape library of 100 volumes at 5GB each, then I
know I will never exceed 500GB of storage. Of course, you choose
volume sizes appropriate to your needs. In your case, with 8TB of
backup storage, you might want to consider something like one hundred
and sixty 50GB or eighty 100GB volumes. There is always overhead in
Bacula for switching from one volume to the other. If you don't have
a need for a small file size, then you can reduce the total amount of
this overhead by increasing volume size. Make vchanger aware of the
max volume count and have it initialize the pre-set number of volumes
which later get labeled in bconsole using 'label barcodes'.
All normal backup jobs point to the same pool and I don't have to
worry about volume naming at all since restores will query the
database anyway. The command line tools to restore without database
still work on these volumes in a pinch. These become easier to work
with if all of the data you're looking to restore is in a single
volume It's another good reason for large volume sizes in this
configuration.
I set volume retention short but job and file retention long. This
allows Bacula to automatically recycle the oldest volume when it runs
out of space without purging the jobs or files until the oldest volume
is actually recycled. If you want to hold onto your data for at least
a month and make Bacula prompt you when it can't do that given the
pool's capacity, you can set your volume retention to 1 month. That
keeps Bacula from overwriting the oldest data too soon. This all
amounts to Bacula automatically giving you maximum retention period
for the disk space that you have while honoring a minimum retention
period as determined by your company's IT policies.
This makes the system work a lot more like a tape-based backup system
where the tapes have real capacity limits and you don't care about the
names of the tapes. It really is a decent and cheap software
implementation of a VTL.
Now if I could just get some hardware accelerated compression between
Bacula and these files, I would be in heaven. Perhaps someone will
write a routine to allow Bacula to offload compression to a GPU. Just
a wish list item for anyone out there who's looking for something
unnecessary (but very cool) to code up . . .
Eric
------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
