You need to enter Backup1 or *1 (the prompt says this, but it is somewhat cryptic).
__Martin >>>>> On Thu, 23 Jul 2020 14:56:23 +1200, Michael Williams said: > > 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
