Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Bacula.
Nothing was collected or created yet.
Bacula
View on Wikipediafrom Wikipedia
 |
| Bacula | |
|---|---|
 | |
| Developers | Kern Sibbald and team |
| Initial release | January 2000 |
| Stable release | 15.0.2[1]
/ 22 March 2024 |
| Written in | C, C++ |
| Operating system | Cross-platform |
| Type | Backup |
| License | GNU Affero General Public License v3.0 |
| Website | www |
Bacula is an open-source, enterprise-level computer backup system for heterogeneous networks. It is designed to automate backup tasks that had often required intervention from a systems administrator or computer operator.
Bacula supports Linux, UNIX, Windows, and macOS backup clients, and a range of professional backup devices including tape libraries. Administrators and operators can configure the system via a command line, GUI or web interface; its back-end is a catalog of information stored by MySQL, PostgreSQL, or SQLite.
Overview
[edit]Bacula is a set of computer programs for managing backup, recovery, and verification of computer data across a network—providing a backup solution for mixed operating system environments.
Bacula is open-source and released under the AGPL version 3 license with exceptions to permit linking with OpenSSL and distributing Windows binaries.[2]
Bacula is available under a "dual license" (see Multi-licensing) AGPLv3 or Proprietary license. Several entities offer commercial support for the AGPL "Bacula community version" while Bacula Systems[3] sells various levels of annual support contracts for "Bacula Enterprise Edition", which contains various non-GPL components developed in-house.
In common with other dual-license software, components developed for the Bacula Enterprise Edition are released into Bacula Community edition after some period of exclusivity to the proprietary version.
Since April 2002, Bacula has over 2 million downloads, which makes it the most downloaded open-source backup program.[4]
Features
[edit]Bacula's features include:
Network options
[edit]- TCP/IP – client–server communication uses standard ports and services instead of RPC for NFS, SMB, etc.; this eases firewall administration and network security
- CRAM-MD5 – configurable client–server authentication
- GZIP/LZO – client-side compression to reduce network bandwidth consumption; this runs separate from hardware compression done by the backup device
- TLS – network communication encryption[5]
- MD5/SHA – verify file integrity
- CRC – verify data block integrity
- PKI – backup data encryption
- NDMP – enterprise version plugin[6]
- cloud backup with some S3 file storage services
Client OS
[edit]The client software, executed by a "file daemon" running on a Bacula client, supports multiple operating systems.[7]
Considerations
[edit]By default, Bacula's differential and incremental backups are based on system time stamps. Consequently, if you move files into an existing directory or move a whole directory into the backup FileSet after a full backup, those files may not be backed up by an incremental save because they may have old dates. You must explicitly update the date/time stamp on all moved files. Bacula versions starting with 3.0 or later support Accurate backup, which is an option that addresses this issue without requiring modification of the files timestamps. This feature should always be used if an accurate state of the filesystem is important. Which criteria should be applied is configurable, i.e. inode comparisons, modification times or md5/sha1 signatures.[8]
History
[edit]| Date | Event |
|---|---|
| January 2000 | Project started |
| April 14, 2002 | First release to SourceForge.net (version 1.16) |
| June 29, 2006 | Release 1.38.11 (Final version 1 release) |
| January 2007 | Release 2.0.0 |
| September 2007 | Release 2.2.3 |
| June 2008 | Release 2.4.0 |
| April 2009 | Release 3.0.0 with new features[8] |
| January 2010 | Release 5.0.0 with new features[9] |
| September 2010 | Release 5.0.3 |
| January 2012 | Release 5.2.4 with new features[10] |
| February 2012 | Release 5.2.6 |
| June 2012 | Release 5.2.9 |
| February 2013 | Release 5.2.13 |
| July 2014 | Release 7.0.5 with many new features[11] |
| August 2015 | Release 7.2.0 with many new features[12] |
| July 2017 | Release 9.0.0 with many new features[13] |
| December 2018 | Release 9.2.0 with many new features[14] |
| January 2020 | Release 9.4.0 with many new features[15] |
| March 2021 | Release 11.0.0 with many new features[16][17] |
| August 2022 | Release 13.0.1 with many new features[18][19] |
| March 2024 | Release 15.0.2 with many new features[20][21] |
Forks of Bacula
[edit]In 2011, Graham Keeling, a "former" Bacula community developer, released a friendly fork of Bacula.[22]
In February 2013 a former Bacula community developer (with several other Free Software users) released Bareos as a fork of Bacula.[23]
See also
[edit]References
[edit]- ^ "Bacula Community 15.0.2 Released!".
- ^ "Bacula Copyright, Trademark, and Licenses". Bacula.org.
- ^ "Bacula Systems S.A."
- ^ "Bacula". 22 March 2024.
- ^ "Bacula TLS – Communications Encryption".
- ^ Bacula Enterprise Plugins
- ^ "Supported Operating Systems". Bacula.org.
- ^ a b "New Features in 3.0.0". Bacula.org.
- ^ "New Features in 5.0.0". Bacula.org.
- ^ "New Features in 5.2.0". Bacula.org.
- ^ "New Features in 7.0.0". Bacula.org.
- ^ "New Features in 7.2.0". Bacula.org.
- ^ "New Features in 9.0.0". Bacula.org.
- ^ "New Features in 9.2.0". Bacula.org.
- ^ "New Features in 9.4.0". Bacula.org.
- ^ "New Features in 11.0.0". Bacula.org.
- ^ "New Features in 11.0.1". Cloud7 News. 6 February 2021. Archived from the original on 25 November 2021. Retrieved 11 June 2021.
- ^ "New Features in 13.0.0". Bacula.org.
- ^ "New Features in 13.0.1". Bacula.org. 5 August 2022.
- ^ "New Features in 15.0.0". Bacula.org.
- ^ "New Features in 15.0.2". Bacula.org. 22 March 2024.
- ^ "Burp".
- ^ "Bareos".
External links
[edit]
Bacula
View on Grokipediafrom Grokipedia
Introduction
Overview
Bacula is a cross-platform, network-based backup system designed for data protection, archiving, and disaster recovery across heterogeneous environments, ranging from single computers to large enterprise networks.[1] As an open-source project licensed under the GNU Affero General Public License version 3 (AGPLv3), Bacula originated in the early 2000s as a free alternative to proprietary commercial backup solutions like Veritas NetBackup, enabling organizations to implement robust backup strategies without licensing costs.[7][1] In its basic operational model, Bacula coordinates backups by transferring data from client machines to storage devices over a network, managed by a central director that oversees the entire process. It features a modular architecture that supports an unlimited number of clients and storage volumes, offering scalability and flexibility at no cost for the community edition. Core components include the Director for orchestration, the Storage Daemon for handling storage, and the File Daemon for client-side operations.[1] As of November 2025, Bacula remains under active development, with the latest stable release in the 15.x series (version 15.0.3) emphasizing enhancements in cloud integration, such as the new Amazon Cloud Driver for improved support of AWS services.[1][8]Core Architecture
Bacula employs a modular client-server architecture that separates core responsibilities among distinct daemons to ensure efficient backup operations across distributed environments. The Director serves as the central control entity, coordinating jobs and managing resources, while the Storage Daemon handles all data writing and reading to storage media, and the File Daemon operates on client machines to collect and transmit data. This separation allows for independent scaling and maintenance of each component without affecting the overall system.[9][10] In the data flow, the File Daemon gathers files from client systems and streams them over the network to the Storage Daemon for storage, with the Director overseeing the process by instructing the File Daemon on what to back up and directing the Storage Daemon to the appropriate media. This orchestration ensures that backup jobs, including full, incremental, and differential types, proceed systematically while updating a central catalog database with job metadata. The flow supports restore operations in reverse, retrieving data from storage via the Director's guidance.[9][11] Bacula's network-centric model relies on TCP/IP for communication between daemons, enabling deployment in LAN or WAN setups where components can run on separate hosts. This design facilitates secure, encrypted data transfer across heterogeneous networks, accommodating environments from single machines to large-scale deployments.[10][12] Scalability is achieved through the distributed nature of the daemons, allowing multiple instances of File Daemons on clients and Storage Daemons on storage nodes to distribute workloads, supporting thousands of clients per Director and handling petabytes of data. The architecture's multi-threaded implementation further enhances performance by processing concurrent jobs efficiently.[10][13] Integration points include support for diverse storage backends via configurable devices and plugins, such as tape libraries for high-capacity archival, disk-based storage for rapid access, and cloud services like Amazon S3 through dedicated plugins that enable direct backup and restore operations. These integrations use abstract storage pools and volumes to manage media types uniformly.[14][15][10]Components
Director
The Director serves as the central control hub, or "brain," of the Bacula backup system, responsible for managing and coordinating all backup, restore, verify, and archive operations across the network. It handles job scheduling to sequence and prioritize tasks, performs client authentication using secure methods such as CRAM-MD5 or TLS with X.509 certificates, and allocates resources including storage daemons, media pools, and client connections to ensure efficient system operation. By maintaining oversight of these elements, the Director enables seamless interaction with other components, such as directing the File Daemon to initiate data transfer for backups.[16] The Director's configuration is defined in thebacula-dir.conf file, which is the most comprehensive among Bacula's configuration files and requires updates for adding clients, storage resources, or modifying job definitions. Key directives within this file include the Storage resource for specifying storage daemons and devices (e.g., Storage { Name = FileStorage, [Address](/page/Address) = localhost, [Port](/page/Port) = 9103, Password = xxx }), the Pool resource for grouping volumes and setting retention policies (e.g., Pool { Name = FullBackupsVirtualPool, Storage = File4, Volume Retention = 30 days }), the Schedule resource for defining job timing and frequency (e.g., Schedule { Name = WeeklyCycle, Run = Level=Full daily at 7:00 }), and the Client resource for authenticating and detailing client machines (e.g., Client { Name = Rufus, [Address](/page/Address) = 192.168.1.10, Password = xxx }). These directives allow administrators to tailor the Director's behavior to specific environments while ensuring resource consistency.[16]
Administrators interact with the Director through the bconsole utility, a text-based console interface that provides real-time monitoring and control of Bacula operations. It supports essential commands such as status to display daemon or job statuses, run to initiate jobs manually, restore to perform recovery operations, list to query resources like volumes or clients, prune to remove expired catalog records, and estimate to predict backup sizes, among others like label, update, mount, and unmount for volume management. Access to bconsole requires password authentication matching the Director's configuration, with options for restricted consoles using access control lists (ACLs) to limit privileges.[16]
The Director integrates with a database backend via the Catalog resource to store and manage metadata essential for tracking backups, including job histories, file lists, volumes, and restore points. Supported databases include PostgreSQL and MySQL for robust production use, with SQLite available but deprecated due to scalability limitations; configuration specifies the database type, name, user credentials, and connection details (e.g., Catalog { Name = MyCatalog, dbname = bacula, user = bacula, password = xxx }). This integration enables the Director to catalog operations efficiently, supporting queries and reporting for long-term data management, with default statistics retention set to five years.[16]
Storage Daemon
The Storage Daemon (SD) in Bacula serves as the server-side component responsible for managing physical and virtual storage devices, acting as the interface that receives backup data from the Director and writes it to media such as tapes, disks, or cloud storage.[17] It handles data persistence by establishing sessions—either append sessions for writing new data or read sessions for restores—using TCP connections authenticated via JobId and a shared password, ensuring secure data transfer to the specified storage volume.[17] This design allows the SD to support multiple concurrent jobs on a single device through locking mechanisms, optimizing resource use in multi-device environments.[17] Configuration of the Storage Daemon is defined in thebacula-sd.conf file, which requires exactly one Storage resource for global settings like the working directory and PID file, alongside Director resources for communication endpoints and Device resources for storage hardware.[18] Device definitions include mandatory directives such as Name, Archive Device (e.g., /dev/nst0 for tapes or a directory path for disk files), and Media Type (e.g., "DLT7000" or "File"), enabling support for diverse hardware.[18] Autochanger support for tape libraries is configured by setting Autochanger = yes, specifying a Changer Device for the library interface, and defining a Changer Command (e.g., /usr/lib/mtx-changer %c %o %S %a %d) to handle slot operations like loading and unloading media.[18] Volume management integrates with the Director's catalog for labeling volumes via label or update commands, while mounting is automated with Always Open = yes (default) or controlled manually using mount and unmount directives to prepare media for jobs.[18]
The Storage Daemon supports a range of media types, including tape drives like LTO and DLT series for high-capacity archival, optical drives for write-once media, disk-based file storage for rapid access, and cloud storage via dedicated device types interfacing with APIs such as Amazon S3 or Microsoft Azure.[18] Labeling ensures volumes are uniquely identified and recyclable, with the SD enforcing mount checks to verify media integrity before writing, preventing data corruption on unlabeled or expired tapes.[18]
Error handling in the Storage Daemon incorporates retry logic through directives like Maximum Open Wait = 5 minutes (default), which allows the SD to pause and retry device access if a tape drive is busy or inaccessible, avoiding immediate job failures.[18] Alerting for media errors, such as tape drive issues, is enabled via the Alert Command (e.g., /opt/bacula/scripts/tapealert %l), which executes scripts to notify administrators of hardware faults per the SCSI Tape Alert specification.[18] Space management features include Maximum Volume Bytes (set in the Director but enforced by the SD) to cap volume sizes and prevent overflow, alongside a Spool Directory for buffering data during intermittent device errors, ensuring reliable persistence even under storage constraints.[18]
Performance tuning for the Storage Daemon focuses on optimizing data throughput and concurrency, with Minimum Block Size (default 0, up to 4,000,000 bytes) and Maximum Block Size (default 64,512 bytes) directives adjusting blocking factors to match device capabilities, such as larger blocks for tape drives to reduce overhead.[18] Buffer management is handled by Maximum Network Buffer Size (default 32,768 bytes, maximum 1,000,000), which controls data chunk sizes during transfers to balance memory use and speed on high-bandwidth networks.[18] Parallel job streams are supported via Maximum Concurrent Jobs (default 20 per Storage resource, configurable per Device), allowing multiple backups to run simultaneously on capable hardware like multi-drive libraries for scalable performance.[18]
File Daemon
The File Daemon, also known as bacula-fd, is a lightweight agent deployed on client machines to facilitate backup and restore operations by providing access to the local file system. It operates as a background service or daemon, listening on TCP port 9102 by default for connections from the Director, and requires minimal system resources due to its focused role in data handling without central management functions.[19] Configuration of the File Daemon is managed through the bacula-fd.conf file, which includes essential resources such as Client (defining the client name and working/pid directories), Director (specifying connections to one or more Directors with authentication details), and Messages (for logging). While FileSets for inclusion and exclusion rules are defined in the Director's configuration, the File Daemon enforces them during operations; supported compression algorithms for data transfer include zlib levels (e.g., GZIP1 for fast, low compression to GZIP9 for high compression), enabled via directives like CommCompression = yes in the Client resource. Encryption options are available through TLS configuration, including directives like TLSEnabled = yes, TLSCertificateFile, and TLSVerifyPeer to secure communications with the Director and Storage Daemon.[19] For backups, the File Daemon supports snapshot-based methods to ensure data consistency, particularly for open files and volumes. On Linux and Unix systems, it integrates with technologies like LVM, BTRFS, and ZFS to automatically create snapshots (enabled via Enable Snapshot = yes in the FileSet), with configurable snapshot sizes (default 10% of the logical volume) and retention periods to minimize performance impact during backups. On Windows, it utilizes Volume Shadow Copy Service (VSS) to create consistent snapshots of volumes, allowing backups of open files and application data without interruption, with support for concurrent VSS operations in recent versions.[20] Restore processes handled by the File Daemon enable selective file recovery, initiated through Director commands like the restore command in bconsole, where users can browse and select specific files or directories from previous backups. For bare-metal restores, Bacula generates a bootstrap file (.bsr) during the backup job, containing metadata on volumes and files needed for recovery; this file guides the restore without requiring a full catalog database, allowing reconstruction on a clean system by loading the appropriate volumes into the Storage Daemon. Resource limits in the File Daemon configuration help manage client-side performance, including Maximum Concurrent Jobs (default 20) to control simultaneous backup or restore sessions per client, and Maximum Bandwidth Per Job (specified in kb/s or mb/s) for throttling network usage to prevent overload. Additional limits like Maximum Job Error Count (default 1000) and Maximum Network Buffer Size (default 65,536 bytes, up to 1,000,000) ensure stability during high-load operations.[19]Features
Backup and Restore Capabilities
Bacula supports multiple backup levels to optimize data protection strategies, including full backups that capture all specified files and directories in a complete copy, incremental backups that record only changes since the last successful backup of any level, and differential backups that include all modifications since the most recent full backup.[16] These levels can be chained across volumes for efficient handling of large datasets, where the system automatically manages multi-volume jobs by linking sequential media in a pool, minimizing manual intervention during extended operations.[16] Backup scheduling, which determines the timing and sequence of these jobs, integrates seamlessly with the Director component to automate level progression, such as weekly differentials following monthly fulls. Restore operations in Bacula provide flexible recovery options, encompassing full system restores that rebuild entire environments from bootable media or automated scripts, file-level restores for selective recovery of individual files or directories via interactive console commands, and point-in-time restores that leverage the catalog database to query and retrieve data up to a specific timestamp or Job ID.[16] The catalog enables precise selection by filtering on attributes like file paths, modification dates, or sizes, ensuring accurate reconstruction without unnecessary data transfer.[16] Data deduplication is implemented through base jobs, which perform exact-match comparisons across backup sessions to exclude unchanged files, thereby reducing storage requirements by avoiding redundant copies of identical data blocks.[21] For integrity assurance, Bacula conducts post-backup verification using CRC32, MD5, or SHA1 hashes to detect corruption, with configurable options to compute and compare signatures during or after jobs.[16] Prune policies automate the removal of obsolete records and volumes based on retention periods defined in job resources, such as 60 days for file entries or 180 days for jobs, maintaining catalog efficiency and compliance with storage limits.[16] Advanced capabilities enhance Bacula's versatility, including multi-stream backups that parallelize data transfer for large files by spawning multiple concurrent streams per job, improving throughput on capable storage devices.[16] The plugin architecture extends support for application-specific backups, such as database dumps for MySQL via integrated scripts or dedicated plugins that handle quiescing, export, and import processes without disrupting live operations.[16] As of version 15.0 (2024), additional features include Zstandard compression support in FileSet resources for efficient data reduction, a Kubernetes plugin enabling backups of containerized environments using CSI Snapshots for persistent volumes, and integrated malware detection during backup and verify jobs using the abuse.ch URLhaus database to identify and report threats. An antivirus plugin for ClamAV further enhances verify jobs by scanning for viruses.[8]Scheduling and Resource Management
Bacula's scheduling capabilities are managed through the Schedule resource in the Director's configuration file, allowing administrators to automate job execution using time-based specifications that resemble cron-like patterns. These schedules define run times with masks for hours, days of the week, months, and other intervals, such as executing a full backup every Sunday at 2:05 AM or incremental backups daily at the same time.[16] The Run directive within a Schedule resource enables overrides for job parameters, including backup levels that progress from full to incremental or differential based on predefined cycles, ensuring systematic data protection without manual intervention.[16] Resource pools in Bacula group storage volumes and devices to allocate resources efficiently for different job types or priorities, preventing contention in multi-client setups. Defined in the Pool resource, these pools specify attributes like volume retention periods, maximum volumes, and recycling policies, with options for level-specific pools (e.g., separate pools for full versus incremental backups) to direct jobs to appropriate storage.[16] Limits on concurrent streams are enforced through directives such as Maximum Concurrent Jobs in the Job or Storage resources, capping the number of simultaneous writes to a device or pool to maintain performance and avoid overload.[16] Retention policies govern how long backup data and metadata are preserved, with configurable time-based or copy-based rules applied at the pool, job, or client level to automate data lifecycle management. Key directives include File Retention (default 60 days for file records), Job Retention (default 180 days for job records), and Volume Retention (default 365 days for volumes), enabling automatic pruning of expired entries via the AutoPrune option to free catalog space while retaining necessary records for restores.[16] Alerting and reporting features utilize the Messages resource to handle notifications for job events, including failures, with support for email delivery via SMTP through customizable MailCommand scripts that incorporate job details like name, status, and errors. Administrators can filter message types (e.g., errors, warnings, or all events) and route them to email recipients, log files, or the system console, with examples including sending detailed failure reports to specified addresses for timely intervention.[16] Priority queuing ensures efficient resource allocation in environments with multiple clients by assigning a Priority value (default 10, range 1-1000) to jobs, where lower numbers indicate higher priority and are processed first by the Director. The Allow Mixed Priority directive permits concurrent execution of jobs with varying priorities if set to yes, reducing wait times for critical tasks while queuing lower-priority ones to avoid system contention.[16] In version 15.0, the "status director" command limits output of scheduled jobs to 50 by default (configurable with "limit" parameter), and advanced job queue control allows RunScript integration for custom pre-job resource checks.[8]Network and Security Options
Bacula employs TCP-based communication protocols across its daemons, utilizing specific ports assigned by the Internet Assigned Numbers Authority (IANA) for secure and efficient data transfer in distributed environments. The Director daemon listens on TCP port 9101 for connections from consoles and other daemons, the File Daemon on port 9102 for backup and restore operations, and the Storage Daemon on port 9103 for data storage interactions.[22][23] These ports form the foundation for all inter-daemon communications, ensuring reliable network connectivity. Bacula supports IPv6 by default during compilation, allowing seamless operation in modern IPv6-enabled networks, though this can be disabled via the --disable-ipv6 configure option if compatibility issues arise with legacy IPv4-only infrastructure.[24][25] Firewall configurations must accommodate these ports, with incoming TCP traffic permitted on the respective daemon hosts to prevent connection failures.[26] For authentication and encryption, Bacula integrates Transport Layer Security (TLS) to secure all daemon-to-daemon communications, providing confidentiality and integrity similar to external tools like stunnel or SSH without requiring additional software. TLS is enabled through configuration directives in each daemon's resource files, such as TLS Enable = yes, which mandates encrypted channels for control and data flows. Certificate management involves specifying paths to X.509 certificates and private keys via directives like TLS Certificate = /path/to/cert.pem and TLS Private Key = /path/to/key.pem, with options for peer verification using TLS Verify Peer = yes to ensure mutual authentication. Self-signed certificates or those from a trusted Certificate Authority (CA) can be used, and pre-shared keys (PSK) are supported as an alternative when TLS-PSK Enable = yes, simplifying setup in trusted networks while maintaining encryption.[27][28][19] Access controls in Bacula are enforced primarily through the Director, which manages authentication via client-specific passwords defined in the Client and Director resources, preventing unauthorized daemon connections. For console users, Access Control Lists (ACLs) are configured within the Director's Console resource, restricting commands and resource visibility—such as limiting a user to specific clients or jobs via ACLs = client1,client2 or CommandACL = status,run. These ACLs provide granular permissions, ensuring that administrative access aligns with least-privilege principles. Passwords are protected using CRAM-MD5 challenge-response during authentication, avoiding plaintext transmission over the network.[29][30][31][32] Integration with VPNs and firewalls is facilitated through Bacula's firewall traversal guidelines, which address Network Address Translation (NAT) scenarios by configuring the Director to use external IP addresses for client connections via the FDAddress directive in Client resources. In NAT environments, where clients are behind firewalls, the File Daemon initiates outbound connections to the Director and Storage Daemon on ports 9101 and 9103, minimizing inbound port requirements; however, for Storage Daemon access, passive mode can be enabled to allow the daemon to accept connections from NAT-translated IPs. Secure tunnels are recommended for enhanced protection, with built-in TLS preferred over external VPNs, though stunnel can wrap communications if legacy encryption is needed. These configurations ensure reliable operation across segmented networks without exposing unnecessary ports.[26][33][34] Audit logging in Bacula captures detailed security events through the Director's event recording feature, which logs actions like job starts, authentication attempts, and configuration changes to the catalog database, flat files, or syslog for comprehensive tracking. These logs include timestamps, user IDs, and event types, enabling forensic analysis of security incidents. For compliance with standards like GDPR, Bacula supports encrypted storage of backups via TLS during transmission and optional file-level encryption in the File Daemon, ensuring personal data remains protected throughout its lifecycle in backup repositories.[8][35][36] As of version 15.0, security enhancements include Time-based One-Time Password (TOTP) console authentication plugin compliant with RFC 6238 for two-factor authentication, volume-level encryption in the Storage Daemon requiring encryption keys, new FileDaemon directives (AllowedBackupDirectories, AllowedRestoreDirectories, AllowedScriptDirectories) for restricting access, volume protection with Append Only and Immutable flags, and logging of security events for incorrect network connections. Hidden password information in plugin FileSets status output further improves security.[8]Supported Platforms
Server Platforms
Bacula's server-side components, primarily the Director and Storage Daemon, are designed to run on POSIX-compliant Unix-like operating systems, with full support for various Linux distributions, FreeBSD, and Solaris. Recommended Linux distributions include Ubuntu 22.04 LTS and later, Debian 11 and later, Red Hat Enterprise Linux (RHEL) 8 and later (including compatible systems like CentOS Stream, AlmaLinux, Rocky Linux, and Oracle Linux), and SUSE Linux Enterprise Server. FreeBSD versions 5.0 and above are supported, while Solaris requires version 8 or higher for compatibility. For optimal stability, deployments should use modern kernel versions aligned with these distributions, such as Linux kernel 5.15 or later, to ensure reliable POSIX system calls and threading support via pthreads.[37][38][39] Hardware specifications for hosting the Director and Storage Daemon emphasize scalability to handle concurrent backup jobs and catalog management. Storage requirements include at least 10 GB for the working directory (e.g., /opt/bacula/working) to accommodate temporary files, logs, and caching; the catalog requires approximately 150 bytes per backed-up file or object.[40][41] The Director relies on a backend database for cataloging backup metadata, with compatibility for MySQL 8.0 and later or PostgreSQL 12 and later, enabling robust indexing and querying of job histories. These databases must be configured with a dedicated "bacula" user account and appropriate permissions; for high-availability setups, clustering options like PostgreSQL's streaming replication or MySQL's Galera Cluster are supported, though they require additional configuration for failover and load balancing. SQLite is available for testing but not recommended for production due to concurrency limitations.[42][43][40] Bacula server components can be deployed in virtualized environments, including VMware vSphere, KVM-based hypervisors, and Docker containers, leveraging the software's portability across Unix-like systems. Running the Director or Storage Daemon in a VM or container allows for isolated resource allocation and easier management, with official support for Linux guests on these platforms; however, direct hardware access may be needed for tape autochangers in Storage Daemon setups.[44][45][46] Cloud deployments are facilitated on platforms like AWS EC2 instances and Azure Virtual Machines, where Bacula can utilize instance types such as AWS m5 or Azure D-series for balanced compute and storage. Bacula Enterprise (version 18.x as of 2025) supports integration with auto-scaling groups, enabling dynamic resource adjustment based on backup workload, with native drivers for cloud storage backends like S3 or Azure Blob for volume offloading.[47][48]Client Operating Systems
Bacula's File Daemon supports deployment on a variety of client operating systems, facilitating backups from diverse endpoints with native file system access where applicable.[37]Unix-like Systems
Bacula provides robust compatibility with Unix-like operating systems, enabling the File Daemon to access local file systems directly for efficient backups. GNU/Linux distributions receive the broadest support, encompassing all major variants such as Red Hat, Fedora, Debian, Ubuntu, Gentoo, and others, in both 32-bit and 64-bit configurations. Official binaries are distributed for Red Hat Enterprise Linux 7, 8, and 9 (and compatible systems like CentOS), Debian 11 and 12, and Ubuntu 22.04 and 24.04 LTS, ensuring seamless integration on contemporary server and desktop environments.[37][38] Solaris versions 8 and later are fully supported, allowing native backups of UFS and ZFS file systems. IBM AIX starting from version 4.3 and HP-UX across all versions are partially supported through community-contributed code, with successful compilations and operations reported but without official binaries or direct testing by the Bacula team.[37]BSD Variants and macOS
FreeBSD versions 5.0 and higher are fully supported, including compatibility with ZFS file systems on platforms where implemented. macOS, built on the Darwin kernel, receives full support across all versions, with the File Daemon capable of backing up HFS+ (and APFS via standard file access) file systems; specific configuration options like thehfsplus flag in FileSet resources enhance handling of macOS-specific attributes such as resource forks. ZFS support is available on macOS through third-party implementations like OpenZFS, allowing Bacula to perform file-level backups of ZFS datasets.[37][49][37]
Windows Compatibility
The Bacula File Daemon is available as a 64-bit binary installer for Microsoft Windows, supporting current Microsoft-supported client and server editions, such as Windows 10/11 and Windows Server 2019/2022. This enables backups of NTFS file systems and integration within Active Directory environments, where domain-joined clients can be backed up at the file level, including system volumes containing AD data (though granular object-level recovery of AD elements is not natively available in the community edition). Support for end-of-life Windows versions like XP, Vista, 7, and Server 2008 was aligned with Microsoft's termination of security updates, with emphasis on modern versions from Bacula 9.0 onward in 2017.[38][50][29][51]Embedded and Mobile Systems
Limited support exists for ARM-based architectures in embedded environments, such as NAS devices running Linux-based operating systems like Synology DSM. While no official binaries are provided, the open-source nature allows compilation and deployment on these platforms, with community reports confirming successful File Daemon operation for backing up shared storage volumes. Bacula does not provide official support for mobile operating systems such as Android or iOS. Older Unix variants predating the supported minimums (e.g., pre-Solaris 8 or early AIX) were effectively dropped as of Bacula version 9.0 in 2017, focusing resources on maintained systems.[52][53][37][51]Development and Community
History
Bacula was originally developed in 2000 by John Walker and Kern Sibbald as an open-source network backup solution aimed at providing enterprise-level data protection without the costs associated with proprietary software.[54] Sibbald, a physicist with experience in software development, became the primary developer after Walker left the project shortly thereafter, seeking to create a flexible, client-server based system for heterogeneous networks, drawing inspiration from commercial backup tools prevalent at the time. The project has benefited from contributions by a global community of developers, with ongoing enhancements driven by user feedback and collaborative efforts.[5] The project's initial release, version 1.0, arrived in 2002 and concentrated on core functionality for tape-based backups primarily targeting Linux environments.[55] This version established Bacula's architecture with separate daemons for the director, storage, and file operations, enabling automated backup, recovery, and verification across networks. Early adoption was driven by its GPL licensing, which allowed free distribution and modification, though the project faced challenges in gaining traction amid competition from established open-source alternatives like Amanda.[56] Subsequent milestones marked Bacula's expansion: version 2.0, released on January 4, 2007, introduced enhanced cross-platform support, including improved Windows client capabilities for broader heterogeneous network compatibility.[57] In 2009, the project transitioned from the GNU General Public License version 2 to the Affero GPL version 3 to better promote community contributions and prevent proprietary forks from diverging without upstream benefits.[58] Version 5.0 followed in January 2010, adding a more robust director console for interactive management and monitoring, solidifying Bacula's position as a viable open-source contender. These developments addressed early limitations in usability and platform reach while navigating ongoing rivalry from tools like Amanda in the open-source backup space.[59]Major Releases and Versions
Bacula's major releases from version 7.0 onward have introduced significant enhancements in storage management, security, and platform support, building on its core backup functionality to address evolving enterprise needs.[6] Version 7.0.0, released in February 2014, marked a key advancement with support for Storage Daemon-to-Storage Daemon transfers, enabling efficient replication and off-site data migration without client involvement. This release also improved Virtual Full backups for better consolidation of incremental jobs and added bandwidth limiting per job to optimize network usage. Additionally, it introduced configurable data encryption ciphers, including AES-128, AES-192, and AES-256, enhancing security for sensitive backups. While deduplication via base jobs was already available, version 7.0 refined migration and copy operations to support multiple simultaneous disk reads, accelerating deduplicated workflows by up to 10 times in certain scenarios. Cloud storage integration was further supported through existing plugins, allowing backups to services like Amazon S3, though not newly introduced in this version.[60][61][60] In July 2017, version 9.0.0 brought a major rewrite of the Storage Daemon for improved scalability and reliability, alongside the reintroduction of Windows source code and binaries, which enhanced compatibility with Microsoft environments. This included better integration with Windows Volume Shadow Copy Service (VSS) for consistent backups of open files and system states on newer Windows versions. Python scripting, a longstanding feature since earlier releases, saw continued support for custom automation of backup tasks, allowing administrators to extend job behaviors via scripts. The release also added Progressive Virtual Fulls via the "Backups To Keep" directive, enabling more flexible retention policies without manual intervention. A new tray monitor was introduced for simplified status monitoring across Director, File Daemon, and Storage Daemon components.[51][62][63] Version 11.0.0, launched in January 2021, focused on performance and security with a redesigned catalog database schema that eliminated the FileName table, significantly boosting query speeds for large-scale deployments exceeding 50 GB. Automatic TLS encryption became default for all network communications starting in version 11.0.0, simplifying secure setups and supporting modern protocols like TLS 1.2 with options for pre-shared keys (PSK). Native support for ARM64 architectures was enabled, broadening compatibility with devices like Raspberry Pi and ARM-based servers. Other enhancements included support for clients behind NAT via the "Connect To Director" directive and a Continuous Data Protection plugin for near-real-time backups.[64][65][66] The 13.0.0 release in July 2022 introduced the Kubernetes plugin, enabling backup and restore of cluster resources such as configurations and deployments, with granular recovery options for individual components. It added "Storage Group" support for organizing volumes and a new Accurate mode to backup only file ACLs and metadata, reducing storage overhead. Windows Cluster Shared Volumes (CSV) gained native support, and catalog objects could now use tags for better management. Security was bolstered with SHA-256 and SHA-512 signature options in FileSets, along with external LDAP console authentication. No AI-driven anomaly detection was included, but the release emphasized orchestration improvements for containerized environments.[67][68][69] As of November 2025, the latest major release is 15.0.3 from March 2025, which incorporates volume encryption, ZSTD compression for efficient data handling, and an improved installation manager for streamlined deployments. This version builds on prior Kubernetes support and adds new plugins for enhanced cloud and container integration. Bacula maintains a cadence of major releases approximately every 1-2 years via the official website and SourceForge, with quarterly bug fixes and security patches to address vulnerabilities promptly.[38][70][6]Forks and Derivatives
Bacula has spawned several notable forks and derivatives, primarily driven by efforts to address perceived limitations in the community edition's development pace and feature integration. The most prominent fork is Bareos, initiated in 2010 by Bacula community developer Marco van Wieringen as a branch from Bacula version 5.2.[71] This project incorporated rejected community patches and contributions that were not merged into the mainline Bacula, aiming to foster more rapid, open-source-driven enhancements.[71] Bareos has since evolved independently under the AGPLv3 license, introducing key additions such as the Bareos Web User Interface for streamlined management, an expanded plugin ecosystem including Python-based plugins for databases like PostgreSQL and virtualization platforms like VMware, and support for diverse storage backends such as GlusterFS and tape libraries.[71][72] It also offers commercial support through Bareos Subscriptions provided by Bareos GmbH & Co. KG.[71] As of November 2025, Bareos maintains active development with its latest stable release being version 24.0.7, released on October 31, 2025, featuring bug fixes and improvements like enhanced NDMP and VMware plugin support.[73] Another significant derivative is Bacula Enterprise, a proprietary extension developed by Bacula Systems SA since the company's founding in 2008.[74] This branch builds on the open-source core but incorporates exclusive features tailored for enterprise environments, including pre-configured backup appliances for simplified deployment and 24/7 professional support services to ensure high availability and rapid issue resolution.[75] It emphasizes scalability for large-scale data centers, with advanced capabilities like dynamic workload distribution across multiple workers for handling billions of files.[75] These forks emerged largely due to disagreements over licensing terms for contributions and gaps in the community edition, where certain enhancements were withheld for proprietary development.[71] In the current landscape as of 2025, Bareos has established itself as a leading alternative through its consistent release cadence, backward compatibility layers with Bacula configurations, and growing adoption in open-source communities seeking robust, vendor-neutral backup solutions.[76]Implementation Considerations
Configuration and Deployment
Bacula can be installed using several methods, depending on the target platform and deployment needs. For Linux distributions, binary packages are available via package managers such as apt for Debian-based systems or yum/dnf for Red Hat-based systems, providing the simplest approach for supported versions like Ubuntu and CentOS.[77] These packages include pre-compiled binaries for the Director, Storage Daemon, File Daemon, and Console, along with dependencies like MySQL or PostgreSQL for the catalog.[77] Compilation from source is recommended for custom builds or unsupported platforms, requiring prerequisites such as development tools, a database server, and libraries like readline and acl.[77] The process involves downloading the source tarball, running./configure with options (e.g., --enable-client-only for file daemons or --with-mysql for database support), followed by make and make install.[77] Community-maintained Docker images, such as those from the fametec/bacula repository, enable containerized deployments for easier portability and isolation, typically involving pulling the image and running containers for each daemon with volume mounts for configuration and data.[78]
Initial setup begins with configuring the daemons after installation. Configuration files are typically placed in /etc/bacula/ or a custom directory specified during compilation, with the Director's file at bacula-dir.conf.[77] To initialize the database, create a dedicated database and user (e.g., via mysql commands for MySQL: CREATE DATABASE bacula; GRANT ALL ON bacula.* TO 'bacula'@'localhost' IDENTIFIED BY 'password';), then execute the provided SQL scripts like create_mysql_database and make_catalog_tables from the source or package directory.[77] Start the daemons using systemd services (e.g., systemctl start bacula-dir bacula-sd bacula-fd) or manually with ./bacula start in the installation directory, ensuring inter-daemon passwords match across configurations.[79] For secure communication, generate SSL certificates using tools like OpenSSL and configure TLS options in the relevant resources, though basic setups can omit this initially.[29]
A minimal bacula-dir.conf for a single-server setup includes essential resources for basic operation. The Director resource defines the service's identity and paths:
Director {
Name = bacula-dir
DIRport = 9101
QueryFile = "/etc/bacula/scripts/query.sql"
WorkingDirectory = "/var/lib/bacula"
PidDirectory = "/var/run/bacula"
Maximum Concurrent Jobs = 1
Password = "your-director-password"
Messages = Standard
}
Director {
Name = bacula-dir
DIRport = 9101
QueryFile = "/etc/bacula/scripts/query.sql"
WorkingDirectory = "/var/lib/bacula"
PidDirectory = "/var/run/bacula"
Maximum Concurrent Jobs = 1
Password = "your-director-password"
Messages = Standard
}
Storage {
Name = File
Address = 127.0.0.1
Password = "your-storage-password"
Device = FileStorage
Media Type = File
SDPort = 9103
}
Storage {
Name = File
Address = 127.0.0.1
Password = "your-storage-password"
Device = FileStorage
Media Type = File
SDPort = 9103
}
Job {
Name = "BackupClient"
Type = Backup
Level = Full
Client = bacula-fd
FileSet = "Full Set"
Storage = File
Messages = Standard
Pool = Default
Priority = 10
Write Bootstrap = "/var/lib/bacula/%c.bsr"
}
Client {
Name = bacula-fd
Address = 127.0.0.1
FDPort = 9102
Catalog = MyCatalog
Password = "your-client-password"
AutoPrune = yes
File Retention = 30 days
Job Retention = 6 months
Maximum File Jobs = 1
}
FileSet {
Name = "Full Set"
Include {
Options {
signature = [MD5](/page/MD5)
Compression = [GZIP](/page/Gzip)
}
File = /
}
Exclude {
File = /var/lib/bacula
File = /proc
File = /sys
File = /tmp
}
}
Schedule {
Name = "WeeklyCycle"
Run = Level=Full sun at 03:00
}
Pool {
Name = Default
Pool Type = [Backup](/page/Backup)
Recycle = yes
AutoPrune = yes
Volume Retention = 365 days
Maximum Volume Bytes = 50G
Maximum Volumes = 100
Label Format = "Vol-"
}
Catalog {
Name = MyCatalog
DBName = bacula
DBUser = bacula
DBPassword = "your-db-password"
}
Messages {
Name = Standard
mailcommand = "/usr/sbin/bsmtp -h localhost -f \"$Bacula$ %r\" -s \"Bacula: %t %e of %c %l\" %r"
operatorcommand = "/usr/sbin/bsmtp -h localhost -f \"$Bacula$ %r\" -s \"Bacula: Intervention needed for %j\" %r"
mail = root@localhost = all, !skipped
console = all, !skipped, !saved
append = "/var/log/bacula/bacula.log" = all, !skipped
catalog = all
}
Job {
Name = "BackupClient"
Type = Backup
Level = Full
Client = bacula-fd
FileSet = "Full Set"
Storage = File
Messages = Standard
Pool = Default
Priority = 10
Write Bootstrap = "/var/lib/bacula/%c.bsr"
}
Client {
Name = bacula-fd
Address = 127.0.0.1
FDPort = 9102
Catalog = MyCatalog
Password = "your-client-password"
AutoPrune = yes
File Retention = 30 days
Job Retention = 6 months
Maximum File Jobs = 1
}
FileSet {
Name = "Full Set"
Include {
Options {
signature = [MD5](/page/MD5)
Compression = [GZIP](/page/Gzip)
}
File = /
}
Exclude {
File = /var/lib/bacula
File = /proc
File = /sys
File = /tmp
}
}
Schedule {
Name = "WeeklyCycle"
Run = Level=Full sun at 03:00
}
Pool {
Name = Default
Pool Type = [Backup](/page/Backup)
Recycle = yes
AutoPrune = yes
Volume Retention = 365 days
Maximum Volume Bytes = 50G
Maximum Volumes = 100
Label Format = "Vol-"
}
Catalog {
Name = MyCatalog
DBName = bacula
DBUser = bacula
DBPassword = "your-db-password"
}
Messages {
Name = Standard
mailcommand = "/usr/sbin/bsmtp -h localhost -f \"$Bacula$ %r\" -s \"Bacula: %t %e of %c %l\" %r"
operatorcommand = "/usr/sbin/bsmtp -h localhost -f \"$Bacula$ %r\" -s \"Bacula: Intervention needed for %j\" %r"
mail = root@localhost = all, !skipped
console = all, !skipped, !saved
append = "/var/log/bacula/bacula.log" = all, !skipped
catalog = all
}
-t flag, such as bacula-dir -t -c /etc/bacula/bacula-dir.conf; absence of errors confirms validity.[79] For dry-run-like testing, use the estimate command in bconsole to simulate job resource needs without executing a backup: connect via bconsole, then estimate job=BackupClient listing=yes. Label volumes through bconsole with the label command, e.g., label storage=File pool=Default volume="Vol-0001", which adds the volume to the pool and prepares it for use. Register clients by installing the File Daemon on the target machine, configuring bacula-fd.conf with the Director's address and a shared password, then adding a Client resource to bacula-dir.conf and restarting the Director.[79] Run a test backup job via bconsole (run job=BackupClient yes) and verify completion in the logs at /var/log/bacula/bacula.log.[79]
For automated deployments, Ansible playbooks are recommended in current documentation for provisioning across multiple hosts. The official Bacula Community Ansible Collection provides roles for installing the Director (with PostgreSQL/MySQL catalog), File Daemon, and Storage Daemon, usable via ansible-galaxy collection install bacula-community.bacula.[80] Example playbooks define variables for hosts, passwords, and database setup, then apply roles like bacula-community.bacula_director to idempotently configure and start services; for 2025 environments, integrate with inventory files for multi-site scaling.[80]