Read how Bacularis with Bacula can be used in the event-driven architecture
Traditionally, backup strategies have been built around scheduled batch processes, running at predefined intervals - once a day, once a week, or several times a day. While easy to implement, this model carries the inherent risk of losing data created or modified between two backup windows.
Event-driven backup changes this paradigm entirely. Instead of waiting for the next scheduled run, a backup is instantly triggered by an event - defined as a "significant change of state" in the system. Examples include a new record added to a database, a file being modified, or a security alert being raised. This immediate response transforms backups from a reactive process into a proactive element of a broader data protection strategy.
The driving force behind event-driven data protection is the need to meet strict recovery objectives:
Shifting from scheduled backups to an event-driven approach mirrors a broader industry trend: moving from passive infrastructure management to proactive automation. Scheduled backups represent a "pull" model, where the system periodically checks for changes. This naturally introduces latency and extends the RPO. In contrast, an event-driven architecture follows a "push" model, reacting instantly to changes, enabling near-zero or even zero RPO.
This represents a fundamental shift - from "let me check if something has changed" to "notify me the moment something changes."
The choice between event-driven and scheduled backups is not about "better versus worse," but about what fits best in a given business and technical context. Both approaches have strengths and limitations, and the right decision depends on risk assessment, cost, and recovery requirements.
Implementing event-driven backup in Bacula comes with some challenges. Particular care must be taken when configuring data retention in Bacula’s catalog database and storage daemon volumes. Since backups are triggered by events rather than fixed schedules, retention policies and volume recycling need to be carefully designed.
Dynamic file volume creation can also be very helpful, as it allows Bacula to automatically add new volumes when needed. However, proper limits must be defined to prevent uncontrolled volume growth instead of efficient reuse.
Starting with version 5.7.0, Bacularis introduces Web Access, which makes event-driven backups easier to implement. Compared to the Bacularis API, web access offers a simpler approach: there’s no need to configure API users or handle direct API integration, since all configuration is securely managed within Bacularis itself.
That said, web access does not replace the Bacularis API. Using the configurable API remains a strong option in environments requiring advanced control and customization. In fact, web access itself uses the API under the hood, acting as a user-friendly "overlay" exposed through the web interface.
Here’s a demonstration video showing how to set up event-driven backup with Bacula. In this example, Bacula creates a backup of a fictional online store’s database whenever a new order is placed. The backup is triggered using Bacularis web access.