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