On Sat, 2021-10-23 at 16:44 +0100, Ruth Ivimey-Cook wrote: > On 20/10/2021 18:39, Matt Ivie wrote: > > 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? > > > 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'? > 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 > -- "Under the sky, under the heavens there is but one family." --Bruce Lee -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/5a2e1a995426effd40e4a5f0ea154807c02e2c17.camel%40mykolab.com.
signature.asc
Description: This is a digitally signed message part
