Always Incremental consolidations include jobs that are not incremental.

[Matt Ivie]

I am running Bareos 16.2.5 under Debian 10 (Buster) and have configured
normal Full, Diff, Inc backups for all of my clients to run on a local
storage daemon. I have configured a remote (within network, but
different building) storage daemon and created Always Incremental jobs
to be stored on that SD. The problem I'm having is that when the
consolidate job runs, one client keeps having all backups from all jobs
included. I can't seem to find a reason why all of the additional
backups are being selected, but they are.

I checked the jobs and they are not always incremental jobs and I've
explicitly set Always Incremental = no on those jobs.

What can I do to verify why the logic of the consolidate job is picking
up these extra jobs?

--
"Under the sky, under the heavens there is but one family."
--Bruce Lee

[Matt Ivie]

I could be running up against a bug I'm unaware of or I could be mis-
understanding the way that Always Incremental backups work. When a
consolidate job runs it is grabbing ALL backups for a client whether
the jobs they are associated with are "Always Incremental" jobs or not.

Does anyone know anything about this or have any experience with this
problem?

If I simply need to define a new client to match my "Always
Incremental" jobs then that's what I'll do. It just seemed logical that
the consolidate job would leave backups alone if they weren't part of
the "Always Incremental" backups for a client.

Thanks in advance.

[Brock Palen]

In my experense incremental will pull in every job related to that client.

I actually use this as a failsafe. I have a VirtualFull job that I set to an Archive job.

When I have had media failures, or other (cough) self induced wounds, I set the archive job back to backup and run a new virtual full.
I have also used this behavior to migrate systems from traditional backup to always incremental.

I think that’s just how it works currently. I think there is probably a way to have two job definitions for a single host and keep them separate.
I do have a few hosts that I have mulitple jobs defined for, that appears to work.


Brock Palen
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting

> --
> You received this message because you are subscribed to the Google Groups "bareos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/5213981bbe1ad49fb44917d179d3044177923471.camel%40mykolab.com.

[Ruth Ivimey-Cook]

Matt,

My understanding of Always Incremental is that running the job flagged
that way never causes a non-Incremental backup to be requested (as would
normally be the case when Incr's are promoted to Diff or Full depending
on the config). It doesn't preclude other jobs being run on the same
client and fileset. When a consolidate job is being run, I would expect
it to use all the jobs available to create the best consolidation
possible, ie. I would expect the behaviour you observed, because it will
take into account all versions & changes to the files.

Why is it important to only include the jobs run as 'always incremental'?

Have you tried running the Always Incremental job using a
differently-named Fileset (though possibly defining the same files). I
*think* bareos partitions backups not on the files covered but on the
fileset name.

Lastly, bareos 16 is rather ancient and there have been a lot of bug
fixes since then, together with a few new features. I would encourage
you to update to at least 18, and preferably 20, in the near future. In
my experience I have not had compatibility problems when doing so (given
the usual "dir.ver == store.ver").

Ruth


--
Ruth Ivimey-Cook
Magazine Editor, Software Consultant
Blog: http://www.ivimey.org/blog

[Matt Ivie]

For one client I had multiple different jobs configured for different
types of backups. I had one job running off site, hence the desire to
use always incremental, and one locally. They were both using the same
client and fileset configurations.

> Have you tried running the Always Incremental job using a
> differently-named Fileset (though possibly defining the same files).
> I
> *think* bareos partitions backups not on the files covered but on
> the
> fileset name.
>

I did try just changing the fileset and that didn't seem to work. What
I finally ended up doing was defining a separate client configuration
for my always-incremental backups. I'll see how that works but I don't
see why they would intermingle.

> Lastly, bareos 16 is rather ancient and there have been a lot of bug
> fixes since then, together with a few new features. I would
> encourage
> you to update to at least 18, and preferably 20, in the near future.
> In
> my experience I have not had compatibility problems when doing so
> (given
> the usual "dir.ver == store.ver").
>

This is good to know, thank you for the info.

> Ruth
>
>
> --
> Ruth Ivimey-Cook
> Magazine Editor, Software Consultant
> Blog: http://www.ivimey.org/blog
>

[Matt Ivie]

On Fri, 2021-10-22 at 21:34 -0400, Brock Palen wrote:
> In my experense incremental will pull in every job related to that
> client.
>
> I actually use this as a failsafe. I have a VirtualFull job that I
> set to an Archive job.
>
> When I have had media failures, or other (cough) self induced
> wounds, I set the archive job back to backup and run a new virtual
> full.
> I have also used this behavior to migrate systems from traditional
> backup to always incremental.
>

Thanks for this tip.

> I think that’s just how it works currently. I think there is
> probably a way to have two job definitions for a single host and keep
> them separate.
> I do have a few hosts that I have mulitple jobs defined for, that
> appears to work.
>

Thanks for the response Brock. What I've currently done is create a
separate client config for each client just for doing always-
incremental. I'll see how that works over time.