What values are people using for bumpsize, bumdays, bumpmult other than
the example values?
I don't think this applies to you, but the only place I've changed the
bump* parameters was on a system that had a dumpcycle 10 days (i.e.
so I would not run out of level numbers) and I wanted to bump to the
next level every day:
bumpsize 500 Mb
bumpdays 0
bumpmult 1
It's been a while since I set this up (I don't even know if it's in use
any more), so the parameters may not be right.
I have a lot of 10 GB disks to back up and it doesn't seem efficient
to me to do eg. an 11 GB "level 5" backup of a disk that has 13 GB of
data on it--In that situation, I think it would probably make more sense
to just do a level 0 backup. ...
Agreed. I have a TODO note to see about making planner decide that if it
asks for the next incremental and that size is within X (a percentage?
an absolute size?) of the full dump size, it might as well (attempt to)
do the full (it may need to demote later if the tape would be too full,
for instance).
Or something like that (still needs some thought).
On the other hand, I don't want to create
a situation where disks 4 GB get a full dump every time. ...
Assuming the partial is significanly less than 4 GB. If it's close
to 4 GB anyway, you're better off doing the full because it's faster
(less work for dump to decide what to do) and makes the restore easier
(less levels to go through).
It would be
nice if bumpsize could be expressed as a % of the disk size rather than
an absolute amount of space.
Do you mean % of the full dump size?
Will going to the next level fix your problem? In other words, if the
11 GB incremental you mentioned above were at level N, would doing a
level N+1 be a solution?
The quick (which doesn't necessarily mean good :-) way to do this might
be to let negative bumpsize values be treated as a percentage. It looks
like it would be pretty easy to change bump_thresh() in planner.c to
take the level 0 size as a new parameter and change the two calls to
pass that information.
The one thing that won't work with this is "amadmin config bump",
which needs a real size to work with. Of course, we might change it to
take an optional "level 0 size" parameter if you're using percentages
and then it would be happy. Hmmm ...
Another (possibly independent) change would be to put the bump* controls
in the dumptype ala dumpcycle (dumptype used if present, else the
global value). Then you could tune this on a disk by disk basis.
On the other hand, as I think about this more, the bump* parameters are
really more related to tape than to backup sizes. In which case, we're
really talking about two things here. The bump* parameters are trying
to save tape. What you (and I) want is something to save restore time
(and some dump time) by controlling the incremental level.
Maybe this is what the STRATEGY API is supposed to address?
H ...
"Jonathan F. Dill" ([EMAIL PROTECTED])
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
