On Tue, Aug 16, 2011 at 12:39 AM, Lyn Amery <l...@gaiaresources.com.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users