Hi Radosław,

Thank you for the reply and my apologies for emailing you directly - that
was by mistake.

I have been doing some more investigation and noticed some other issues
when doing actions relating to the catalogue. See the below:
root@sandpit:~ # bconsole
Connecting to Director localhost:9101
1000 OK: 103 sandpit-dir Version: 9.6.3 (09 March 2020)
Enter a period to cancel a command.
*relabel
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
Automatically selected Storage: sandpit-sd-Backup-Test
Defined Pools:
     1: Backup-Test
     2: Scratch
Select the Pool (1-2): 1
+---------+------------+-----------+---------+-----------+----------+--------------+---------+------+-----------+-----------+---------+----------+---------------------+-----------+
| MediaId | VolumeName | VolStatus | Enabled | VolBytes  | VolFiles |
VolRetention | Recycle | Slot | InChanger | MediaType | VolType | VolParts
| LastWritten         | ExpiresIn |
+---------+------------+-----------+---------+-----------+----------+--------------+---------+------+-----------+-----------+---------+----------+---------------------+-----------+
|       1 | Backup1    | Append    |       1 | 6,082,978 |        0 |
 2,592,000 |       1 |    0 |         0 | File      |       1 |        0 |
2020-07-04 03:47:59 |   875,911 |
+---------+------------+-----------+---------+-----------+----------+--------------+---------+------+-----------+-----------+---------+----------+---------------------+-----------+
Enter a Volume name or *MediaId: 1
sql_get.c:1266 Media record for Volume name "1" not found.

I noticed similar issues on my production system (the above is from a test
VM) until I labeled another media. After that, I could take actions on the
new media, but not on the old.

As this is a test VM that has no data in it, I have exported it to an OVA
and put it on Google Drive. This can be re-imported into Virtual Box if you
want to troubleshoot with my test VM directly. You can download it here:
https://drive.google.com/file/d/1fS2iJzMYD3LDDTaQe-9PlCEM68mrhZzg/view?usp=sharing
The password to login is simply 123open.

Alternatively, what log files are helpful here? It seems to me that either
there is something wrong with the catalogue database or with the SQL
queries being used for certain parts of Bacula.

Any help is much appreciated. My production system is limited in RAM and
CPU and runs a MYSQL database for another service. This is why I was hoping
to use MYSQL for the Bacula catalogue, to avoid having to run an additional
database server.

Regards,
Michael


On Fri, 3 Jul 2020 at 19:01, Radosław Korzeniewski <
rados...@korzeniewski.net> wrote:

> Hello Michael,
>
> pt., 3 lip 2020 o 06:12 Michael Williams <mickwi...@gmail.com> napisał(a):
>
>> Hello,
>>
>> So it's been some time since I was last looking into this issue. I have
>> finally setup another test VM running FreeBSD and installed Bacula using
>> FreeBSD Ports, compiled with MYSQL as the database. Running a test, it has
>> exactly the same issue with running an incremental or differential backup
>> with the "Accurate = Yes".
>>
>
> Could you share your logs, please?
>
> If you run your job with bad preconditions then I do not expect different
> results.
>
>
>> Is anyone else using MYSQL for the catalogue? If so, are you using the
>> the 'Accurate = Yes' job configuration option?
>>
>
> I do not know, because you sent this email to me directly and not to the
> user group.
>
> best regards
> --
> Radosław Korzeniewski
> rados...@korzeniewski.net
>
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to