On 01/27/11 12:09, Graham Keeling wrote:
> Now follow the thinking through. Luckily, I have already done that for you.
>
> Remember, at the start you had three obvious options:
> a) Make more volumes, reduce the max sizes.
> b) Make more volumes, keep the max sizes the same.
> c) Increase the number of jobs per volumes.
>
> You have realised that (a) and (b) are not very good.
>
> So you try (c) and increase the number of jobs per volumes.
No, that's not the answer at all. You are operating from flawed initial
assumptions.
> Your suggestion was to use either 'Maximum Volume Jobs' or 'Volume Use
> Duration'.
>
> 'Maximum Volume Jobs' initially appears to work because each volume can now
> get
> filled up to its allocated size.
"Allocated size" here is almost meaningless. You are operating from
flawed initial assumptions.
> 'Volume Use Duration' prevents the allocated space being used up, so it also
> wastes space.
"Allocated space used up" is meaningless. You are operating from flawed
initial assumptions.
> So, at this point, I am stuck.
Let's try this.
---------------------
You have a box. You have a supply of books.
How many books will fit in the box?
---------------------
The answer is not "One", "Five", "Ten", or "One hundred". It is "It
depends on the size of the box and the size of each book."
Suppose I have a 1TB disk volume, and I create a disk volume which
contains one day's worth of nightly incremental backups, and my
incrementals have 30 days retention time.
Suppose I have five clients and the total volume backed up was 8GB. I
have an 8GB volume containing 8GB of data. I have 992GB remaining on
the disk, which I can use however I like. No space has been wasted.
When these jobs expire, they will all expire at once. The volume will
be completely purged, and I can delete it, getting the entire 8GB back
all at once with no wasted space.
Suppose the next night someone on one of those clients downloads the
entirety of _Cheers_ and the next night's incremental backup is 108GB.
I get a 108GB volume containing 108GB of data. No space is wasted in
doing so. (Well, aside from it being 100GB of _Cheers_, that is.) I
now have 116GB used and 884GB available on my 1TB disk, which I can
still use *however I like*. I can divide it into as many or as few
volumes as I like. No space has been wasted. A month from today, these
jobs too will expire, and this volume will be purged, and I will get
this entire 108GB back all at once, with no wasted space.
Suppose the next day I'm testing. I do a 1GB backup of one client, to a
single volume which is then marked as used. I do this every fifteen
minutes, all day, creating 96 1GB volumes, each holding 1GB of data.
I've now created 98 volumes in all, totalling 212GB of data. Plus my
nightly backup adds one more 8GB volume; that's 99 volumes, totalling
220GB. Oh dear, I only have 780GB left. I'll have to use it all in one
volume, or it'll be wasted....
Oh, wait. No it won't. Because nothing on earth says that I'm limited
to creating 100 volumes, or any other arbitrary number of volumes,
*unless I choose to be*. Sure, I COULD only allow myself to create a
maximum of ten volumes, not to exceed 5GB each, then complain that the
remaining 950GB was wasted because I wasn't letting myself create any
more or larger volumes. But I would have nobody but myself to blame for it.
Maximum Pool Volumes is useful if you have a tape storage device *and a
finite quantity of tapes*. It is not a particularly useful directive
for managing a disk pool. Doing so is like chaining yourself to the
wall and then complaining that you can't reach the window.
Maximum Volume Size and Maximum Volume Jobs are a *little* more useful
for disk volumes. Maximum Volume Size is most useful when you're going
to copy volumes off onto fixed size removable media of some kind.
Neither one, in and of itself, is necessarily a good answer to managing
disk volumes, particularly if you unwisely decide to throw Maximum Pool
Volumes into the mix.
The best plan for managing disk volumes, IMHO, absent other constraints,
is to allow the disk to contain as many volumes as it has physical room
for, allow each volume to be whatever size it needs to be to hold the
jobs you're writing to it, and make sure that all the jobs written to
any single volume all expire at roughly the same time, so that there's
only a few hours between when jobs start to be pruned off the volume and
when the entire volume becomes available for purging and deletion. The
way to accomplish this is to use different Pools for different retention
periods (which usually maps very closely to backup levels), and limit
the time during which each volume is writable. Which brings us back to
Volume Use Duration.
Disk volumes *are not a finite quantity resource*. You're not going to
run out of slots for them. You're not going to run out of labels.
There is no reason to limit how many of them you can have, as long as
you have disk space for them.
*This* - the mistaken idea that you can inherently only have just so
many disk volumes - is the invalid initial assumption that is screwing
you up.
--
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, Free Stater
It's not the years, it's the mileage.
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
