Limitations

There exists one critical element of a Bacula Enterprise instance the reliability of which may affect the reliability of any integrity checking done with Bacula: The catalog database.

Not only does the catalog have to be configured to prevent unauthorized access and modifications to it, the catalog must also remain available, consistent and correct. Otherwise, if you can not ensure the catalog’s security, you can not rely on the results of any Verify Jobs. The most important steps are

Create a dedicated role for access to Bacula Enterprise’s** catalog database. The credentials are stored in the director (dir)’s configuration, so this needs to be protected against unauthorized access as well.
Do not assign permissions to modify the catalog to applications that do not need them, like reporting tools. Use a role with restricted permissions for those tools.
Ensure that your Bacula as well as your catalog database server(s) are inaccessible to unauthorized persons – both remotely and physically.
Create and keep backups of your catalog database. Keep those backups safe.
Consider running your catalog in a cluster to minimize the risk of failure and data loss.

While Unix and Gnu/Linux systems systems typically have a file system layout that allows to identify critical files easily, Microsoft Windows is much more difficult in that respect. One reason is that a lot of the configuration information is kept in the registry, not easily accessible at the file level. Also, in the registry, system configuration, critical application data, and non-critical, changing data are mixed, which makes verification of the complete registry impossible. Furthermore, it’s difficult – if not impossible – to identify critical system files on a windows system with reasonable effort, and the way Windows itself manages its system files makes it very difficult to apply Verify Jobs to Windows operating systems.