Bareos vs Bacula: when each one is the right choice
For a team already running Bacula, moving to Bareos is a common next step when the priorities are an AGPLv3 license with no open-core restrictions, a WebUI and plugins that fit a mixed Linux, Windows, FreeBSD and macOS estate. Staying on Bacula makes more sense when the existing Director configuration, catalog and restore procedures are stable, the team already has a support contract with Bacula Systems, or Bacula Enterprise features are already in use. Bareos is a fork of the Bacula source code, so the two share the same Director, Storage Daemon and File Daemon model, which keeps the decision mostly about support, plugins and release cadence rather than a rewrite of the backup design.
Start with the commercial support path, because it determines who you call when a restore fails. Bareos support depends on a Bareos subscription, which provides tested packages for major Linux distributions, Windows and macOS through separate subscription repositories, along with subscription-only plugins. Bacula Enterprise is the commercial version offered by Bacula Systems, which provides support, services and training. Ask each vendor for the scope of support, the platforms covered, the plugin list and whether the quote includes upgrade assistance. Prices for Bareos subscriptions are provided by quote, so get the written terms before comparing totals. Then inventory your plugins. Confirm which hypervisor, database and NDMP or SAN integrations your jobs depend on, and check each one against the Bareos documentation and Bacula's own documentation at bacula.org. Bacula community license terms and feature parity must be confirmed against Bacula's own documentation before you rely on them in either direction.
Release line expectations and migration effort are the last checks. Bareos 25.1.1 was published on September 3, 2026, alongside maintenance releases 24.0.11 and 23.1.8, so confirm which branch your support contract covers and how long each one is maintained. Check the same for your current Bacula release line, including the stable 15.0.x line that lists 15.0.3. Migration effort is driven mainly by the catalog and the job definitions: test a restore of an existing volume on a Bareos instance before you retire the old Director, and confirm that the PostgreSQL catalog schema, storage volumes and client configurations carry over as expected. Plan a parallel run so that both systems can restore older backups during the retention window.
Which backup system fits which scenario
This table maps common Bacula and Bareos situations to the option that fits best and the condition that decides it. Read each row against your own licensing, support and migration constraints, since the right answer often changes when one condition flips.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Bacula-only shop with no migration appetite | Stay on Bacula | Your team already runs Bacula reliably, the Bacula Enterprise support path meets your needs, and a move would add change risk without a requirement that Bacula cannot meet. |
| Bacula shop that wants AGPL code and a subscription-backed support path | Bareos | You want AGPLv3 code without open-core restrictions and a vendor support route from Bareos GmbH, and you can plan a migration of catalog, jobs and clients. |
| New deployment choosing between the two | Bareos, after a proof of concept | You want the WebUI, documented plugins for VMware vSphere, Hyper-V and Proxmox, and S3-compatible storage targets, and you will test restores against your own workloads first. |
| Proxmox-heavy estate that needs VM plugins | Bareos | Your requirement is a general network backup system with a Proxmox plugin alongside physical hosts, tape or file-level jobs, not Proxmox-native deduplicated VM backups alone. |
| Tape-heavy environment | Bareos or Bacula, confirm per drive model | Both descend from the same Director, Storage Daemon and File Daemon design. Confirm your specific tape library and drive support with each vendor before choosing. |
| Regulated team that needs documented support | Bareos with a subscription | Subscriptions include subscription repositories with complete version history and subscription-only plugins, and are a prerequisite for support. Ask for the support scope in writing and confirm it matches your audit evidence needs. |
| Encryption and access control requirements | Confirm with both projects | Bareos documents encrypted communication, backup encryption and role-based ACLs for commands and objects. Verify the equivalent controls in your target Bacula edition before deciding. |
How the Director, Storage and File Daemons and Catalog fit together
Bareos splits control, data movement and indexing into separate services, and each one has its own failure mode and check. Bacula uses the same basic design, so the operational questions below apply to both, and the component-level details should be confirmed against the Bacula documentation before you assume they match.
Director schedules every job
The Director is the scheduling and control service. It runs backup, restore, verify and archive jobs, and it decides which File Daemon and Storage Daemon each job uses. Check that the Director configuration is version-controlled and that its schedules, pools and client definitions are reviewed after every change, because a single Director defines the whole estate's backup behavior. Confirm with Bacula's documentation how the equivalent scheduling resources are named and structured before migrating configuration files.
Storage Daemons write to media
Storage Daemons receive data from File Daemons and write it to disk, tape or S3-compatible object storage. Plan storage locations per site or workload, since a restore depends on the Storage Daemon and media that hold the data. Test restores from each target type, including tape handling and object storage credentials, rather than assuming a successful backup job means a recoverable one.
File Daemons run on each client
A File Daemon is installed on every protected machine and reads its data for the Director's jobs. It adds operational scope: each client needs a supported operating system build, network reach to the Director and Storage Daemon, and matching version management. Track which clients run which File Daemon release, because a fleet with mixed versions makes upgrades and troubleshooting harder. Plugins for hypervisors and databases run through this layer as well.
Catalog depends on PostgreSQL
The Catalog stores file indexes and volume records, and Bareos runs it on PostgreSQL. PostgreSQL must be running before the Catalog service starts, so startup order and database availability belong in your runbook. Back up the Catalog database on its own schedule and test that you can rebuild Bareos service state from it. Confirm the supported PostgreSQL versions for your Bareos release in the Bareos documentation before you choose a database version.
bconsole and bareos-webui for operators
bconsole is the text console for direct control of the Director, and bareos-webui is the web interface for monitoring and managing jobs. Teams used to Bacula's console will find the command workflow familiar, but they should confirm which console commands and WebUI features their release provides. Restrict console and WebUI access with role-based ACLs, since operators can trigger restores of any client they are allowed to see.
Storage targets set the restore path
Bareos writes to disk, tape or S3-compatible object storage, and the deduplicating storage formats it supports include ZFS, VDO and btrfs. The target determines restore speed, retention cost and what you must replicate off site. Ask which target your backup window and restore objectives depend on, and confirm the object storage compatibility with the Bareos documentation for the release you plan to run.
Bareos vs Bacula feature by feature
This table compares Bareos and Bacula on license, vendor support, interface, plugins, recovery, security, storage formats and release status. Where the Bareos column reflects documented capabilities, the Bacula cell lists what to confirm with Bacula Systems or the Bacula documentation, so use those items as a checklist for your own edition and vendor call.
| Capability | Bareos | Bacula |
|---|---|---|
| License | AGPL-3.0-only with no open-core restrictions, according to the Bareos README and copyright file | Open source per bacula.org. Upstream code moved from GPLv2 to AGPLv3 in 2010. Confirm current terms for your edition |
| Commercial vendor and support | Bareos GmbH sells subscriptions with tested packages and support, priced by quote | Bacula Systems sells Bacula Enterprise with support, services and training. Confirm community support options directly |
| WebUI | bareos-webui web interface on top of the Director and bconsole | Confirm whether a web interface ships with your edition and what operations it covers |
| Plugins for VMware vSphere, Hyper-V and Proxmox | Plugins cover these hypervisors, with some plugins limited to subscriptions | Confirm plugin coverage for each hypervisor with Bacula Systems or the Bacula documentation |
| NDMP SAN backups | Supported, according to the Bareos README | Confirm NDMP support, supported versions and licensing in the Bacula documentation |
| Bare-metal and Windows recovery | Relax-and-Recover for Linux bare metal and Barri for Windows disaster recovery | Confirm bare-metal and Windows disaster recovery options with Bacula Systems |
| Encryption and role-based ACLs | Encrypted communication, backup encryption and role-based ACLs for commands and objects | Confirm encryption options and access control model for the edition you plan to run |
| Always Incremental and deduplicating storage | Always Incremental for file backups. Stores on disk, tape or S3-compatible storage in formats suited to ZFS, VDO or btrfs | Confirm an Always Incremental equivalent and which deduplicating storage formats are supported |
| Latest supplied release | 25.1.1, published September 3, 2026, with maintenance releases 24.0.11 and 23.1.8 | 15.0.3 listed on bacula.org in the stable 15.0.x line. Confirm the current release before planning |
What the AGPL history means for a Bacula codebase
The Bareos community edition is the open-source project itself. Bareos describes its software as licensed under AGPLv3 without open-core restrictions, so the features in the public code are not held back for a paid tier. Its files carry the copyright of Bareos GmbH & Co. KG and are published under AGPL-3.0-only, which means you read the code, run it, modify it and share changes under the same license terms.
- No open-core split: the public repository is the full product, with no feature gated behind a commercial license key.
- Public releases: the project publishes releases on GitHub, with Bareos 25.1.1 published on September 3, 2026 alongside maintenance releases 24.0.11 and 23.1.8.
- Community repository: packages for the community track are fetched from the public download repository, which is separate from the subscription repositories.
- Self-support: without a subscription, you rely on the documentation, the project and your own staff or partner for troubleshooting.
- Platform coverage: the README lists Linux, Windows, FreeBSD and macOS as supported platforms.
Before you rely on the community track for production, confirm the package sources, release cadence and support expectations for your exact operating systems with the Bareos project.
A Bareos subscription is a commercial agreement with Bareos GmbH that sits alongside the AGPL code. It does not change the license of the software. What it adds is access to subscription repositories, which provide tested packages for major Linux distributions, Windows and macOS, along with complete version history. Subscription repositories are kept separate from the public community repository, so your installation source changes when you move to a subscription.
- Tested packages: the subscription repositories carry packages for major Linux distributions, Windows and macOS.
- Version history: the subscription repositories offer the complete version history rather than only current builds.
- Subscription-only plugins: some plugins are available only to subscribers, so check the plugin list for your hypervisors and workloads.
- Support prerequisite: a subscription is a prerequisite for Bareos support.
- Quoted pricing: prices are provided by quote, so the cost depends on the scope you request.
Ask for the subscription terms in writing, including which plugins are included, which operating systems are covered and how the repositories are accessed.
Bacula is the project Bareos forked from. The Bacula code changed from GPLv2 to AGPLv3 on July 24, 2010, which is the license baseline Bareos inherited and extended. Bacula.org describes Bacula as a set of open-source programs for backup, recovery and verification across a network, and lists Bacula 15.0.3 in the stable 15.0.x line. Any Bacula shop should read the license history for the specific release it runs, since older installations may have been built from code under different terms.
- License change: the code moved from GPLv2 to AGPLv3 on July 24, 2010, which affects how network-hosted modifications must be shared.
- Stable line: Bacula 15.0.3 is listed in the 15.0.x stable line on the project site.
- Shared lineage: the Bareos codebase shares its origin with Bacula, so architecture concepts such as the Director, Storage and File Daemons carry over.
- Diverging code: the two projects now develop separately, so a feature or patch in one does not automatically appear in the other.
- Terms to confirm: check the current community license and redistribution terms directly with the Bacula project.
Confirm the community license terms and the exact release you run before deciding whether your modifications, if any, require source disclosure.
Bacula Enterprise is the commercial version of Bacula offered by Bacula Systems, which provides support, services and training. The supplied information does not describe its license model, package delivery, plugin set or support tiers in detail, so treat any comparison with Bareos subscriptions as a question to answer in writing rather than an assumption. Compare the two commercial offers on the same list of deliverables.
- Vendor and scope: Bacula Systems provides the commercial product along with support, services and training.
- Package delivery: confirm how Bacula Enterprise packages are distributed and whether they cover your operating systems.
- Plugins and features: ask which hypervisor, database and workload integrations are included and which carry extra cost.
- Support terms: ask for response expectations, supported versions and the escalation path in the contract.
- Training and services: check whether training or professional services are bundled or priced separately.
Ask Bacula Systems for a written list of what Bacula Enterprise includes, and compare it line by line with the Bareos subscription scope you receive in the quote.
Release lines and what a Bacula shop risks by moving to Bareos
The first decision is which release line to run, and the supplied version facts make that choice deliberate. Bacula.org lists Bacula 15.0.3 as a release in the stable 15.0.x line. Bareos 25.1.1 was published on September 3, 2026, together with maintenance releases 24.0.11 and 23.1.8, so Bareos maintains several lines at once. A shop moving over should not simply take the newest number. Match the line to your change calendar, confirm which fixes each line receives, and read the release notes for every version between your current release and your target on the Bareos GitHub releases page. Confirm there that configuration and catalog changes are listed before you schedule the move.
The main risks sit in three places: configuration, catalog and plugins. Bacula and Bareos share a common origin, but the Director configuration, the Storage and File Daemon settings, and the schedules and pools built on them must be migrated and tested as a change in their own right. Check each resource directive against the Bareos documentation and confirm what the target version accepts before the Director starts. The Bareos Catalog runs on PostgreSQL, and that database holds the file indexes and volume records you need to restore anything. Ask whether the catalog schema requires a migration, how that migration is applied and whether it can be rolled back. Plugin behavior is the third risk. Check the version, options and licensing of each hypervisor and database plugin you use, because Bareos offers some plugins only through subscription.
Test restores on the target version before you commit to it. Take a copy of the catalog, point a test Director at it and restore representative jobs: a file-level restore, a full restore of a virtual machine and a restore of a volume written before the upgrade. Time each restore, record every step that needed manual intervention and keep the existing Bacula Director available until those restores succeed. If you plan to buy support, note that the Bareos subscription page states that subscriptions are a prerequisite for support and that subscription repositories are separate from the public community repository. Confirm which repository your packages come from before cutover, and get the support scope for your chosen line in writing.
What drives backup running cost on each platform
Bareos and Bacula both start from free source code, so most of the running cost sits outside the license. The cards separate the fees you pay a vendor from the infrastructure, storage and staff time you carry yourself, and mark which items recur and which are paid once.
Software license and community use
Bareos is licensed under AGPLv3 without open-core restrictions, so running the community edition carries no license fee. Bacula's code also moved to AGPLv3 in 2010, but confirm the current Bacula license terms and which features sit only in Bacula Enterprise before you assume parity. The cost you still carry is the staff time to operate a community build, which a license review will not show. Ask both vendors to confirm in writing which components fall under which license.
Bareos subscription pricing
A subscription quote is the main recurring vendor fee on the Bareos side. Subscriptions are a prerequisite for Bareos support and provide tested packages for major Linux distributions, Windows and macOS through repositories separate from the public community download, along with subscription-only plugins. Prices are by quote only, so the quote should list covered platforms, plugins, support terms and the renewal period. Confirm that the plugins you need for hypervisors and databases are in scope.
Bacula Enterprise support and services
Bacula Systems sells Bacula Enterprise and offers support, services and training alongside it. These are the recurring vendor costs on the Bacula side, and the price is set by quote. Ask which features are Enterprise only, whether support covers your operating systems and plugin mix, what training is included, and whether services are one-time engagements or ongoing. Compare that scope line by line with any Bareos subscription quote before deciding.
Catalog database infrastructure
Bareos keeps its Catalog of file indexes and volumes in PostgreSQL, which must be running for the Catalog service to work. That database carries its own hosting, sizing, patching, backup and failover costs, and it usually grows with file counts and retention. Plan for a catalog that you can back up and restore independently of the data it indexes. Confirm the database options and their support status for Bacula with Bacula Systems before comparing the two.
Storage capacity and deduplication
Bareos writes to disk, tape or S3-compatible object storage, in a format designed for deduplicating storage such as ZFS, VDO or btrfs. Always Incremental schemes reduce how often full backups run, which lowers the capacity you buy. The largest recurring storage cost is usually retention multiplied by change rate, so set retention per job class and measure your own deduplication ratio before sizing hardware or object storage contracts. Run the same test data through Bacula to compare results.
Operator time and upgrade testing
Operator time is easy to underestimate. Each Bareos component, from the Director and Storage Daemons to File Daemons on every client, plus bconsole and the WebUI, needs configuration, monitoring and restore drills. Release lines such as 25.1.1, alongside maintenance releases 24.0.11 and 23.1.8, mean your upgrade calendar must match the line you run. Budget staff time for test restores after every upgrade, and ask the vendor how long each line receives fixes.
Moving a Bacula estate to Bareos without losing restore points
This sequence moves a Bacula estate to Bareos in controlled stages, so every existing volume stays restorable until its retention period ends. Each step closes with a check that proves the next one is safe to start.
Inventory jobs, pools, volumes and clients
Export the current Director configuration, job definitions, schedules, pool settings, storage definitions and client resources, and list every volume with its status, media type and retention. Record which File Daemons, plugins and storage devices each job depends on. The inventory is done when every job can be traced to a client, a pool, a storage device and a retention rule, and the team has a written list of what must survive the move.
Confirm plugin and storage parity
Check each plugin, storage target and format in use against the Bareos documentation and the Bareos README, which list the supported virtual environment plugins, tape and S3-compatible object storage. Ask the vendor or your own test environment to confirm any plugin version your jobs rely on, because a feature listed for Bareos may not match the exact Bacula release you run. The step closes with a parity table marking each item as supported, needs a replacement, or needs confirmation.
Stand up a Bareos Catalog on PostgreSQL
Build a new Bareos Catalog on PostgreSQL in parallel with the running Bacula Catalog, since the Bareos documentation states that PostgreSQL must be running for the Catalog service. Keep the new Catalog on separate hosts or a separate database so the production Bacula Catalog is not altered. The step is complete when the Catalog service starts, accepts connections and passes a basic test job against a non-production client.
Run test restores from existing volumes
Import or reference a copy of existing volumes in a test environment and restore a sample of files, directories and full jobs from each job type, including any plugin-based and tape restores. Compare restored content with checksums or known file lists, and confirm that restore jobs complete on the Bareos Director. Whether old volumes can be read directly depends on format compatibility, so confirm that with your own test restores before relying on it. The step closes when every job type has at least one verified restore.
Migrate File Daemons and schedules in batches
Move clients to Bareos File Daemons in small groups, starting with non-critical hosts, and recreate their client resources and schedules in the Bareos Director. Run a full backup and a restore test for each batch before moving the next group, and keep the Bacula client definition in place until the batch has passed. The batch is complete when its first scheduled backup and its test restore both finish successfully and are recorded in the catalog.
Rebuild configuration, WebUI and access roles
Recreate Director configuration, the bareos-webui setup and role-based ACLs for commands and objects, because these are rebuilt rather than carried across. Assign operators only the commands and client scopes they need, and document the mapping from old Bacula console users to new Bareos roles. The step closes when each operator logs in, runs their permitted actions and is denied the actions outside their role.
Keep old restore paths until retention ends
Leave the Bacula Director, Storage Daemons and Catalog running in read-only mode, and keep the old volumes and their media accessible until the longest retention period in the inventory has expired. Schedule a dated review that confirms no restore request is pending against the old system, and document how to restore from it if a request arrives. The sequence is complete when the old system is retired by a signed-off decision that cites the inventory and the last successful test restore.
Where Bareos and Bacula implementation projects usually run long
Projects usually run long at the catalog, the storage targets and the restore tests, not at the first successful backup. Installing the Director, a Storage Daemon and a File Daemon on one client is quick. The effort comes from the Catalog, which runs on PostgreSQL and must be up for the Director to schedule or record anything. Plan for PostgreSQL operations as a standing task: backup and restore of the catalog database itself, retention and pruning of file records as the job count grows, and monitoring of its disk and connection use. Ask whether the client's team already runs PostgreSQL at this level, because a team new to it will add weeks of learning to the schedule, and confirm the sizing with Bareos and your own job volumes before work starts.
Storage target design is the second long-running item. Bareos can write to disk, tape or S3-compatible object storage, and the layout of Storage Daemon devices, pools and volumes decides how restores and retention behave. Tape handling is the usual overrun: labeling, media rotation, off-site movement and drive compatibility each need a named owner and a test. Client rollout also multiplies work across Linux, Windows, FreeBSD and macOS, since each platform has its own File Daemon packaging and its own configuration habits. Plugin configuration for hypervisors and databases adds per-workload credentials and job definitions. Confirm with Bareos which plugins your estate needs and whether they sit in the subscription repositories.
Restore validation and access role design are where schedules slip most often. A job that reports success has not proven that data can be restored to a usable state, so build scheduled restore tests for files, a database and a VM, and record the time each one takes. Role-based ACLs for commands and objects also need decisions before go-live: which operators may run restores, which may change retention, and who holds the Director console credentials. Effort depends on your environment, your recovery objectives and vendor confirmation of supported configurations. DeployOpen scopes implementation work of this kind in writing before any work starts, so ask for the storage, catalog and restore-test items to be listed as separate deliverables.
Questions buyers ask before choosing Bareos or Bacula
Is Bareos a drop-in replacement for Bacula?
Not automatically. Bareos is a fork of the Bacula source code, so the two share a general architecture of a Director, Storage Daemons, File Daemons and a Catalog, but they have diverged since the fork. Configuration files, job definitions, plugins, catalog details and console behavior need to be compared against your current setup before you assume anything carries over. Treat the move as a migration with a test environment, not a package swap. Ask Bareos GmbH and your Bacula distributor to list which settings and integrations differ for your version, and test restores before you cut over.
What does a Bareos subscription include and how is it priced?
The subscription provides tested packages for major Linux distributions, Windows and macOS through subscription repositories that carry the complete version history, plus subscription-only plugins. It is also a prerequisite for Bareos support. Bareos publishes no fixed price on its subscription page: prices are given by quote. Ask for a written quote that lists the number of protected systems or the licensing unit, which plugins are included, the support level, the repository access period and whether renewals are one-time or recurring. Compare that against any Bacula Enterprise quote on the same scope, since both are priced individually.
Is the community edition enough for a production backup estate?
It can be, depending on what you need from the vendor. Bareos is licensed under AGPLv3 without open-core restrictions, so the core software is available without a paid tier. What the community route does not include is the subscription repository, the subscription-only plugins and vendor support. Decide whether your team can own package testing, security patch tracking, plugin maintenance and incident response internally. If it can, the community build may suit you. If it cannot, price a subscription against the internal effort it replaces.
How long does a migration from Bacula to Bareos take, and what drives it?
No duration is established here, so ask each party for a scope-based estimate. The effort depends mainly on the size of the catalog, the number of File Daemons and clients, the plugins and integrations in use, the volume of retained media, and the restore and retention requirements you must keep meeting during the move. Systems that rely on custom scripts, tape libraries or database-specific plugins take longer to validate. Ask for a plan that covers a parallel run, restore tests for representative jobs and a rollback path before any production cutover.
What does a Bareos move require from the internal team?
Your team needs working knowledge of the Director, Storage Daemons, File Daemons and Catalog, plus PostgreSQL, because the Bareos catalog runs on PostgreSQL and that service must be running. Someone must also own the Linux and Windows client rollout, backup encryption keys, role-based ACLs for commands and objects, and the restore runbooks. Plan for people who understand your retention policies and your recovery time expectations, since the platform will not decide those for you. Ask your provider which of these tasks they run and which they hand over.
Can our team migrate to Bareos without outside help?
It is possible for a team with Bacula experience and a non-production test environment, especially for a small estate with standard file backups. Teams with large catalogs, many plugins, tape libraries or strict restore obligations usually find the cutover and validation work is where mistakes happen. Be honest about your team's capacity during the change window. Fixed-scope help can cover planning, implementation, testing and documentation, with the scope and deliverables agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so you can decide which parts to keep in house.
Which Bacula release line should we compare against Bareos?
Compare current versions on both sides before deciding. Bacula.org lists Bacula 15.0.3 in the stable 15.0.x line, and Bareos 25.1.1 was published on September 3, 2026, alongside maintenance releases 24.0.11 and 23.1.8. Check which Bareos branch receives security fixes for your deployment, and ask Bacula Systems which Bacula Enterprise support window applies to the release you run. Support windows, not release dates alone, should drive your upgrade plan.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, so Bareos vs Bacula work starts from your environment rather than a generic template. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
How we scope
- We document your current Bacula or Bareos estate, including Directors, Storage Daemons, File Daemons and the Catalog database.
- We define which clients, hypervisors and databases must be covered, and which backup methods and retention needs apply.
- The written scope states deliverables, timelines and what is excluded, and it is agreed before any migration or build work starts.
How we build
- We plan Bareos packaging and repository access, including whether a subscription is needed for your Linux, Windows or macOS hosts.
- We configure storage targets for disk, tape or S3-compatible object storage and test restores against your own recovery objectives.
- We run test restores and verify jobs in a non-production environment before any cutover from existing Bacula schedules.
How we hand over
- We deliver configuration documentation, job definitions, role-based ACL settings and encryption key handling procedures for your team.
- We record restore runbooks and a tested recovery procedure so your operators can run restores without relying on the original builders.
- We confirm with you which items are owned by your team, including the Catalog database, WebUI access and subscription contacts.
How we support
- Ongoing support, upgrades and recurring restore testing are available as a retainer after handover.
- We track Bareos release lines and maintenance releases, and plan upgrades in a scheduled window agreed with your team.
- Before any upgrade, we confirm backup compatibility, catalog schema changes and plugin availability for your environment.
