Hello,
wt., 28 sie 2018 o 15:16 George Anchev <stu...@anchev.net> napisał(a):
> On Tue, 28 Aug 2018 13:50:17 +0200 Radosław
> Korzeniewski wrote:
>
> > This is interesting. Your remote FD got a first
> > ID... but it is unrelated.
>
> Yes. Because long time ago DIR and SD were on that
> host and there were no other hosts in the network. But
> that was Bacula 5.x (perhaps).
>
And this client had a name 'remote-fd', right?
>
> > I think this is the main cause. You have changed your
> > fileset without instructing Bacula to ignore these
> > changes with IFC parameter as you've done for
> > 'local_Fileset'. This is a suspicion only, as I did
> > not verified it in source code.
>
> I think this may be incorrect suspicion because in the
> past I have noticed that running an estimate for a job
> without IFC also resulted in Full fallback and simply
> adding the IFC and reloading the DIR service instantly
> resulted in correct incremental estimate.
>
I do not understand the above statement. Is it the same situation like you
are experiencing now.
>
> Here are the corrected queries:
>
> MariaDB [bacula]> SELECT StartTime, Job FROM Job WHERE Type='B' AND
> Level='F' AND Name='local_Backup' AND ClientId=5 and FileSetId=60;
> +---------------------+-------------------------------------+
> | StartTime | Job |
> +---------------------+-------------------------------------+
> | 2018-07-15 15:11:19 | local_Backup.2018-07-15_15.11.15_11 |
> +---------------------+-------------------------------------+
> 1 row in set (0.00 sec)
>
> MariaDB [bacula]> SELECT StartTime, Job FROM Job WHERE JobStatus IN
> ('T','W') AND Type='B' AND Level='F' AND Name='remote_Backup' AND
> ClientId=5;
> Empty set (0.00 sec)
>
>
This query is not correct. You are asking for remote_Backup on local-fd,
right?
> > > [...]
> > > +---------------------+--------------------------------------+
> > > | 2018-07-15 17:39:53 |
> > > remote_Backup.2018-07-15_17.39.48_31 |
> > > +---------------------+--------------------------------------+
> >
> > OK, it would be great if we can verify what
> > filesetid was used for this job.
>
> bat says:
>
> JobId: 4677
> Job: remote_Backup.2018-07-15_17.39.48_31
> Backup Level: Full (upgraded from Incremental)
> FileSet: "remote_FileSet" 2016-01-10 01:57:55
>
>
What sql query say?
> IOW: that is fileset 64, not 65 (the latest one
> shown by the sql query).
>
> > I think it is because you didn't set the "Ignore
> > Fileset Changes = yes" for your 'remote_FileSet'
> > before reloading the configuration. Now it is simply
> > too late. :)
>
> As mentioned above my experience shows that it is not
> the case (at least until now).
>
>
My current experience in this area is: when you change fileset, then any
next incr/diff jobs will be upgraded to full unless you've set ignore
fileset changes = yes.
> > I could be wrong about it because I did not verified
> > my suspicion in source code. So, when you've added
> > the IFC parameter to 'remote_FileSet' then any other
> > changes to this fileset will be ignored, but not
> > this one.
>
> I think it may be worth checking the source code
> although personally have no idea how to do it or how
> to get info from that. It is possible that Bacula 9.x
> works differently from version 7.x in regards to IFC.
> But logically: it would make no sense. E.g. what is the
> point of changing a file set, then telling the program
> to ignore the fileset change and then the program
> ignoring the instruction?
I never observe this kind of behavior in Bacula.
Sounds like incorrect
> (buggy) behavior. So far I have never seen this
> happening.
>
> I wonder what to do.
>
To understand what is happening in your setup, you need to carefully check
you catalog data. You can even trace some debug messages to verify what is
going on Bacula side. I'm not sure if it is worth the effort.
>
> > Every time Director find a Fileset in configuration
> > it verifies if the appropriate record exist in
> > catalog, if not Dir creates it. The fileset records
> > are not removed from fileset table - this is a
> > behavior I'm experiencing.
>
> Thanks for sharing. I wonder if that should be like
> this. Why keep records for things expired long ago
> which will never be used again?
The fileset data is required for job information. When you delete some jobs
(manually or when automatic retention time pass) then Bacula has no
information what fileset entries are not required any more. To check it
Bacula has to make a special catalog query which would take time and
resources, which is useless when you want to save a few bytes on your
catalog.
> By long ago I mean:
> long after any retention times have expired and even
> after quite a few purges for the particular job have
> been run.
>
You could manually delete orphaned fileset data using dbcheck utility:
(...)
10) Eliminate orphaned Filename records
(...)
best regards
--
Radosław Korzeniewski
rados...@korzeniewski.net
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
