Security and best practices#
This page provides general security recommendations and best practices for using Restore Verification safely and effectively.
1. Use a dedicated Restore Destination#
A key security principle is to use dedicated test hosts as Restore Destinations.
Running restore tests on a production host is technically possible, but it introduces several risks:
When using a Restore Destination with original-path restore, restored data may overwrite production data.
Restoring large backups may quickly consume the available storage space on the Restore Destination.
The load generated by restoring large amounts of data may negatively affect a production host, including storage, network, CPU, and memory utilization.
Recommendation: Use dedicated test environments as Restore Destinations.
2. Restrict access to the Restore Destination#
Restored test data may contain sensitive or confidential production information.
The Restore Destination should therefore be protected with access controls appropriate for the original data.
Recommendation: Restrict access to the Restore Destination so that restored data is accessible only to authorized users and services.
3. Clean up restored data#
Remove restored test data when it is no longer needed. This prevents production data from remaining on the Restore Destination longer than necessary.
Please note that Bacularis does not automatically clean up restored data from the Restore Destination after tests.
Recommendation: Prepare a script or other automation to remove restored test data when it is no longer required.
4. Use a dedicated Restore Job#
Prepare a dedicated Restore Job that is used only for Restore Verification.
Restore Verification adds RunScript configuration to the Restore Job. These
scripts are intended specifically for the Restore Verification workflow.
Using the same Restore Job for both regular restores and Restore Verification
causes the Restore Verification RunScript to also be executed during normal
restore operations. In such cases, the script may cause the regular Restore
Job to fail.
Recommendation: Maintain at least two Restore Jobs: one for regular restore operations and another dedicated exclusively to Restore Verification.
5. Use a dedicated Verify Job#
If you use Restore Verification with the Native Bacula Verify method, use a Verify Job dedicated exclusively to Restore Verification.
Bacularis updates directives in the Verify Job as required by the Restore Verification workflow. If the same Verify Job is also used for unrelated verification tasks, these updates may affect its behavior outside Restore Verification.
Recommendation: When using Native Bacula Verify, use a dedicated Verify Job exclusively for Restore Verification.
6. Use HTTPS instead of HTTP#
Restore Verification uses Bacularis Web Access, which communicates over HTTP(S).
If Bacularis is used without TLS encryption, Web Access requests may be exposed to network interception.
Recommendation: Use HTTPS for Bacularis Web Access whenever communication leaves a fully trusted local environment.
7. Restrict source IP addresses#
Restore Test configuration allows you to restrict the source IP addresses that are permitted to start Restore Verification tests.
This can be configured using the Access for IP addresses option in the advanced Restore Test settings. Only requests originating from the configured IP addresses are then accepted.
For example, if Restore Verification requests are sent locally from the Bacula
Director host to Bacularis, the permitted source address can be set to 127.0.0.1.
By default, Access for IP addresses is disabled. Multiple source IP addresses can be configured.
IP restrictions provide an additional access-control layer and should be used together with HTTPS rather than as a replacement for encrypted communication.
Recommendation: Restrict source IP addresses whenever possible.
8. Limit administrative access#
Restore Verification is available only to Bacularis administrators, meaning
users assigned the admin role.
Granting administrative access therefore also grants the ability to configure Restore Verification.
Bacularis provides additional mechanisms for restricting access, including restrictions that can also apply to administrators. The important general principle is that administrative access includes access to Restore Verification configuration.
Grant administrative access only to users who need to configure or operate Restore Verification.
Recommendation: When granting administrative access, keep in mind that it also provides access to Restore Verification.
9. Use the Audit log#
Bacularis records Restore Verification errors and warnings in the Audit log, available at:
[Application settings] => [Tab: Audit log]
You can also configure email notifications for Audit log events using the Bacularis email notification plugin.
Audit log events can be used to detect configuration problems, failed Restore Tests, and other Restore Verification warnings.
Recommendation: Regularly review the Audit log or configure email notifications for important Bacularis events.
10. Restore only the data you need to test#
When using Rule-based Verification, you can choose to restore only the paths that will actually be tested.
This is particularly useful for large backups because it avoids restoring data that is not part of the verification scope and reduces storage usage on the Restore Destination.
Restoring the entire backup can also be valuable, however. A full restore provides broader recovery coverage and can detect problems that path-based verification may not expose, such as unavailable Bacula volumes required to reconstruct the restore point.
There is a trade-off between test efficiency and recovery coverage.
Recommendation: Choose the restore scope according to your verification goals. Use targeted path restores when efficiency is important, and full restore-point tests when broader recovery coverage is required.
11. Plan storage capacity#
Make sure the Restore Destination has enough free space for the largest expected restore and for any temporary resources created by checker plugins.
Application-level checkers may require additional space beyond the restored files themselves. For example, a database checker may need space for both the restored dump and the temporary imported database.
Recommendation: Size the Restore Destination for the largest expected restore and any additional temporary test data.
12. Protect the Restore Destination itself#
A test host should not be treated as unimportant simply because it is not a production system.
Restore Destinations may temporarily contain real production data and should therefore be protected accordingly.
Consider:
restricting access,
keeping the operating system up to date,
disabling unnecessary services,
applying appropriate file and system permissions,
using network isolation where appropriate.
Recommendation: Apply security controls to the Restore Destination that reflect the sensitivity of the data being restored.
13. Schedule tests with system load in mind#
Restore Verification may generate significant I/O and network traffic not only on the Restore Destination, but also across other parts of the backup infrastructure, including:
the Storage Daemon,
the Director,
the network,
backup storage.
Avoid scheduling large Restore Tests during backup windows or other periods of high storage activity unless the infrastructure is sized for concurrent workloads.
Recommendation: Schedule resource-intensive Restore Tests during periods when sufficient storage, network, and system capacity is available.
14. Treat custom checker plugins as trusted code#
Custom checker plugins execute code on the Restore Destination and may start processes, access restored data, or modify temporary resources.
Because custom checkers can perform application-level operations and execute external commands, they should be treated as trusted executable code.
Recommendation: Install only trusted checker plugins and review their code before deployment.