Hello,
pon., 27 sie 2018 o 22:12 George Anchev via Bacula-users <
bacula-users@lists.sourceforge.net> napisał(a):

> On Mon, 27 Aug 2018 18:29:17 +0200 Radosław
> Korzeniewski wrote:
>
> > Until you show your queries as I done above I cannot
> > judge here. :)
>
> Attached.
>
MariaDB [bacula]> select ClientId from Client where name='local-fd';
> +----------+
> | ClientId |
> +----------+
> |        5 |
> +----------+
> 1 row in set (0.00 sec)
> MariaDB [bacula]> select ClientId from Client where name='remote-fd';
> +----------+
> | ClientId |
> +----------+
> |        1 |
> +----------+
>

This is interesting. Your remote FD got a first ID... but it is unrelated.


>
> MariaDB [bacula]> select * from FileSet where fileset='local_FileSet';
>
> +-----------+---------------+------------------------+---------------------+
> | FileSetId | FileSet       | MD5                    | CreateTime
> |
>
> +-----------+---------------+------------------------+---------------------+
> |        60 | local_FileSet | ElA2mS+TR9/dNnhML8/E5B | 2016-01-07 00:47:55
> |
>
> +-----------+---------------+------------------------+---------------------+
> 1 row in set (0.00 sec)
> MariaDB [bacula]> select * from FileSet where fileset='remote_FileSet';
>
> +-----------+----------------+------------------------+---------------------+
> | FileSetId | FileSet        | MD5                    | CreateTime
>   |
>
> +-----------+----------------+------------------------+---------------------+
> |        64 | remote_FileSet | XW/0wB//49w0pSdx1ihdJB | 2016-01-10
> 01:57:55 |
> |        65 | remote_FileSet | a6Eub7/EM4/JhR1At5l+0A | 2018-08-07
> 01:49:36 |
>
> +-----------+----------------+------------------------+---------------------+
> 2 rows in set (0.00 sec)
>

OK, it definitely shows that you have changed your fileset and Bacula
computed a new md5 for it. 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.


> MariaDB [bacula]> SELECT StartTime, Job FROM Job WHERE JobStatus IN
> ('T','W') AND Type='B' AND Level='F' AND Name='local-fd' AND ClientId=5 and
> FileSetId=60;
> Empty set (0.00 sec)
>

Well, the above sql query is invalid. Your job name is not 'local-fd' but
'local_Backup'.


> MariaDB [bacula]> SELECT StartTime, Job FROM Job WHERE JobStatus IN
> ('T','W') AND Type='B' AND Level='F' AND Name='remote-fd' AND ClientId=1
> AND FileSetId=65;
> Empty set (0.00 sec)
>

The same here. Your remote job is not 'remote-fd' but 'remote_Backup'.


> MariaDB [bacula]> SELECT * FROM Job WHERE Name='local-fd' AND ClientId=5;
> Empty set (0.00 sec)
> MariaDB [bacula]> SELECT * FROM Job WHERE Name='remote-fd' AND ClientId=1;
> Empty set (0.00 sec)
> MariaDB [bacula]> SELECT * FROM Job WHERE Name='local-fd';
> Empty set (0.00 sec)
> MariaDB [bacula]> SELECT * FROM Job WHERE Name='remote-fd';
> Empty set (0.00 sec)
>

The same for any above queries.


> MariaDB [bacula]> SELECT StartTime, Job FROM Job WHERE JobStatus IN
> ('T','W') AND Type='B' AND Level='F' AND ClientId=1;
> +---------------------+--------------------------------------+
> | StartTime           | Job                                  |
> +---------------------+--------------------------------------+
> | 2018-07-15 17:39:53 | remote_Backup.2018-07-15_17.39.48_31 |
> +---------------------+--------------------------------------+
> 1 row in set (0.00 sec)
>

OK, it would be great if we can verify what filesetid was used for this job.


> MariaDB [bacula]> SELECT StartTime, Job FROM Job WHERE JobStatus IN
> ('T','W') AND Type='B' AND Level='F' AND ClientId=5;
> +---------------------+----------------------------------------+
> | StartTime           | Job                                    |
> +---------------------+----------------------------------------+
> | <unrelated>         | <unrelated>                            |
> | <unrelated>         | <unrelated>                            |
> | 2018-07-15 15:11:19 | local_Backup.2018-07-15_15.11.15_11    |
> | <unrelated>         | <unrelated>                            |
> | <unrelated>         | <unrelated>                            |
> | <unrelated>         | <unrelated>                            |
> +---------------------+----------------------------------------+
> 6 rows in set (0.00 sec)


As you do not have a problem with local_Backup then you can skip checking
it.


> To avoid potential misunderstandings:
>
> Incremental estimates for local* work fine.
> Incremental estimates for remote* fall back to Full.
>
>
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. :) 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.

The <unrelated> incremental jobs also estimate fine
> but I have hidden them to avoid visual clutter.
>
> FWIW: I have no idea why FileSetId=64 exists (as well
> as many other older records in FileSet table which I
> have used in the past and don't exist any more).
>

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.

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

Reply via email to