Bareos vs Proxmox Backup Server: which fits a Proxmox estate
Proxmox Backup Server fits a team whose estate is Proxmox VE and whose backup goal is fast, deduplicated protection of VMs and containers. It is built for Proxmox VE: the integrated client handles QEMU virtual machines and LXC containers, and the server exposes a RESTful API for datastores that clients use to create and restore backups. Incremental backups, deduplication, client-side AES-256-GCM encryption and remote sync of only new data are part of the product. Bareos fits a team that must back up Proxmox alongside Windows servers, Linux file servers, databases and tape libraries under one scheduler and one catalog. Its Proxmox plugin sits inside a general network backup system with Director, Storage and File Daemons, file-level jobs, tape and S3-compatible storage. Both are AGPL-licensed, so license alone does not separate them.
The decision turns on four questions. First, is the estate Proxmox-only? If yes, Proxmox Backup Server covers the hypervisor layer natively; if physical hosts or other hypervisors exist, Bareos keeps one tool for all of them. Second, do you need tape or file-level restores? Proxmox Backup Server supports tape backup, but file-level restore and general workload coverage are the strengths of Bareos, so confirm the exact restore granularity your auditors and application owners expect. Third, how far beyond Proxmox does scope extend? Write out the list of hosts and databases before choosing. Fourth, who operates the system? Bareos has more components to run, including a PostgreSQL-backed Catalog, so a team without backup administration skills should weigh that effort honestly.
Cost depends on support rather than features. Proxmox lists Proxmox Backup Server subscriptions per server per year, and all tiers carry the same features, so the choice is about response times and ticket allowances, not capability. Bareos subscriptions are priced by quote and are required for support, with subscription-only plugins. Ask each vendor for a written quote covering servers, clients, plugins and support tier, and ask Bareos whether its Proxmox plugin is in the subscription tier you need. Confirm your Proxmox VE version against the Proxmox VE FAQ support window, and test restores of both VMs and single files in a non-production environment before you commit.
Which platform fits which backup scenario
This table maps common backup scenarios to the platform that usually fits better and the condition that drives the choice. Read each row as a conditional: the reason holds only while the stated requirement holds, so check it against your estate before deciding. The main takeaway is that a Proxmox-only estate points toward Proxmox Backup Server, while mixed estates, tape and file-level requirements shift the balance toward Bareos.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Proxmox-only estate with VMs and containers | Proxmox Backup Server | Its integrated client for QEMU VMs and LXC containers and its deduplicated datastores fit this workload directly. This holds if you have no requirement to back up non-Proxmox hosts with the same tool. |
| Mixed Linux and Windows servers beside Proxmox | Bareos | Bareos supports Linux, Windows, FreeBSD and macOS through File Daemons on each client, so one catalog and schedule can cover both. Confirm that the Proxmox plugin meets your VM restore needs. |
| Tape-based long-term retention | Bareos | Bareos writes to tape as a native storage target within the Director's job and volume model. Proxmox Backup Server also offers tape backup, so confirm the changer, drive and media workflow your library needs before choosing. |
| File-level restore of individual files | Bareos | Bareos runs file-level jobs against clients directly, which suits restoring single files from physical hosts or guests. For VM images, Proxmox Backup Server's file-level access depends on the snapshot type, so test it on your datastore. |
| Offsite sync to a second site | Proxmox Backup Server | Its remote sync transfers only new data between datastores, and push sync can encrypt snapshots before sending. This suits sites that are both Proxmox-based. Bareos can write to S3-compatible object storage for offsite copies, which suits non-Proxmox targets. |
| Existing Bareos deployment | Bareos | Existing catalogs, schedules, retention policies and trained operators carry real migration cost. Keep Bareos for Proxmox guests through its plugin unless a planned Proxmox-only consolidation justifies a parallel run. |
How each platform is built and what that means for operations
Proxmox Backup Server and Bareos both move data from hosts to storage, but they differ in how many moving parts you run and where the state lives. The cards below cover the components, the catalog, upgrade paths and the daily work each design creates for your team.
Proxmox Backup Server as one datastore
Proxmox Backup Server is a client-server system built around a datastore that holds the backup data and a RESTful API that clients use to create and restore backups. Proxmox VE hosts use the integrated client for QEMU virtual machines and LXC containers, while the proxmox-backup-client command-line tool covers other Linux amd64 hosts. Your main design question is whether the datastore's storage, whether local disk or S3-compatible object storage, can absorb your retention and deduplication targets. Confirm the object store path against your own sizing before you commit.
Bareos Director and daemons
Bareos splits work across a Director that schedules backup, restore, verify and archive jobs, Storage Daemons that write data to media, and File Daemons installed on each client. This gives you more control over where data lands, including tape and disk, but it also means you operate several services and must keep their versions aligned. Map each daemon to a host, a network path and a failure domain before you plan restores. Ask your team who owns the Director configuration when clients are added.
The Bareos Catalog needs PostgreSQL care
The Bareos Catalog holds file indexes and volume records, and it runs on PostgreSQL, which must be running for the Catalog service to work. Losing or corrupting the Catalog can make backed-up data hard to locate, so backup and tested restore of the database become part of the Bareos routine. Plan database maintenance, connection limits and its own backup schedule. Proxmox Backup Server has no separate catalog database to manage, so this work does not exist in that design.
Operator time with bconsole and bareos-webui
Bareos administration is available through the bconsole text console and the bareos-webui web interface, so operators can choose between scripted commands and a browser. Expect routine time on job definitions, client onboarding, pool and volume management and reviewing job reports. Confirm which interface your staff will use for restores, and whether role-based ACLs restrict who can run which commands. Proxmox Backup Server's web interface and API cover datastore administration, which keeps day-to-day work focused on one product.
Upgrade paths for each platform
Proxmox Backup Server releases follow the Proxmox release cycle, and its roadmap lists 4.2 as released on April 29, 2026, based on Debian Trixie 13.4. Bareos publishes its own release line, with 25.1.1 published on September 3, 2026 alongside maintenance releases for 24.0 and 23.1. Upgrading a Bareos estate means checking Director, Storage Daemon, File Daemon and Catalog compatibility together, while Proxmox Backup Server upgrades concentrate on one server and its clients. Confirm the supported upgrade path for your exact versions with each vendor before scheduling.
Where each design fits your team
Proxmox Backup Server suits a team whose estate is mainly Proxmox VE, because the integrated client and single server keep the operating model small. Bareos suits teams that also back up physical servers, Windows hosts, databases and tape libraries under one scheduler and catalog. The cost of running Bareos is the Catalog, the daemon topology and the skills to run them, while the cost of Proxmox Backup Server is concentrated in datastore capacity and the scope limits of one vendor's clients. Test a restore from each design on a representative workload before you decide.
Capabilities side by side
This table sets Proxmox Backup Server's hypervisor-native scope against Bareos' general network backup scope, row by row on deduplication, encryption, tape, object storage, restore and access control. Where a capability is not covered by the supplied facts, the cell tells you what to confirm before you decide, and the takeaway is that the choice turns on whether your estate is mostly Proxmox VE or mixed.
| Capability | Proxmox Backup Server | Bareos |
|---|---|---|
| Scope | Built for virtual machines, containers and physical hosts, optimized for Proxmox VE | General network backup for mixed environments on Linux, Windows, FreeBSD and macOS |
| Deduplication and incremental methods | Incremental backups and deduplication built in | Supports Always Incremental for file backups and a format suited to deduplicating storage such as ZFS, VDO or btrfs |
| Encryption | Client-side AES-256-GCM encryption, SHA-256 checksums | Encrypted communication and backup encryption; confirm algorithms and key handling in your version |
| Tape support | Tape backup supported; up to 256 tape drives per changer in the web interface (4.2) | Tape supported as a storage target alongside disk and S3-compatible object storage |
| Object storage datastores | S3-compatible datastores fully supported as of 4.2, with push sync encrypting snapshots before sending | Stores backups on S3-compatible object storage; confirm supported providers and features for your setup |
| File-level restore | Confirm the granularity of restore inside each VM or container for your Proxmox VE version | File-level jobs for Linux, Windows, FreeBSD and macOS clients through File Daemons; confirm restore options per client type |
| Bare-metal recovery | Physical hosts are in scope; confirm the bare-metal restore procedure with the vendor | Linux bare-metal recovery with Relax-and-Recover and Windows disaster recovery with Barri |
| Hypervisor plugins | Native integration with Proxmox VE QEMU VMs and LXC containers | Plugins for VMware vSphere, Hyper-V and Proxmox, plus databases and NDMP SAN backups |
| Role-based access | Confirm role and permission model in your PBS version | Role-based ACLs for commands and objects in the Director |
| Licensing | AGPL-3.0 or later, free and open-source | AGPLv3 without open-core restrictions |
| Subscription model | Per server per year, all features at every level; tiers differ in support tickets and response time | Subscriptions are a prerequisite for support, provide tested packages and subscription-only plugins; prices by quote |
What the licenses and paid tiers include
Both Bareos and Proxmox Backup Server are released under the GNU Affero General Public License, which means the core software can be installed, run and modified without buying a license. Bareos states that its license is AGPLv3 with no open-core restrictions, and Proxmox Backup Server is released as free and open-source software under AGPL version 3 or later. The license question therefore rarely decides between them. What decides it is what each vendor sells on top of the code and what your team must run itself.
- Core software cost: Neither product requires a paid license to back up data, so the software line item is zero in both cases.
- Copyleft obligations: AGPL terms apply if you modify the software and make it available to users over a network, so check this with counsel if you plan custom changes.
- Source provenance: Bareos files are copyright Bareos GmbH & Co. KG under AGPL-3.0-only, and Proxmox Backup Server is published by Proxmox Server Solutions.
- Hardware and labor: Storage, backup hosts and the time to operate them are costs regardless of license.
Confirm the exact license text and any dependencies you ship with each product against the copyright and license files in the project repositories before you make a legal decision.
Proxmox Backup Server subscriptions are priced per server per year, and the Proxmox pricing page says every feature is available at every level. The tiers differ only in support entitlement, ticket allowance and response time. A subscription also grants access to the Enterprise Repository, which the vendor recommends for production, while the no-subscription repository is described for testing and non-production use. The software itself works without a subscription.
- Community tier: Listed at 560 euros per server per year, with no enterprise ticket support.
- Basic tier: Listed at 1,120 euros per server per year, with 5 support tickets a year and a one business day response.
- Standard tier: Listed at 2,240 euros per server per year, with 15 tickets and a 4-hour critical response.
- Premium tier: Listed at 4,480 euros per server per year, with unlimited tickets and a 2-hour critical response.
Each tier includes unlimited backup storage and clients. Confirm the current prices, tier terms and whether your repository access matches your change policy directly with Proxmox before budgeting, because the figures above come from the pricing page as supplied.
Bareos is open source under AGPLv3 without open-core restrictions, so the features in the public project are the same features a subscriber runs. The commercial offer from Bareos GmbH is a subscription, and its main value is access to tested packages for major Linux distributions, Windows and macOS through subscription repositories that keep the full version history. Subscriptions are also a prerequisite for Bareos support. Some plugins are available only with a subscription. Prices are not published and are set by quote.
- Tested packages: Subscription repositories supply packages tested for major Linux distributions, Windows and macOS, separate from the public community download repository.
- Full version history: Subscribers can access complete package history, which matters when you need a specific older release.
- Subscription-only plugins: Some plugins are sold only through subscriptions, so confirm which hypervisor or database plugins you need are in the community set.
- Support prerequisite: A subscription is required for Bareos support, so budget for it if you need vendor help.
- Quote-based pricing: Ask for a written quote that lists the operating systems, plugins and support level covered.
Before you commit, ask Bareos which plugins your Proxmox estate requires and whether they are subscription-only, since that single answer can change the cost of this comparison.
What drives the running cost of each backup platform
The running cost of a backup platform is mostly a set of recurring costs that sit in different budgets, so start by separating them. Subscription fees are the most visible line, but they are not the largest one for most estates. Proxmox Backup Server is priced per server per year, with Community at 560 euros, Basic at 1,120 euros, Standard at 2,240 euros and Premium at 4,480 euros, all with unlimited backup storage and clients, according to the Proxmox pricing page. Those tiers differ only in support entitlement, so the decision is how much vendor response time you need, not which features you pay for. Bareos subscriptions are priced by quote and buy access to tested packages, subscription-only plugins and the subscription repositories, and they are a prerequisite for Bareos support. Ask each vendor what the subscription covers, whether it is per server, per socket or per host, and whether plugins are included or billed separately.
Storage and operator time are the costs that scale with the estate and recur every month. Proxmox Backup Server deduplicates and stores datastores on local disk, and since 4.2 it supports S3-compatible object store datastores at full support level, which moves the cost to object storage fees. Bareos writes to disk, tape or S3-compatible storage and relies on deduplicating filesystems such as ZFS, VDO or btrfs, so its disk footprint depends on how your Storage Daemons are built. Operator time differs too. Bareos needs someone to maintain the Director, the Catalog on PostgreSQL, job schedules and tape rotation, while Proxmox Backup Server centers on datastores, pruning and sync jobs. Tape hardware is a one-time purchase for Bareos or Proxmox Backup Server (up to 256 drives per changer in the web interface, per the Proxmox roadmap), but drives, media and offsite handling recur. Ask for a sizing of retention, change rate and tape rotation, and confirm the upgrade cadence and licensing for any plugins you need, such as Proxmox or database plugins.
Moving backups from one platform to the other
The sequence below moves protection from Bareos to Proxmox Backup Server, or the reverse, without losing the ability to restore older data. It ends with both platforms documented, tested and the old jobs retired on a recorded date.
Inventory protected hosts and retention rules
The backup owner lists every protected host, VM, container, database and file share, along with its current schedule, retention period, encryption setting and the restore owner who signs off on it. Compare this list against the Proxmox VE guests, bare-metal hosts and file-level sources that each target platform covers, since a Proxmox Backup Server datastore does not protect a physical file server the same way a Bareos File Daemon does. The step is done when the list is reviewed by the team that depends on the data and every item has a named target platform or a documented reason it stays where it is.
Confirm scope and client support on the target
Before any job is written, the platform engineer checks on the target system that each source type is supported and that the required clients are installed and licensed. For Proxmox Backup Server, this means confirming the integrated client for Proxmox VE guests and the proxmox-backup-client for other Linux hosts. For Bareos, it means confirming File Daemon and plugin coverage for hypervisors and databases, and whether a subscription is needed for the packages in use. Ask the vendor or check the documentation for any gap, because a missing client discovered after cutover forces a rebuild. The step closes with a written coverage table signed off by the platform owner.
Rebuild datastores, pools and catalogs on the new platform
Most configuration does not transfer. The team creates the new target structures: on Proxmox Backup Server, datastores and their storage backing, plus encryption keys managed under the operator's key handling process; on Bareos, the Storage Daemon media or pools, the Catalog database on PostgreSQL, and the Director job and client definitions. Backup encryption keys must be stored and tested before the first job runs, because a backup that cannot be decrypted is not a backup. The step is complete when a test job writes to the new storage and the catalog or datastore reports the expected entries.
Recreate schedules and client configuration
The platform engineer recreates each schedule from the inventory, carrying over the frequency, retention settings and pruning rules as written rather than copying defaults from the old system. Client-side configuration, such as Proxmox VE backup targets or Bareos File Daemon settings on each host, is set per host and tracked in version control. Each change is logged with an owner. The step is done when every inventory item has an active schedule on the new platform and a matching entry in the change log.
Run both platforms in parallel
During an overlap period agreed by the backup owner and the risk owner, both systems protect the same hosts. This gives the team a comparison of job success, duration, storage growth and alert behavior on real workloads before the old system is switched off. Duplicate protection costs storage and may load the network, so the owner should check capacity on both targets before starting. The step closes when the team has reviewed job reports for the agreed overlap period and recorded any failed or slow jobs with a fix.
Verify restores on the new platform
A backup job that reports success is not evidence of recoverability. The restore owner runs test restores from the new platform for each source type on the inventory: a Proxmox VE guest or container, a file-level restore, a database if covered, and a bare-metal or full-host test where the target supports it. Each restore is timed against the documented recovery procedure, and the results are written down with the person who performed them. The step is done when every source type has at least one successful restore that the restore owner has signed off on.
Keep the old platform restorable until retention expires
Existing backups in the old format usually cannot be converted into the new platform, so the old system, its catalog or datastores, and the documented restore procedure must stay available until the last backup under the retention policy has expired or been deliberately migrated. Ask the vendor for the supported way to read older data if the old platform will be retired, and confirm that the old software versions and keys are kept under access control. This step is complete when the retention end date for each old set is recorded and the owner accepts the dependency.
Retire old jobs and document the cutover
Once the parallel period has closed and restores are proven, the old jobs are disabled, not deleted, and the change is recorded. The team updates the runbook with the new schedules, restore procedures, key locations and escalation contacts, and removes the old system from monitoring only after the retention end date. The step closes when the runbook is approved by the backup owner and a restore drill from the new platform is on the calendar for the next review cycle.
Where backup implementations usually run long
Most delays start before the first job runs, when teams size datastores and decide how each Proxmox node reaches the backup target. On Proxmox Backup Server, the integrated client covers QEMU virtual machines and LXC containers in Proxmox VE, so the main sizing question is the datastore: how much unique data the chunk store will hold after deduplication, and how quickly a restore must complete. Bareos needs more design work because it has a Director, Storage Daemons, File Daemons on each client, and a Catalog on PostgreSQL that must be running for the Catalog service. If the Proxmox plugin is part of the plan, confirm which plugin edition your subscription covers, since Bareos lists some plugins as subscription-only, and confirm that the plugin version matches your Proxmox VE release.
Key custody is the item most often left unresolved. Proxmox Backup Server encrypts on the client with AES-256-GCM, so a lost key can leave backups unreadable. Name the owner of the key, where it is escrowed, and who may authorize its use before the first backup runs. Bareos provides backup encryption, encrypted communication and role-based ACLs for commands and objects, but its key ownership model still needs a written owner and a tested recovery path. For offsite copies, Proxmox Backup Server 4.2 lets push sync jobs encrypt snapshots before sending them and moved S3-compatible object store datastores to full support. Bareos can place copies on disk, tape or S3-compatible storage. Confirm which path each site needs and how retention pruning interacts with the offsite copy.
Restores are where schedules slip. Teams often learn after go-live that no one has run a full restore of a virtual machine or a Bareos catalog, and unverified restores are a common reason backup projects run long. For Bareos, plan catalog recovery explicitly, because the catalog holds the file indexes and volume records, and a rebuild path must be tested alongside the PostgreSQL service it depends on. If tape is in scope, confirm the library model and drive count with the vendor and your Bareos configuration, since Proxmox Backup Server 4.2 allows up to 256 tape drives per changer in its web interface. Ask whether the test plan covers a bare-metal rebuild or only file-level restores, because Bareos's Relax-and-Recover support for Linux bare metal is a separate workflow with its own testing.
Questions buyers ask before choosing or hiring help
Is Proxmox Backup Server alone enough for a Proxmox estate?
For a estate that is all Proxmox VE, PBS covers the core job: it is built for VMs and containers, it has incremental backups with deduplication, client-side AES-256-GCM encryption, and tape backup, and its clients integrate with Proxmox VE. It is less suited if you also need to back up physical Linux or Windows servers, databases or file shares under one catalog and one retention policy, or if your auditors expect backups to be managed from a single tool. Map every workload type first. If the list is only Proxmox guests, PBS may be sufficient; if it is not, plan a second tool or Bareos alongside it, and confirm the coverage with your own restore tests.
Can Bareos protect Proxmox VMs?
Yes, through its plugin for Proxmox, which is one of the virtual environment plugins listed in the Bareos README. Bareos also writes to disk, tape or S3-compatible object storage and supports Always Incremental file backups, so it can cover VMs and physical hosts in one scheme. Confirm the exact plugin behavior, supported Proxmox VE versions and restore granularity with Bareos before committing, because the plugin's capabilities are not the same as PBS's native, deduplicated VM format. Test a full VM restore and a single-file restore on your own hardware.
What does the subscription choice change for each product?
For Proxmox Backup Server, subscriptions are priced per server per year at 560 euros (Community), 1,120 euros (Basic), 2,240 euros (Standard) and 4,480 euros (Premium), according to Proxmox's pricing page. All levels include unlimited storage and clients and the Enterprise Repository; they differ in ticket allowance and response time. For Proxmox VE, subscriptions are priced per CPU socket per year. For Bareos, subscriptions provide tested packages through subscription repositories, subscription-only plugins and are a prerequisite for support, and prices are by quote. Ask Bareos for the plugin list included in your tier before assuming the Proxmox plugin is covered.
How much effort does each product need to run?
Effort depends on the components you run, not on the license. A PBS setup needs a datastore sized for your retention, a sync plan if you copy off site, and monitoring of verification and pruning jobs. A Bareos setup has more moving parts: a Director, Storage Daemons, File Daemons on each client, a Catalog that depends on PostgreSQL, and the bconsole or bareos-webui for administration. Count the hosts, the database administration, the storage design and the restore testing schedule, then compare that operating load with the workloads you actually need protected.
How long does a migration usually take, and what drives it?
No supplied fact gives a migration duration for either product, so treat any figure you hear as unverified until a written scope confirms it. The main drivers are the number of VMs and containers, total backup data and retention history, whether existing jobs can be rebuilt or must be migrated, the storage backend and its capacity, tape library configuration, and how many restore tests are required before old backups are retired. Keep the old system running until restores from the new one have been proven. Ask for the timeline and its assumptions in writing.
Can our own team do this work without a partner?
A team with Linux, storage and backup administration experience can deploy PBS from the Proxmox documentation and run Bareos from its documentation, and both are open source. What is harder to staff is the ongoing discipline: tested restores, retention decisions, catalog and database maintenance, upgrade planning across Proxmox VE and Debian release cycles, and evidence for audits. Proxmox VE is supported at least as long as the matching Debian release has security support, roughly 3 years, so plan upgrades on that cadence. If the team has no one who runs restore drills, a partner can help, but the team still owns the decisions.
What should we ask a partner to put in a written scope?
Ask for an inventory of protected workloads and the backup method for each, the target architecture with the components named, the storage and retention design, the restore test plan with success criteria, the migration steps and rollback path, the handover documentation, and what the engagement excludes. Also ask which Proxmox VE, PBS and Bareos versions are in scope and who holds the subscriptions and license keys. DeployOpen plans, implements, documents and supports self-hosted platforms in your own infrastructure and works on fixed-scope agreements, so ask for deliverables, timelines and acceptance tests in writing before work starts. Ask for the quote to be itemized by those deliverables.
How DeployOpen helps choose, implement or migrate backups
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure. For Bareos vs Proxmox Backup Server, we start by mapping which workloads run on Proxmox VE, which need file-level or tape jobs, and where the backup data must live.
How we scope
- We list the Proxmox VE clusters, VMs, containers and physical hosts that need protection, with their recovery targets.
- We record whether tape, S3-compatible object storage or file-level jobs are required, and where each copy must sit.
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before any work starts.
How we build
- We deploy the chosen platform in your infrastructure, configuring datastores or Bareos Director, Storage and File Daemons as scoped.
- We set up encryption, access roles and retention rules, then test restores of VMs, containers and files.
- We document backup jobs, catalog or datastore layout and restore runbooks as part of the build deliverables.
How we hand over
- We deliver the configuration, runbooks and restore test results that your team needs to operate the backups.
- We walk your operators through scheduled jobs, monitoring of failed runs and the restore procedure for each workload.
- We provide evidence of backup and restore controls that your internal or external auditors can review.
How we support
- Ongoing support, upgrades and periodic restore testing are available as a retainer after handover.
- Retainers can cover platform upgrades, such as moving between Proxmox Backup Server or Bareos release lines, under written scope.
- Support scope, response expectations and fees are confirmed in the written agreement, and we provide a quote from the agreed scope.
