On this page

Backup, Disaster Recovery, and Archiving

Backup software creates recoverable copies of data, systems, and configurations to protect against data loss, corruption, ransomware, and disasters. Disaster recovery extends this capability to enable rapid restoration of entire systems and services following catastrophic failures. Archiving addresses long-term retention requirements for compliance, legal hold, and historical reference.

This page covers client-server and standalone backup solutions that protect file systems, virtual machines, applications, and databases. The scope includes deduplicating backup tools, enterprise backup platforms, and solutions with integrated disaster recovery capabilities. Cloud-native backup services (AWS Backup, Azure Backup) and database-specific backup tools are covered in separate benchmarks.

Assessment methodology

Tool assessments derive from official vendor documentation, published API references, release notes, and technical specifications as of 2026-01-24. Feature availability varies by product tier, deployment model, and version. Verify current capabilities directly with vendors during procurement. Community-reported information is excluded; only documented features are assessed.

Requirements taxonomy

This taxonomy defines evaluation criteria for backup, disaster recovery, and archiving tools. Requirements are organised by functional area and weighted by typical priority for mission-driven organisations. Adjust weights based on specific operational context and compliance obligations.

Functional requirements

Core capabilities that define what the tool must do for data protection.

Backup operations

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
F1.1	File-level backup	Ability to back up individual files and directories with metadata preservation	Full: preserves permissions, timestamps, extended attributes, ACLs. Partial: basic metadata only. None: data only.	Review file backup documentation; test with complex permission structures	Essential
F1.2	Image-based backup	Block-level backup of entire disks or volumes capturing complete system state	Full: bootable images, bare-metal restore support. Partial: images without boot capability. None: file-level only.	Review image backup documentation; verify bare-metal restore procedures	Essential
F1.3	Incremental backup	Backup of only changed data since the last backup, reducing time and storage	Full: block-level change detection, forever-incremental support. Partial: file-level incremental. Limited: full backups only.	Review incremental backup documentation; assess change tracking mechanism	Essential
F1.4	Synthetic full backup	Creation of full backup from existing incremental chain without re-reading source data	Full: automated synthetic full creation. Partial: manual consolidation only. None: requires source re-read.	Review synthetic full documentation; verify storage efficiency	Important
F1.5	Continuous data protection	Near-real-time backup with recovery point objectives measured in seconds or minutes	Full: journal-based CDP with configurable RPO. Partial: frequent scheduled backups. None: minimum daily intervals.	Review CDP documentation; verify actual achievable RPO	Context-dependent
F1.6	Application-consistent backup	Coordination with applications to ensure backup captures consistent application state	Full: VSS/application quiescing, pre/post scripts. Partial: crash-consistent only with application support.	Review application consistency documentation; test with database workloads	Essential
F1.7	Parallel backup streams	Ability to backup multiple sources simultaneously to maximise throughput	Full: configurable parallelism per job and globally. Partial: fixed parallelism. None: sequential only.	Review parallelism documentation; test with multiple backup sources	Important

Deduplication and storage efficiency

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
F2.1	Content-defined chunking	Variable-length chunking that identifies duplicate data across files and backups	Full: content-aware chunking with configurable parameters. Partial: fixed-size blocks. None: no deduplication.	Review deduplication documentation; verify chunking algorithm	Essential
F2.2	Global deduplication	Deduplication across all backup sources and retention periods in a repository	Full: repository-wide deduplication. Partial: per-job or per-client only. None: no cross-backup deduplication.	Review global dedup documentation; test with multiple similar sources	Important
F2.3	Compression	Data compression to reduce storage requirements	Full: multiple algorithms (zstd, lz4, zlib), configurable levels. Partial: single algorithm, fixed level. None: no compression.	Review compression documentation; benchmark compression ratios	Important
F2.4	Source-side deduplication	Deduplication processing at the backup client before data transfer	Full: client-side dedup reducing network traffic. Partial: server-side only.	Review client architecture documentation	Important
F2.5	Storage backend flexibility	Support for multiple storage destinations including local, network, cloud, and tape	Full: 5+ storage backends with consistent API. Partial: 2-4 backends. Limited: single backend type.	Review storage backend documentation; verify supported destinations	Essential

Recovery operations

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
F3.1	Granular file recovery	Ability to restore individual files without recovering entire backup	Full: file browser, search, instant access. Partial: extraction from archive. None: full restore only.	Review file recovery documentation; test selective restore	Essential
F3.2	Point-in-time recovery	Recovery to specific timestamps within retention period	Full: any point within retention. Partial: backup point times only. None: latest only.	Review PITR documentation; verify granularity	Essential
F3.3	Bare-metal recovery	Full system restoration to dissimilar or replacement hardware	Full: hardware-independent restore, driver injection. Partial: same hardware only. None: not supported.	Review bare-metal documentation; verify hardware compatibility	Important
F3.4	Instant recovery	Immediate workload availability by running directly from backup storage	Full: VM instant recovery with storage vMotion. Partial: manual failback. None: traditional restore only.	Review instant recovery documentation; verify performance impact	Important
F3.5	Cross-platform recovery	Recovery of backups to different operating systems or hypervisors	Full: P2V, V2V, cross-hypervisor support. Partial: limited conversion options. None: same platform only.	Review cross-platform documentation; test conversion scenarios	Context-dependent
F3.6	Recovery verification	Automated testing and validation of backup recoverability	Full: automated recovery testing, integrity verification, sandboxed boot testing. Partial: manual verification only.	Review verification documentation; assess automation options	Important

Disaster recovery

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
F4.1	Replication	Real-time or scheduled copying of backups to secondary locations	Full: continuous replication with bandwidth control. Partial: scheduled copy jobs. None: manual copy only.	Review replication documentation; verify bandwidth management	Essential
F4.2	Failover automation	Automated or orchestrated failover to recovery site during disaster	Full: automated failover with runbooks. Partial: manual failover with procedures. None: no failover support.	Review failover documentation; verify orchestration capabilities	Important
F4.3	Recovery orchestration	Coordinated recovery of multiple systems in correct sequence with dependencies	Full: dependency-aware orchestration, runbooks. Partial: manual sequencing. None: individual recovery only.	Review orchestration documentation; test multi-system recovery	Important
F4.4	RTO/RPO monitoring	Tracking and reporting of recovery time and recovery point objectives	Full: automated SLA monitoring, alerting. Partial: manual calculation. None: no tracking.	Review RTO/RPO documentation; verify reporting capabilities	Important
F4.5	DR testing	Non-disruptive testing of disaster recovery procedures	Full: isolated DR testing, automated validation. Partial: manual test procedures. None: production-impact testing only.	Review DR testing documentation; assess test isolation	Important

Archiving and retention

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
F5.1	Retention policies	Configurable rules for backup retention based on age, count, or custom criteria	Full: GFS schemes, custom policies, per-source rules. Partial: global policies only. None: manual deletion.	Review retention documentation; verify policy flexibility	Essential
F5.2	Legal hold	Ability to prevent deletion of backups subject to legal or compliance requirements	Full: explicit legal hold with audit trail. Partial: manual policy override. None: no hold capability.	Review legal hold documentation; verify audit capabilities	Context-dependent
F5.3	Immutable backups	Write-once storage preventing modification or deletion for specified periods	Full: software and hardware immutability support. Partial: software-only. None: mutable backups only.	Review immutability documentation; test deletion attempts	Important
F5.4	Archive tiering	Movement of aged backups to lower-cost storage tiers	Full: automated tiering with policies. Partial: manual archive migration. None: single tier only.	Review tiering documentation; verify automation	Context-dependent
F5.5	Long-term format stability	Backup format designed for long-term accessibility without version lock-in	Full: documented open format, format versioning. Partial: proprietary but stable. Poor: frequent format changes.	Review format documentation; assess upgrade requirements	Important

Technical requirements

Infrastructure and architecture considerations.

Deployment and hosting

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
T1.1	Self-hosted deployment	Installation on organisation-controlled infrastructure	Full: documented self-hosted deployment, no cloud dependency. Partial: hybrid only. None: SaaS only.	Review deployment documentation; verify offline capability	Essential
T1.2	Container deployment	Deployment via containers for consistent, portable installation	Full: official container images, Kubernetes support. Partial: community images. None: no container support.	Review container documentation; verify image maintenance	Important
T1.3	High availability	Redundant deployment preventing single points of failure	Full: active-active or active-passive HA, documented procedures. Partial: manual failover. None: single instance only.	Review HA documentation; verify failover mechanisms	Important
T1.4	Air-gapped deployment	Operation in isolated networks without internet connectivity	Full: offline installation, updates, licensing. Partial: initial online activation. None: requires connectivity.	Review air-gap documentation; verify offline licensing	Context-dependent
T1.5	Multi-site architecture	Distributed deployment across multiple geographic locations	Full: federated management, site-aware routing. Partial: independent instances.	Review multi-site documentation; assess management capabilities	Context-dependent

Scalability and performance

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
T2.1	Horizontal scaling	Addition of capacity through additional nodes rather than larger hardware	Full: scale-out architecture, load distribution. Partial: limited scale-out. None: scale-up only.	Review scaling documentation; verify architecture	Important
T2.2	Large file handling	Efficient backup of files exceeding 1TB in size	Full: streaming backup, chunked processing. Partial: memory-constrained. None: size limitations.	Review large file documentation; test with TB-scale files	Context-dependent
T2.3	High file count handling	Efficient backup of sources with millions of files	Full: optimised metadata handling, parallel scanning. Partial: performance degradation. None: practical limits.	Review file count documentation; benchmark with millions of files	Important
T2.4	Network efficiency	Optimisation of backup traffic over constrained networks	Full: bandwidth throttling, WAN optimisation, delta sync. Partial: basic throttling. None: no optimisation.	Review network documentation; test on bandwidth-limited connections	Important
T2.5	Resource management	Control over CPU, memory, and I/O consumption during backup operations	Full: configurable resource limits per job. Partial: global limits only. None: no resource control.	Review resource documentation; verify enforcement	Important

Integration architecture

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
T3.1	REST API	Programmatic access to backup operations and management	Full: comprehensive API, documented, versioned. Partial: limited operations. None: no API.	Review API documentation; assess coverage	Important
T3.2	CLI interface	Command-line access for scripting and automation	Full: complete CLI parity with GUI. Partial: limited commands. None: GUI only.	Review CLI documentation; compare with GUI capabilities	Essential
T3.3	Pre/post scripts	Execution of custom scripts before and after backup operations	Full: configurable hooks with error handling. Partial: basic script support. None: no hooks.	Review script documentation; test error scenarios	Important
T3.4	Monitoring integration	Export of metrics and events to monitoring systems	Full: Prometheus/SNMP/syslog export. Partial: built-in monitoring only. None: no export.	Review monitoring documentation; verify export formats	Important
T3.5	Hypervisor integration	Native integration with virtualisation platforms	Full: agentless VM backup, CBT support. Partial: agent-required. None: no hypervisor awareness.	Review hypervisor documentation; verify CBT support	Important

Security requirements

Security controls and data protection capabilities.

Encryption

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
S1.1	Client-side encryption	Data encrypted before leaving the backup client	Full: client-side encryption, key never transmitted. Partial: server-side encryption. None: unencrypted transfer.	Review encryption documentation; verify key handling	Essential
S1.2	Encryption algorithm	Cryptographic algorithm used for data protection	AES-256-GCM or equivalent authenticated encryption. AES-256-CBC acceptable. Weaker algorithms inadequate.	Review encryption documentation; verify algorithm and mode	Essential
S1.3	Key management	Control over encryption keys including generation, storage, and rotation	Full: user-controlled keys, KMS integration, rotation support. Partial: vendor-managed keys. None: no key management.	Review key management documentation; verify rotation procedures	Essential
S1.4	Encryption at rest	Protection of stored backup data	Full: mandatory encryption of repository. Partial: optional encryption. None: unencrypted storage.	Review storage documentation; verify encryption enforcement	Essential
S1.5	Transport encryption	Protection of data during network transfer	Full: TLS 1.3 or TLS 1.2 with strong ciphers. Partial: TLS 1.2 minimum. None: unencrypted transport.	Review transport documentation; test cipher negotiation	Essential

Authentication and access control

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
S2.1	Role-based access control	Granular permissions based on user roles	Full: custom roles, granular permissions, delegation. Partial: fixed roles. Limited: admin/user only.	Review RBAC documentation; assess granularity	Important
S2.2	Multi-factor authentication	MFA support for administrative access	Full: TOTP, WebAuthn, push notification support. Partial: single MFA method. None: password only.	Review MFA documentation; verify supported methods	Important
S2.3	SSO integration	Federation with identity providers	Full: SAML 2.0 and OIDC support. Partial: single protocol. None: local authentication only.	Review SSO documentation; verify IdP compatibility	Important
S2.4	Audit logging	Comprehensive logging of administrative and backup operations	Full: immutable audit logs, configurable retention, export. Partial: basic logging. None: no audit trail.	Review audit documentation; assess log completeness	Essential
S2.5	Separation of duties	Prevention of single administrator having complete control	Full: segregated backup and restore permissions, dual control options. Partial: basic separation. None: no separation.	Review access control documentation; verify separation options	Important

Security certifications and compliance

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
S3.1	SOC 2 Type II	Independent audit of security controls (commercial vendors)	Full: current certification for relevant services. Partial: Type I only. None: no certification.	Request SOC 2 report; verify audit scope	Important
S3.2	Security track record	History of vulnerability handling and security incidents	Full: responsible disclosure programme, timely patches, CVE tracking. Partial: reactive patches. Poor: unaddressed vulnerabilities.	Review security advisories; check CVE database	Important
S3.3	Code auditability	Ability to review source code for security assessment	Full: open source with complete source access. Partial: source available for review. None: closed source.	Review licence terms; assess audit options	Context-dependent

Operational requirements

Day-to-day administration and management considerations.

Administration

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
O1.1	Web management interface	Browser-based administration console	Full: comprehensive web UI, responsive design. Partial: limited web UI. None: CLI/desktop only.	Review UI documentation; assess during trial	Important
O1.2	Centralised management	Single console for managing multiple backup servers or clients	Full: centralised policy, monitoring, reporting. Partial: basic aggregation. None: per-instance management.	Review central management documentation	Important
O1.3	Policy-based management	Definition and application of backup policies across multiple sources	Full: hierarchical policies, inheritance, exceptions. Partial: flat policies. None: per-source configuration.	Review policy documentation; test inheritance	Important
O1.4	Scheduling flexibility	Control over backup timing and frequency	Full: flexible schedules, calendar integration, timezone support. Partial: basic cron-style. Limited: fixed intervals.	Review scheduling documentation; assess flexibility	Essential
O1.5	Notifications and alerting	Proactive notification of backup status and issues	Full: multi-channel alerts, customisable thresholds, escalation. Partial: email only. None: log review required.	Review alerting documentation; verify channels	Important

Monitoring and reporting

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
O2.1	Backup job monitoring	Real-time visibility into backup job status and progress	Full: live progress, detailed status, historical trends. Partial: completion status only.	Review monitoring documentation; assess visibility	Essential
O2.2	Capacity reporting	Tracking and forecasting of storage consumption	Full: deduplication ratios, growth trends, forecasting. Partial: current usage only.	Review reporting documentation; verify forecasting	Important
O2.3	Compliance reporting	Reports demonstrating backup policy compliance	Full: SLA compliance, audit reports, scheduled delivery. Partial: manual report generation. None: no compliance reports.	Review compliance documentation; assess report templates	Important
O2.4	Health monitoring	Proactive detection of backup infrastructure issues	Full: component health, predictive alerts, self-healing. Partial: reactive alerts. None: manual monitoring.	Review health documentation; verify alerting	Important

Maintenance and support

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
O3.1	Documentation quality	Completeness and accuracy of technical documentation	Excellent: comprehensive, current, searchable, tutorials. Good: complete reference. Adequate: basic coverage. Poor: minimal.	Assess documentation during evaluation	Essential
O3.2	Update mechanism	Process for applying updates and patches	Full: in-place updates, rollback support, staged rollout. Partial: manual update process. None: reinstallation required.	Review update documentation; verify rollback	Important
O3.3	Backup of backup infrastructure	Protection of backup server configuration and metadata	Full: integrated backup of catalogue/config. Partial: manual export. None: no metadata backup.	Review self-backup documentation; verify recovery	Important
O3.4	Community or vendor support	Available support channels and response capabilities	Document channels: community forum, email, phone, premium support. Note response commitments.	Review support options; check SLA terms	Important

Data management requirements

Data handling, portability, and lifecycle.

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
D1.1	Repository format documentation	Public documentation of backup storage format	Full: open, documented format enabling third-party tools. Partial: documented but proprietary. None: undocumented format.	Review format documentation; assess openness	Important
D1.2	Repository portability	Ability to move backup repositories between systems	Full: platform-independent repositories, documented migration. Partial: same-platform portability. None: tied to installation.	Review portability documentation; test migration	Important
D1.3	Integrity verification	Detection of backup corruption or tampering	Full: cryptographic integrity checks, periodic verification. Partial: basic checksums. None: no verification.	Review integrity documentation; verify check mechanisms	Essential
D1.4	Repository maintenance	Tools for repository health and optimisation	Full: automated maintenance, space reclamation, consistency checks. Partial: manual tools. None: no maintenance.	Review maintenance documentation; assess automation	Important

Commercial and contractual requirements

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
C1.1	Pricing model	Structure of licensing or subscription costs	Per-socket, per-TB, per-workload, or subscription models. Assess predictability and scale impact.	Review pricing documentation; model costs at scale	Important
C1.2	Nonprofit pricing	Discounted licensing for qualifying organisations	Full: established programme, significant discount. Partial: ad-hoc discounts. None: standard pricing.	Research nonprofit programmes; verify eligibility	Important
C1.3	Open source licence	Licence terms for FOSS options	BSD/MIT (permissive), AGPL (copyleft, network use triggers), proprietary components.	Review licence terms; assess compliance requirements	Essential for FOSS
C1.4	Vendor stability	Organisation financial health and longevity	Assess: funding, revenue model, market position, community health (FOSS).	Research organisation; review governance	Important

Accessibility requirements

ID	Requirement	Description	Assessment criteria	Verification method	Typical priority
A1.1	Web UI accessibility	Accessibility of browser-based management interface	Full: WCAG 2.1 AA compliance. Partial: basic keyboard navigation. None: mouse-dependent.	Test with screen reader; review accessibility statement	Important
A1.2	CLI accessibility	Command-line interface for visually impaired administrators	Full: complete CLI with accessible output formats. Partial: limited CLI. None: GUI only.	Review CLI documentation; test output formats	Important

Assessment methodology

Tools are assessed against each requirement using the following scale:

Rating	Symbol	Definition
Full support	●	Requirement fully met with documented, production-ready capability
Partial support	◐	Requirement partially met; limitations documented in notes
Minimal support	○	Basic capability exists but significant gaps
Not supported	✗	Capability not available
Not applicable	-	Requirement not relevant to this tool
Not assessed	?	Insufficient documentation to assess

Additional notation:

$ indicates feature requires paid tier or add-on
E indicates enterprise tier only
P indicates plugin or extension required

Functional capability comparison

Backup operations

Req ID	Requirement	restic	BorgBackup	Proxmox Backup Server	Bareos	Veeam	Acronis
F1.1	File-level backup	●	●	●	●	●	●
F1.2	Image-based backup	✗	✗	●	●P	●	●
F1.3	Incremental backup	●	●	●	●	●	●
F1.4	Synthetic full backup	●	●	●	●	●	●
F1.5	CDP	✗	✗	✗	✗	●$	●$
F1.6	Application-consistent	◐	◐	●	●	●	●
F1.7	Parallel streams	●	●	●	●	●	●

Assessment notes:

restic F1.6: Supports pre/post backup hooks for application quiescing; no native VSS integration
BorgBackup F1.6: Pre/post hooks available; VSS through external scripting only
restic/BorgBackup F1.2: File-level only; image backup requires separate imaging tool

Deduplication and storage efficiency

Req ID	Requirement	restic	BorgBackup	Proxmox Backup Server	Bareos	Veeam	Acronis
F2.1	Content-defined chunking	●	●	●	●P	●	●
F2.2	Global deduplication	●	●	●	◐	●	●
F2.3	Compression	●	●	●	●	●	●
F2.4	Source-side deduplication	●	●	●	✗	●	●
F2.5	Storage backend flexibility	●	◐	◐	●	●	●

Assessment notes:

restic F2.5: Supports local, SFTP, REST, S3, Azure, GCS, Backblaze B2, and other backends
BorgBackup F2.5: Local and SSH/SFTP; cloud via rclone mount or borg-specific repos
Proxmox Backup Server F2.5: Local, S3 (technology preview in v4.0+), remote PBS sync
Bareos F2.1: Dedupable storage backend added in version 24; requires compatible storage (ZFS, VDO, btrfs)

Recovery operations

Req ID	Requirement	restic	BorgBackup	Proxmox Backup Server	Bareos	Veeam	Acronis
F3.1	Granular file recovery	●	●	●	●	●	●
F3.2	Point-in-time recovery	●	●	●	●	●	●
F3.3	Bare-metal recovery	✗	✗	◐	●	●	●
F3.4	Instant recovery	✗	✗	●	✗	●	●
F3.5	Cross-platform recovery	✗	✗	◐	●	●	●
F3.6	Recovery verification	●	●	●	◐	●	●

Assessment notes:

restic F3.6: Repository integrity checks with restic check; no automated recovery testing
Proxmox Backup Server F3.3: Bare-metal for Proxmox VE guests; limited for physical systems
Proxmox Backup Server F3.5: VM recovery between Proxmox clusters; no cross-hypervisor

Disaster recovery

Req ID	Requirement	restic	BorgBackup	Proxmox Backup Server	Bareos	Veeam	Acronis
F4.1	Replication	◐	◐	●	●	●	●
F4.2	Failover automation	✗	✗	✗	✗	●$	●$
F4.3	Recovery orchestration	✗	✗	✗	◐	●$	●$
F4.4	RTO/RPO monitoring	✗	✗	◐	◐	●	●
F4.5	DR testing	✗	✗	◐	◐	●	●

Assessment notes:

restic F4.1: Copy command for repository-to-repository transfer; no continuous replication
BorgBackup F4.1: Repository sync via borg transfer; manual scheduling
Proxmox Backup Server F4.1: Built-in sync jobs between PBS instances with bandwidth control

Archiving and retention

Req ID	Requirement	restic	BorgBackup	Proxmox Backup Server	Bareos	Veeam	Acronis
F5.1	Retention policies	●	●	●	●	●	●
F5.2	Legal hold	✗	✗	✗	✗	●	●
F5.3	Immutable backups	◐	◐	◐	◐	●	●
F5.4	Archive tiering	◐	✗	◐	●	●	●
F5.5	Long-term format stability	●	●	●	●	◐	◐

Assessment notes:

restic F5.3: Object lock support on compatible S3 backends (experimental in 0.18+)
BorgBackup F5.3: Append-only mode prevents modification; deletion requires separate key
Proxmox Backup Server F5.3: S3 object lock support in technology preview
restic/BorgBackup F5.5: Documented repository formats with strong backward compatibility commitments

Technical capability comparison

Deployment and hosting

Req ID	Requirement	restic	BorgBackup	Proxmox Backup Server	Bareos	Veeam	Acronis
T1.1	Self-hosted	●	●	●	●	●	●
T1.2	Container deployment	●	●	◐	●	●	◐
T1.3	High availability	-	-	◐	●	●	●
T1.4	Air-gapped deployment	●	●	●	●	◐	◐
T1.5	Multi-site architecture	◐	◐	●	●	●	●

Deployment details:

Tool	Infrastructure	Container support	Minimum resources	Storage requirements
restic	Single binary, no server required	Official Docker images	512MB RAM, 1 CPU	Repository-dependent
BorgBackup	Python application, optional server	Community Docker images	1GB RAM, 1 CPU	Repository-dependent
Proxmox Backup Server	Debian-based appliance or packages	LXC container option	2GB RAM, 2 CPU, 8GB OS disk	ZFS recommended
Bareos	Linux (RHEL, Ubuntu, SUSE, Debian)	Official Docker images	4GB RAM, 2 CPU	PostgreSQL database + storage
Veeam	Windows Server 2019+ or Veeam appliance	Hardened Linux appliance	8GB RAM, 4 CPU	SQL Server database + repository
Acronis	Windows/Linux server or cloud	Management Server in Docker	8GB RAM, 4 CPU	PostgreSQL/SQL Server + storage

Integration architecture

Req ID	Requirement	restic	BorgBackup	Proxmox Backup Server	Bareos	Veeam	Acronis
T3.1	REST API	●	✗	●	●	●	●
T3.2	CLI interface	●	●	●	●	●	●
T3.3	Pre/post scripts	●	●	●	●	●	●
T3.4	Monitoring integration	◐	◐	●	●	●	●
T3.5	Hypervisor integration	✗	✗	●	●P	●	●

API and integration details:

Tool	API type	Authentication	Rate limits	SDK availability
restic	REST (rest-server)	Basic auth, TLS	Configurable	Go library
BorgBackup	CLI only	SSH keys	N/A	Python library
Proxmox Backup Server	REST	API tokens, TLS	Configurable	Rust library, CLI
Bareos	REST, CLI	PAM, LDAP, internal	None documented	Python SDK
Veeam	REST, PowerShell	OAuth 2.0, API keys	Per-tier limits	PowerShell, .NET
Acronis	REST	OAuth 2.0, API keys	Tier-dependent	Python, Go SDKs

Security capability comparison

Encryption

Req ID	Requirement	restic	BorgBackup	Proxmox Backup Server	Bareos	Veeam	Acronis
S1.1	Client-side encryption	●	●	●	●	●	●
S1.2	Encryption algorithm	AES-256-CTR + Poly1305	AES-256-CTR + HMAC-SHA256 or BLAKE2b	AES-256-GCM	AES-128/256-CBC	AES-256	AES-256
S1.3	Key management	●	●	●	◐	●	●
S1.4	Encryption at rest	●	●	●	●	●	●
S1.5	Transport encryption	TLS 1.2+	SSH	TLS 1.2+	TLS 1.2+	TLS 1.2+	TLS 1.2+

Encryption details:

restic: Uses scrypt for key derivation; repository password encrypts master key; supports multiple passwords via key files
BorgBackup 1.x: Uses HMAC-SHA256 for authentication; BorgBackup 2.x uses BLAKE2b AEAD
Proxmox Backup Server: GCM mode provides authenticated encryption; key management per datastore
Bareos: Encryption optional, configured per FileSet; keys stored in director configuration

Authentication and access control

Req ID	Requirement	restic	BorgBackup	Proxmox Backup Server	Bareos	Veeam	Acronis
S2.1	RBAC	-	-	●	●	●	●
S2.2	MFA	-	-	●	◐	●	●
S2.3	SSO integration	-	-	●	●	●	●
S2.4	Audit logging	◐	◐	●	●	●	●
S2.5	Separation of duties	-	-	●	●	●	●

Authentication notes:

restic: Repository-level password authentication; no built-in user management
BorgBackup: SSH key authentication; append-only mode provides operational separation
Proxmox Backup Server: Realms (PAM, LDAP, AD, OpenID Connect), namespaces for isolation, granular ACLs
Bareos: PAM integration, LDAP/AD support, role-based console permissions

Security certifications

Certification	restic	BorgBackup	Proxmox Backup Server	Bareos	Veeam	Acronis
SOC 2 Type II	-	-	-	-	●	●
ISO 27001	-	-	-	-	●	●
Open source audit	●	●	●	●	-	-
CVE tracking	●	●	●	●	●	●

Operational capability comparison

Administration

Req ID	Requirement	restic	BorgBackup	Proxmox Backup Server	Bareos	Veeam	Acronis
O1.1	Web interface	✗	✗	●	●	●	●
O1.2	Centralised management	✗	✗	◐	●	●	●
O1.3	Policy-based management	✗	✗	◐	●	●	●
O1.4	Scheduling flexibility	External	External	●	●	●	●
O1.5	Notifications	External	External	●	●	●	●

Administration notes:

restic/BorgBackup: CLI tools require external scheduling (cron, systemd timers) and notification (scripts, monitoring integration)
Third-party wrappers provide enhanced management: resticprofile, autorestic, borgmatic, vorta (BorgBackup GUI)

Support comparison

Aspect	restic	BorgBackup	Proxmox Backup Server	Bareos	Veeam	Acronis
Documentation	Excellent	Excellent	Excellent	Good	Excellent	Good
Community forum	● Active	● Active	● Active	● Active	● Active	◐ Limited
Commercial support	✗	✗	●$	●$	●	●
Response time (critical)	Community	Community	2-4 hours$	4 hours$	1 hour	1 hour

Commercial comparison

Pricing models

Tool	Type	Model	Free tier	Nonprofit programme	Estimated cost (50 workloads)
restic	Open source	Free	● Full product	N/A	£0 + infrastructure
BorgBackup	Open source	Free	● Full product	N/A	£0 + infrastructure
Proxmox Backup Server	Open source	Free + support subscription	● Full product	N/A	£0-2,000/year (support)
Bareos	Open source	Free + subscription	● Community edition	N/A	£0-8,000/year (subscription)
Veeam	Commercial	Per-workload licence	◐ Community (10 workloads)	● Significant discount	£3,000-15,000/year
Acronis	Commercial	Per-workload subscription	✗	◐ Partner discounts	£4,000-20,000/year

Cost notes:

Open source infrastructure costs (storage, compute, network) vary by scale and provider
Veeam Community Edition: Free for up to 10 workloads with some feature limitations
Proxmox and Bareos subscriptions provide enterprise repositories and support; software is functionally identical
Commercial pricing varies significantly by workload type (VM, physical, cloud) and edition

Vendor details

Tool	Organisation	Founded	HQ location	Business model
restic	Community project	2014	Germany (primary maintainer)	Donations, sponsorships
BorgBackup	Borg Collective	2010 (attic), 2015 (borg)	Community distributed	Donations, sponsorships
Proxmox Backup Server	Proxmox Server Solutions GmbH	2020 (PBS), 2005 (company)	Austria (EU)	Support subscriptions
Bareos	Bareos GmbH & Co. KG	2012	Germany (EU)	Support subscriptions
Veeam	Veeam Software (Insight Partners)	2006	US (Switzerland HQ)	Licence/subscription
Acronis	Acronis International GmbH	2003	Switzerland	Subscription

Jurisdictional considerations:

restic, BorgBackup: Community projects; no corporate jurisdiction; data stored per user configuration
Proxmox, Bareos: EU-based companies; GDPR as primary framework; no CLOUD Act exposure
Veeam: US ownership (Insight Partners); subject to CLOUD Act for cloud services; self-hosted deployments under customer control
Acronis: Swiss headquarters; offers regional data centres; cloud services subject to local jurisdiction

Detailed tool assessments

restic

Type: Open source
Licence: BSD 2-Clause -permissive licence allowing commercial use and modification without disclosure requirements
Current version: 0.18.1 (released September 2025)
Deployment options: Single binary (Linux, Windows, macOS, BSD); no server component required
Source repository: https://github.com/restic/restic
Documentation: https://restic.readthedocs.io

restic provides fast, secure, deduplicated backups using content-defined chunking and client-side encryption. The tool operates as a standalone binary without requiring a separate server component, connecting directly to storage backends including local filesystem, SFTP, REST servers, and cloud object storage (S3, Azure Blob, Google Cloud Storage, Backblaze B2).

The architecture prioritises simplicity and security. All data is encrypted with AES-256 before leaving the client, using a repository password that never leaves the local system. The chunking algorithm (Rabin fingerprinting) provides efficient deduplication across files and backups. Repositories are self-contained and portable, storing all metadata alongside backup data.

Key strengths:

Single binary deployment with no server dependencies simplifies installation across platforms
Direct cloud storage support eliminates need for intermediate servers or gateways
Cryptographic integrity verification detects corruption or tampering
Reproducible builds enable verification of official binaries
Backward compatibility commitment ensures long-term data accessibility

Key limitations:

No built-in scheduling, monitoring, or alerting; requires external tools (cron, systemd, monitoring stack)
No graphical interface; CLI-only operation may challenge less technical administrators
No native bare-metal or image-based backup; file-level only
No centralised management for multiple clients; each instance operates independently
Pre-1.0 version numbering, though repository format is stable and documented

Deployment and operations:

restic installs as a single binary (approximately 25MB) with no external dependencies. Self-update capability downloads and verifies new versions automatically.

Deployment type	Procedure
Linux/macOS	Download binary or install via package manager (apt, dnf, brew, nix)
Windows	Download binary, Chocolatey, Scoop, or WinGet
Container	Official Docker images at docker.io/restic/restic

Resource requirements:

Scale	RAM	CPU	Notes
Small (<100GB)	512MB	1 core	Memory scales with repository size during operations
Medium (<1TB)	1-2GB	2 cores	Parallel backup streams increase CPU usage
Large (>1TB)	4GB+	4+ cores	Index operations require memory proportional to repository size

Storage backend configuration example (S3):

# Initialise repository
export AWS_ACCESS_KEY_ID=your-access-key
export AWS_SECRET_ACCESS_KEY=your-secret-key
restic -r s3:s3.eu-west-2.amazonaws.com/bucket-name init

# Backup with retention policy
restic -r s3:s3.eu-west-2.amazonaws.com/bucket-name backup /data
restic -r s3:s3.eu-west-2.amazonaws.com/bucket-name forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Organisational fit:

Best suited for:

Organisations with Linux/Unix administration skills comfortable with CLI tools
Environments requiring direct cloud storage backup without intermediate servers
Distributed teams needing portable, self-contained backups
Budgets prioritising zero licensing cost with infrastructure investment

Less suitable for:

Organisations requiring graphical management interfaces
Environments needing VM-level or image-based backup
Teams without capacity to integrate scheduling and monitoring externally

BorgBackup

Type: Open source
Licence: BSD 3-Clause -permissive licence allowing commercial use and modification
Current version: 1.4.3 (stable, December 2025); 2.0.0b20 (beta, December 2025)
Deployment options: Python application; Linux, macOS, BSD, Windows (via WSL)
Source repository: https://github.com/borgbackup/borg
Documentation: https://borgbackup.readthedocs.io

BorgBackup delivers deduplicating backup with strong encryption and compression. Forked from Attic in 2015, the project has matured into a widely-deployed backup solution, particularly in Linux server environments. The tool supports local and SSH-based remote repositories, with cloud storage accessible through filesystem mounts (rclone, s3fs) or dedicated hosting services.

The deduplication mechanism uses content-defined chunking with configurable chunk sizes. Compression options include lz4 (fast), zstd (balanced), and zlib (maximum compression). Encryption uses AES-256-CTR with HMAC-SHA256 (1.x) or authenticated AEAD modes (2.x), with keys derived from a passphrase using Argon2.

Key strengths:

Mature, battle-tested codebase with extensive deployment history
Excellent compression ratios with multiple algorithm options
Append-only repository mode prevents ransomware from deleting backups
Strong backward compatibility within major version series
Active community with comprehensive documentation

Key limitations:

SSH-only remote access; no native cloud storage support (requires filesystem mounts)
Python dependency adds complexity compared to single-binary tools
Version 2.x repositories incompatible with 1.x; migration required via transfer command
No graphical interface in core project (Vorta provides third-party GUI)
Windows support limited to WSL; no native Windows client

Deployment and operations:

BorgBackup requires Python 3.10+ and compilation of C extensions. Pre-built binaries simplify installation on common platforms.

Deployment type	Procedure
Linux	Package manager (apt, dnf, pacman) or pip
macOS	Homebrew or pip
Windows	WSL with Linux package
Server	Standalone or with borgmatic wrapper

Retention policy example:

# Initialise encrypted repository
borg init --encryption=repokey-blake2 /backup/repo

# Backup with archive naming
borg create /backup/repo::{hostname}-{now:%Y-%m-%d} /data

# Prune with retention policy
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /backup/repo

Organisational fit:

Best suited for:

Linux-focused environments with SSH infrastructure
Organisations prioritising compression efficiency
Scenarios requiring append-only repositories for ransomware protection
Teams comfortable with Python-based tooling

Less suitable for:

Windows-centric environments
Organisations requiring native cloud storage integration
Teams needing graphical management interfaces

Proxmox Backup Server

Type: Open source
Licence: AGPL-3.0 -copyleft licence requiring source disclosure for networked services
Current version: 4.1 (released November 2025)
Deployment options: Debian-based appliance, packages for Debian 13, LXC container
Source repository: https://git.proxmox.com
Documentation: https://pbs.proxmox.com/docs/

Proxmox Backup Server (PBS) provides enterprise backup for virtual machines, containers, and physical hosts with deduplication, compression, and encryption. Developed by Proxmox Server Solutions, PBS integrates natively with Proxmox VE but supports standalone use for any Linux system via the backup client.

The architecture uses a content-addressable storage format with variable-length chunks. The web interface provides datastore management, backup job monitoring, and tape library support. Version 4.0 introduced S3-compatible object storage as a backend (technology preview), expanding deployment options beyond local and remote PBS instances.

Key strengths:

Native integration with Proxmox VE virtualisation platform
Web-based management interface with comprehensive monitoring
Built-in sync jobs for multi-site replication
Efficient changed-block tracking for VM backups
Support for tape libraries and offline media
S3 storage backend (technology preview v4.0+)

Key limitations:

Optimal performance tied to Proxmox VE; other hypervisors require agent backup
AGPL licence requires source disclosure for modifications to networked service
Physical server backup limited to Linux systems (client not available for Windows)
S3 backend in technology preview; not yet production-ready
Smaller ecosystem compared to established enterprise solutions

Deployment and operations:

PBS deploys as a dedicated appliance or packages on Debian 13. ZFS is recommended for optimal deduplication and data integrity.

Component	Minimum	Recommended
CPU	2 cores	4+ cores (verification jobs CPU-intensive)
RAM	2GB	8GB+ (1GB per TB of deduplication index)
OS disk	8GB	32GB SSD
Datastore	HDD/SSD	ZFS mirror or RAID-Z

Backup job configuration:

PBS supports scheduling through the web interface with sync jobs for replication:

# Client backup (CLI)
proxmox-backup-client backup root.pxar:/ --repository pbs.example.org:datastore1

# Sync job between PBS instances (configured in web UI)
# Source: remote PBS, Target: local datastore
# Schedule: daily at 02:00, bandwidth limit: 50 MB/s

Organisational fit:

Best suited for:

Proxmox VE virtualisation environments
Organisations with Linux server administration capacity
Environments requiring integrated web management
Multi-site deployments with replication requirements

Less suitable for:

VMware or Hyper-V primary environments
Windows-heavy infrastructure
Organisations requiring commercial support guarantees

Bareos

Type: Open source
Licence: AGPL-3.0 -copyleft licence requiring source disclosure for networked services
Current version: 25 (December 2025); 24.0.6 (October 2025 maintenance)
Deployment options: Linux (RHEL, Ubuntu, SUSE, Debian), packages and containers
Source repository: https://github.com/bareos/bareos
Documentation: https://docs.bareos.org

Bareos (Backup Archiving Recovery Open Sourced) is an enterprise backup solution forked from Bacula in 2010. The platform supports diverse workloads including file servers, databases, virtual machines, and cloud storage, with particular strength in tape library management and large-scale deployments. Bareos GmbH provides commercial support and subscription services while maintaining the open source community edition.

The architecture follows a director-storage-client model. The Director daemon orchestrates backup operations, Storage daemons manage media, and File daemons run on protected systems. This distributed architecture scales to thousands of clients and petabytes of data.

Key strengths:

Proven scalability to exabyte-class deployments
Comprehensive tape library support including WORM media
Native plugins for VMware, Hyper-V, Proxmox, databases
Flexible storage options including deduplication (v24+)
SUSE and Red Hat certified
Windows disaster recovery (v25)

Key limitations:

Complexity of director-storage-client architecture increases administrative overhead
PostgreSQL database dependency adds infrastructure requirements
Web UI less polished than commercial alternatives
Deduplication requires compatible storage backend (ZFS, VDO, btrfs)
Learning curve steeper than simpler tools

Deployment and operations:

Bareos requires PostgreSQL for its catalogue database. Typical deployment includes Director, Storage Daemon, and WebUI on a central server, with File Daemons on protected systems.

Component	Purpose	Resource requirements
Director	Job orchestration, scheduling	2GB RAM, 2 CPU
Storage Daemon	Media management	4GB RAM, 2 CPU, storage devices
File Daemon	Client backup agent	512MB RAM, 1 CPU
WebUI	Management interface	1GB RAM, 1 CPU
PostgreSQL	Catalogue database	4GB RAM, SSD storage

Job configuration example:

# FileSet definition
FileSet {
  Name = "ServerData"
  Include {
    Options {
      Signature = SHA256
      Compression = LZ4
    }
    File = /var/data
    File = /etc
  }
  Exclude {
    File = /var/data/cache
  }
}

# Job definition
Job {
  Name = "BackupServer1"
  Type = Backup
  Client = server1-fd
  FileSet = "ServerData"
  Schedule = "WeeklyCycle"
  Pool = "Full"
  Storage = "File1"
}

Organisational fit:

Best suited for:

Large-scale deployments with diverse workloads
Environments with tape library requirements
Organisations with dedicated backup administrators
VMware and Hyper-V virtualisation (with plugins)

Less suitable for:

Small deployments where architecture complexity exceeds requirements
Teams without Linux administration experience
Organisations seeking simple, appliance-style deployment

Veeam Backup and Replication

Type: Commercial
Licence: Proprietary -per-workload or per-socket licensing
Current version: 13.0.1 Patch 1 (January 2026)
Deployment options: Windows Server, Veeam Hardened Linux Appliance
Documentation: https://helpcenter.veeam.com

Veeam Backup and Replication provides comprehensive data protection for virtual, physical, and cloud workloads. The platform dominates the VMware and Hyper-V backup market, with extensive features for disaster recovery, replication, and cloud mobility. Version 13 introduced enhanced ransomware protection, AI-driven anomaly detection, and expanded Kubernetes support.

The architecture centres on a backup server managing jobs, with proxy servers handling data movement and repository servers storing backups. This distributed model scales across data centres with centralised management through Veeam Backup Enterprise Manager.

Key strengths:

Market-leading VMware and Hyper-V integration with CBT support
Instant VM recovery enabling immediate workload availability
Comprehensive disaster recovery orchestration
Extensive cloud integration (AWS, Azure, GCP)
Robust ransomware protection with immutable backups
Large partner and integration ecosystem

Key limitations:

Licensing costs significant for large deployments
Windows Server dependency for backup server (Linux appliance available)
Complexity increases with full feature deployment
Domain-joined installations have elevated security considerations
Proprietary format limits long-term portability

Deployment and operations:

Veeam deploys on Windows Server or as a pre-configured hardened Linux appliance. SQL Server (Express included, Standard/Enterprise for scale) stores configuration data.

Component	Minimum	Recommended
CPU	4 cores	8+ cores
RAM	8GB	16GB+ (4GB per 10 concurrent jobs)
OS disk	60GB	100GB SSD
SQL Server	Express (10GB limit)	Standard for >500 VMs

Licensing models:

Edition	Model	Includes
Community	Free	10 workloads, limited features
Foundation	Per-workload	Core backup and recovery
Advanced	Per-workload	+ Monitoring, orchestration
Premium	Per-workload	+ Recovery orchestration, CDP

Nonprofit programme: Veeam offers significant discounts (reported 50%+) through technology donation programmes. Eligibility requires verification through designated partners.

Organisational fit:

Best suited for:

VMware and Hyper-V virtualisation environments
Organisations requiring enterprise disaster recovery
Environments with budget for commercial licensing
Teams benefiting from graphical management and wizards

Less suitable for:

Linux-only infrastructure
Organisations prioritising open source
Budget-constrained environments without nonprofit eligibility

Acronis Cyber Protect

Type: Commercial
Licence: Proprietary -per-workload subscription
Current version: 16 (February 2024 base, ongoing updates)
Deployment options: Windows/Linux server, cloud-hosted, appliance
Documentation: https://dl.managed-protection.com/u/cyberprotect/

Acronis Cyber Protect integrates backup, disaster recovery, and endpoint security in a unified platform. The product targets organisations seeking consolidated data protection and cybersecurity, with AI-powered anti-malware, patch management, and vulnerability assessment alongside traditional backup capabilities. The architecture supports on-premises, cloud, and hybrid deployments.

Key strengths:

Integrated backup and security reduces tool sprawl
Broad platform support including Windows, Linux, macOS, mobile
Global data centre network for cloud backup and DR
Bare-metal recovery with dissimilar hardware support
Ransomware protection with behavioural detection
MSP-focused cloud platform (Cyber Protect Cloud)

Key limitations:

Security features may overlap with existing endpoint protection
Subscription model increases long-term costs versus perpetual licences
Complexity of integrated platform requires broader expertise
Performance overhead from security scanning during backup
Cloud dependency for some features

Deployment and operations:

Acronis Management Server deploys on Windows or Linux, with agents on protected workloads. Cloud deployment eliminates infrastructure requirements.

Deployment	Use case	Infrastructure
On-premises	Data sovereignty, air-gapped	Management server + storage
Cloud	Simplified management	Acronis Cloud subscription
Hybrid	Flexibility, DR to cloud	On-premises + cloud storage

Organisational fit:

Best suited for:

Organisations consolidating backup and endpoint security
MSP and service provider environments (Cyber Protect Cloud)
Distributed organisations with remote endpoint protection needs
Environments requiring integrated anti-ransomware

Less suitable for:

Organisations with established, separate backup and security stacks
Purely Linux/open source environments
Budget-constrained organisations (subscription costs accumulate)

Selection guidance

Decision framework

                           +------------------+
                           | Primary          |
                           | requirement?     |
                           +--------+---------+
                                    |
         +--------------------------+---------------------------+
         |                          |                           |
         v                          v                           v
+--------+--------+       +---------+--------+        +---------+--------+
| VM/hypervisor   |       | File-level       |        | Enterprise       |
| backup          |       | backup           |        | features         |
+--------+--------+       +---------+--------+        +---------+--------+
         |                          |                           |
   +-----+-----+              +-----+-----+               +-----+-----+
   |           |              |           |               |           |
   v           v              v           v               v           v
+--+---+   +---+---+     +----+---+  +----+---+     +-----+--+  +-----+--+
|Proxmox|  |VMware/|     |Minimal |  |Central |     |Veeam   |  |Bareos  |
|VE     |  |Hyper-V|     |infra   |  |mgmt    |     |Acronis |  |        |
+--+---+   +---+---+     +----+---+  +----+---+     +--------+  +--------+
   |           |              |           |
   v           v              v           v
  PBS      Veeam/         restic/      Bareos/
           Acronis        Borg         PBS

Recommendations by organisational context

Minimal IT capacity (no dedicated IT staff)

Primary recommendation: restic with cloud storage

restic’s single-binary deployment and direct cloud storage support minimise infrastructure requirements. Configure with systemd timers or scheduled tasks for automated backups. Cloud storage eliminates local storage management.

Implementation approach:

Deploy restic binary on systems requiring backup
Configure cloud storage backend (Backblaze B2, Wasabi, or S3-compatible)
Create systemd timer or cron job for daily backups
Configure retention policy (7 daily, 4 weekly, 12 monthly typical)
Set up email notifications via script wrapper
Document recovery procedures; test quarterly

Alternative: BorgBackup with borgmatic wrapper provides similar simplicity with enhanced compression.

Established IT function (dedicated IT team)

Primary recommendation: Proxmox Backup Server (virtualised environments) or Bareos (diverse infrastructure)

For Proxmox VE environments, PBS provides native integration with minimal additional infrastructure. For heterogeneous environments including physical servers, multiple hypervisors, and tape libraries, Bareos offers comprehensive coverage.

Implementation approach (PBS):

Deploy PBS as dedicated VM or physical appliance
Configure ZFS storage pool for datastores
Integrate with Proxmox VE cluster
Configure sync jobs to secondary site
Establish verification schedule
Document and test DR procedures

Implementation approach (Bareos):

Deploy Director with PostgreSQL on dedicated server
Configure Storage Daemon(s) based on storage architecture
Deploy File Daemons on protected systems
Define FileSets, Schedules, and Pools
Configure WebUI for operations team
Establish monitoring integration

Specific constraints

Data sovereignty requirements: restic, BorgBackup, Proxmox Backup Server, or Bareos with self-hosted storage. Avoid cloud services from US-headquartered vendors for sensitive data.

Windows-centric environment: Veeam (budget permitting) or Acronis. restic supports Windows but lacks native VSS integration; Bareos Windows agent provides full support.

Tape library requirements: Bareos (strongest tape support) or Veeam. Neither restic nor BorgBackup support tape natively.

Compliance-driven (audit requirements): Veeam or Acronis provide compliance reporting, certifications, and legal hold. Open source tools require building compliance documentation manually.

Migration paths

From	To	Complexity	Approach	Timeline
Manual scripts	restic/Borg	Low	Parallel run, gradual transition	2-4 weeks
restic	BorgBackup	Medium	New repository, historical data via archive	4-8 weeks
BorgBackup	restic	Medium	New repository, historical data via archive	4-8 weeks
Legacy Bacula	Bareos	Low	In-place upgrade path documented	2-4 weeks
Veeam	Bareos	High	Parallel infrastructure, phased migration	3-6 months
Any	Veeam/Acronis	Medium	Parallel run, import tools for some formats	4-8 weeks

External resources

Official documentation

Tool	Documentation	API reference	Release notes
restic	https://restic.readthedocs.io	https://restic.readthedocs.io/en/latest/100_references.html	https://github.com/restic/restic/releases
BorgBackup	https://borgbackup.readthedocs.io	https://borgbackup.readthedocs.io/en/stable/internals.html	https://github.com/borgbackup/borg/releases
Proxmox Backup Server	https://pbs.proxmox.com/docs/	https://pbs.proxmox.com/docs/api-viewer/	https://pbs.proxmox.com/wiki/Roadmap
Bareos	https://docs.bareos.org	https://docs.bareos.org/DeveloperGuide/	https://docs.bareos.org/Appendix/ReleaseNotes.html
Veeam	https://helpcenter.veeam.com	https://helpcenter.veeam.com/docs/backup/rest/	https://www.veeam.com/kb4738
Acronis	https://dl.managed-protection.com/u/cyberprotect/	https://developer.acronis.com	Per-version release notes

Relevant standards

Standard	Relevance	URL
ISO 27001	Information security management	https://www.iso.org/iso-27001-information-security.html
NIST SP 800-184	Cyber security recovery guide	https://csrc.nist.gov/publications/detail/sp/800-184/final
GDPR Article 32	Security of processing (backup encryption)	https://gdpr-info.eu/art-32-gdpr/

Backup, Disaster Recovery, and Archiving

Requirements taxonomy

Functional requirements

Backup operations

Deduplication and storage efficiency

Recovery operations

Disaster recovery

Archiving and retention

Technical requirements

Deployment and hosting

Scalability and performance

Integration architecture

Security requirements

Encryption

Authentication and access control

Security certifications and compliance

Operational requirements

Administration

Monitoring and reporting

Maintenance and support

Data management requirements

Commercial and contractual requirements

Accessibility requirements

Assessment methodology

Functional capability comparison

Backup operations

Deduplication and storage efficiency

Recovery operations

Disaster recovery

Archiving and retention

Technical capability comparison

Deployment and hosting

Integration architecture

Security capability comparison

Encryption

Authentication and access control

Security certifications

Operational capability comparison

Administration

Support comparison

Commercial comparison

Pricing models

Vendor details

Detailed tool assessments

restic

BorgBackup

Proxmox Backup Server

Bareos

Veeam Backup and Replication

Acronis Cyber Protect

Selection guidance

Decision framework

Recommendations by organisational context

Minimal IT capacity (no dedicated IT staff)

Established IT function (dedicated IT team)

Specific constraints

Migration paths

External resources

Official documentation

Relevant standards

See also