If an incremental backup is upgraded to a differential one, the since time is not updated accordingly. Instead the incremental since time is used.
This means that the differential is actually a normal incremental backup in disguise.

The problem seems to be in GetLevelSinceTime() (dird/job.cc), which is in dire need of an overhaul anyways.

Workaround: use accurate

potential fix included in: https://github.com/sebsura/bareos/tree/dev/ssura/master/poc/resume

Original Mantis issue

We should be able to build Fedora 40.
However, there are two show-shoppers right now:

• upgrade libfmt to a recent version
• fix problems during systemtests (these seem to fail and hang in CI)

Bareos component version

All parts are using 23.0.2.

Steps to reproduce

Open the Subscription tab in the web ui, or call
status subscriptions all
in the console.

Expected results

That the MariaDB Plug-in also counted like the PostgreSQL one.

Actual results

For the PostgreSQL add on, the clients count 2 times. One for the add-on (1 db_units) and one for the file level (1 normal_units) backup like expected.
The MariaDB clients are counted only as file level(1 normal_units) clients.
Sample output:

| pgsqlhost | PostgreSQL | 1 | | | |
| pgsqlhost | | | | | 1 |
| mariadbhost | | | | | 1 |
| msSQL | MSSQL-default:Foo | 1 | | | |
| msSQL | | | | | 1 |

Environment

- OS: `Rocky 8+9`
Fileset for MariaDB:
 Include {
    Options {
      Signature = SHA512
      Compression = GZIP9
      Accurate = pugsmc1n
      No Atime = yes
      # Bug https://bugs.bareos.org/view.php?id=1449
      Check File Changes = no
      # For Bareos 23
      Hard Links = yes
    }
    Plugin = "python"
             ":module_path=/usr/lib64/bareos/plugins"
             ":module_name=bareos-fd-mariabackup"
             ":mycnf=/etc/bareos/mariadb.cnf"
    File = "/etc/my.cnf"
    File = "/etc/my.cnf.d"
    File = "\\|sh -c 'ls /etc/mariadb_* 2>/dev/null|cat'"
    File = "\\|sh -c 'ls /etc/mysql_* 2>/dev/null|cat'"
  }
File set for PostgreSQL:
Include {
    Options {
      Signature = SHA512
      Compression = GZIP9
      Accurate = pugsmc1n
      No Atime = yes
      # Bug https://bugs.bareos.org/view.php?id=1452
      Check File Changes = no
      # For Bareos 23
      Hard Links = yes
    }
    File = "\\|sh -c 'ls /etc/psql_*'"
    Plugin = "python"
             ":module_path=/usr/lib64/bareos/plugins"
             ":module_name=bareos-fd-postgresql"
             ":wal_archive_dir=/var/lib/pgsql/wal_archive"
             ":switch_wal_timeout=120"
             ":db_host=/var/run/postgresql"
             ":role=backup"
  }

Relevant log output

When call it in the console, no uncounted will listed:
Clients/Filesets that cannot be categorized for backup units yet:
No results to list.

Amount of data that cannot be categorized for backup units yet:
         unknown_mb:
 unknown_percentage:

Relevant traces output

No response

Anything else?

In the price list https://www.bareos.com/Bareos_Preisliste.pdf
All three database add ons (PostgreSQL, MariaDB, MSSQL) are listed as an separate unit.
An test MSQL server are also counted twice. One for the the data base an one for the file level.

I recommend to be more explicit where macro expansion will not be required by your build specification.

• Quoting Text for Autoconf
• On Quoting Arguments to macros

This repeats in syslog about 1 to 3 times per second when a backup is running:
Apr 02 19:01:31 p14s.fw.b4.mad bareos-tray-monitor[2788]: libpng warning: iCCP: known incorrect sRGB profile

Would you like to add the configuration script "AX_PTHREAD" to your build specification?

Bareos component version

bareos-dir >= 22

Steps to reproduce

1. use default configuration
2. prepare a job with a Write Bootstrap = "|/usr/bin/bsmtp -h localhost -f \"\(Bareos\) \" -s \"Bootstrap for Job %j\" root"
3. don't have a working smtp service
4. Run the job and check the result

Expected results

list joblog and list jobs shows the same coherent jobstatus.

Monitoring jobstatus with list jobs will never reveal the fact that bootstrap write has failed until someone read the joblog.

Actual results

19-Apr 12:48 bareos-dir JobId 4: Error: Error running program when updating bootstrap file: |/usr/bin/bsmtp -h localhost -f "(Bareos) " -s "Bootstrap for Job BackupCatalog.2023-04-19_12.48.10_06" root: ERR=Child exited with code 1
19-Apr 12:48 bareos-dir JobId 4: Error: Bareos bareos-dir 22.0.4~pre53.42001aeec (14Apr23):
  Build OS:               Red Hat Enterprise Linux release 9.1 (Plow)
  JobId:                  4
  Job:                    BackupCatalog.2023-04-19_12.48.10_06
  Backup Level:           Full
  Client:                 "bareos-fd" 22.0.4~pre53.42001aeec (14Apr23) Red Hat Enterprise Linux release 9.1 (Plow),redhat
  FileSet:                "Catalog" 2023-04-19 12:48:10
  Pool:                   "Full" (From Job FullPool override)
  Catalog:                "MyCatalog" (From Client resource)
  Non-fatal FD errors:    1
  Termination:            *** Backup Error ***

*list jobs
Using Catalog "MyCatalog"
+-------+------------------+-----------+---------------------+----------+------+-------+----------+---------------+-----------+
| jobid | name             | client    | starttime           | duration | type | level | jobfiles | jobbytes      | jobstatus |
+-------+------------------+-----------+---------------------+----------+------+-------+----------+---------------+-----------+
|     4 | BackupCatalog    | bareos-fd | 2023-04-19 12:48:22 | 00:00:00 | B    | F     |       74 |     5,530,808 | T         |
+-------+------------------+-----------+---------------------+----------+------+-------+----------+---------------+-----------+

Environment

- OS: all
- component: bareos-director

Relevant log output

No response

Relevant traces output

No response

Anything else?

Maybe the problem can be fixed easily at seen in the code.

  UpdateJobEnd(jcr, TermCode);

  if (!jcr->db->GetJobRecord(jcr, &jcr->dir_impl->jr)) {
    Jmsg(jcr, M_WARNING, 0,
         T_("Error getting Job record for Job report: ERR=%s\n"),
         jcr->db->strerror());
    jcr->setJobStatusWithPriorityCheck(JS_ErrorTerminated);
  }

  bstrncpy(cr.Name, jcr->dir_impl->res.client->resource_name_, sizeof(cr.Name));
  if (!jcr->db->GetClientRecord(jcr, &cr)) {
    Jmsg(jcr, M_WARNING, 0,
         T_("Error getting Client record for Job report: ERR=%s\n"),
         jcr->db->strerror());
  }

  UpdateBootstrapFile(jcr);

  switch (jcr->getJobStatus()) {
...

Maybe UpdateJobEnd(jcr, TermCode);should happen last.

Bareos component version

23.0.2

Steps to reproduce

1. Back up an EFI-enabled virtual machine
2. restore EFI-enabled virtual machine
3. try to boot

Expected results

The virtual machine should boot the same system that was configured before backup

Actual results

The virtual machine does not boot at all

Environment

- OS: ``
- component:

Relevant log output

No response

Relevant traces output

No response

Anything else?

Workaround: Enter the EFI setup, add the grub entry and change the boot order, as describe here:
https://www.veritas.com/content/support/en_US/article.100038338

As a user of Bareos I would want to be able to use WORM tapes (and other read-only storages). For that we need to remove the pre-labels on not yet written volumes and instead write a normal volume label (that doesn't need to be rewritten).
While this is a change in the volume format, it will only affect empty volumes.

As a user of Bareos I don't want to see non-existent features in the installer. For that the PostgreSQL back-end option, that is integrated in the director since Bareos 23, should be removed from the list of installable options in the Windows installer.
There are also two presets that will both provide PostgreSQL functionality (one probably was the SQLite variant we had earlier). This should be removed, too.

Problem seems to be the STATIC objects we use. If you link the resource directly to the executable

modified   core/src/filed/CMakeLists.txt
@@ -60,11 +60,6 @@ if(HAVE_WIN32)
   )
 endif()
 
-if(HAVE_WIN32)
-  bareos_configure_file(FILES ../win32/filed/filedres.rc.in)
-  list(APPEND FDSRCS ${CMAKE_CURRENT_BINARY_DIR}/../win32/filed/filedres.rc)
-endif()
-
 include_directories(${OPENSSL_INCLUDE_DIR})
 
 add_library(fd_objects STATIC ${FDSRCS})
@@ -76,6 +71,11 @@ endif()
 
 add_executable(bareos-fd filed.cc)
 
+if(HAVE_WIN32)
+  bareos_configure_file(FILES ../win32/filed/filedres.rc.in)
+  target_sources(bareos-fd PRIVATE ${CMAKE_CURRENT_BINARY_DIR}/../win32/filed/filedres.rc)
+endif()
+
 set(BAREOS_FD_LIBRARIES bareosfind bareos Threads::Threads)
 if(HAVE_WIN32)
   target_sources(bareos-fd PRIVATE ../win32/generic/main.cc)

then the icon appears normally again.

I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from functions like the following?

• fputs ⇒ sendit
• pthread_cond_signal ⇒ handle_stored_connection

I would like to point out that identifiers like "_BAREOS_H" and "__JCR_H_" do not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

I suggest to add the key word "const" to the type specifiers for parameters like the following.

• strip_prefix, add_prefix, add_suffix (function "bregexp_build_where")
• ptr (function "write_nbytes")

Would you like to apply the advices from an article to more places in your source files?

Bareos component version

1. bareos > 22.0
2. mariadb >= 11.0

Steps to reproduce

1. install bareos version 23
2. install mariadb version 11+
3. setup backup with mariabackup plugin
4. see error raised during backups

Expected results

Terminated jobs

Actual results

The message below appears when you try to make an incremental mariadb backup. I think the backup work fails because of the warning.

Fatal error: python3-fd-mod: Could not get LSN with command "echo 'SHOW ENGINE INNODB STATUS' | mysql --defaults-extra-file=/root/.my.cnf -r | grep 'Log sequence number' | awk '{ print $4 }'", Error: b"mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead\n"

Environment

- OS: `Linux Ubuntu 22.04`
- component: mariadb version: 11.0.3-MariaDB-1:11.0.3+maria~ubu2204 mariadb.org binary distribution

Relevant log output

No response

Relevant traces output

No response

Anything else?

Mariadb is getting ride of old names, so the long deprecated mysql* and also the symlink mariabackup should be replaced by the real binary name
mariabackup -> mariadb-backup
mysql -> mariadb
....

Initial report https://bugs.bareos.org/view.php?id=1568

An experimental branch exist with some changes may serve as a basis
https://github.com/bruno-at-bareos/bareos/tree/dev/bruno/master/fix-mariadb-11%2B

Currently the syslog() implementation on windows reports every message as an error in the windows event log.
I propose that we use the following severity level translation instead:

LOG_EMERG   |
LOG_ALERT   | ==> EVENTLOG_ERROR_TYPE
LOG_CRIT    |
LOG_ERR     |

LOG_WARNING | ==> EVENTLOG_WARNING_TYPE

LOG_NOTICE  |
LOG_INFO    | ==> EVENTLOG_INFORMATION_TYPE
LOG_DEBUG   |
NO SEVERITY |

Additional options:

EVENTLOG_SUCCESS
EVENTLOG_AUDIT_FAILURE
EVENTLOG_AUDIT_SUCCESS

See: https://learn.microsoft.com/en-us/windows/win32/eventlog/event-types

Bareos component version

bareos-fd --version 23.0.3~pre63.bb6c03acf
bareos-dir --version 23.0.3~pre63.bb6c03acf
bareos-sd --version 23.0.3~pre63.bb6c03acf
bconsole --version 23.0.3~pre63.bb6c03acf

Steps to reproduce

1. Have Ubuntu 20.04 LTS installed with the OS supplied release of urllib3
2. Update to BareOS 23.0.3
3. Try to back up a VM from VCenter

Expected results

Backup succeeds, as it did prior to the upgrade to 23.0.3

Actual results

JobId 31832: Fatal error: bareosfd: Traceback (most recent call last):
File "/usr/lib/bareos/plugins/BareosFdWrapper.py", line 59, in handle_plugin_event
return bareos_fd_plugin_object.handle_plugin_event(event)
File "/usr/lib/bareos/plugins/bareos-fd-vmware.py", line 1057, in handle_plugin_event
return self.start_backup_job()
File "/usr/lib/bareos/plugins/bareos-fd-vmware.py", line 497, in start_backup_job
return self.vadp.prepare_vm_backup()
File "/usr/lib/bareos/plugins/bareos-fd-vmware.py", line 1492, in prepare_vm_backup
if self.get_vm_nvram():
File "/usr/lib/bareos/plugins/bareos-fd-vmware.py", line 3226, in get_vm_nvram
self.vm_nvram_content = self.retrieve_file_content_from_datastore(
File "/usr/lib/bareos/plugins/bareos-fd-vmware.py", line 3310, in retrieve_file_content_from_datastore
retries = urllib3.util.Retry(
TypeError: __init__() got an unexpected keyword argument 'allowed_methods'

Environment

- OS: `NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
`
- component:
python3-urllib3/focal-updates,focal-security,now 1.25.8-2ubuntu0.3 all [installed]

Relevant log output

No response

Relevant traces output

No response

Anything else?

I resolved this issue in my instance by doing a do-release-upgrade. Other users may find the info contained within this issue useful. The version of urllib3 available via apt in Ubuntu 20.04 LTS is from 2020.