Backup Systems

Backup systems create recoverable copies of data at defined intervals, enabling restoration after hardware failure, human error, malicious action, or disaster. The architecture encompasses the software that orchestrates copy operations, the storage media that holds backup data, and the policies that govern what gets backed up, how frequently, and for how long. Effective backup design balances recovery objectives against storage costs, network bandwidth, and operational complexity.

Recovery Point Objective (RPO)

The maximum acceptable age of data at restoration time, measured as elapsed time since the last backup. An RPO of 4 hours means the organisation accepts losing up to 4 hours of work if restoration becomes necessary.

Recovery Time Objective (RTO)

The maximum acceptable duration from failure detection to service restoration. An RTO of 2 hours requires backup systems capable of completing restoration within that window.

Backup Window

The time period allocated for backup operations, constrained by system availability requirements and network capacity. A 6-hour nightly window from 22:00 to 04:00 represents a common pattern for batch backups.

Retention Period

The duration for which backup copies remain available for restoration before deletion or archival. Retention periods derive from operational needs, compliance requirements, and storage economics.

Backup Chain

The sequence of backup files required to perform a complete restoration. Chains begin with a full backup and extend through subsequent incremental or differential backups.

Backup Types

Backup operations fall into four categories distinguished by what data they copy and how they relate to previous backups. The choice between these types determines storage consumption, backup duration, and restoration complexity.

A full backup copies every file within the defined scope regardless of modification state. Full backups are self-contained: restoration requires only the single backup set with no dependencies on prior copies. This independence comes at the cost of time and storage, as each full backup duplicates unchanged data. A 500 GB file server with 5% daily change rate produces 500 GB backup sets whether files changed or not.

An incremental backup copies only files modified since the most recent backup of any type. The first incremental after a full backup captures files changed in that interval; the second incremental captures changes since the first incremental. This approach minimises backup duration and storage consumption but creates restoration dependencies. Restoring from incrementals requires the base full backup plus every incremental in sequence. A Monday full backup followed by Tuesday through Friday incrementals means Friday restoration requires loading five backup sets in order.

A differential backup copies all files modified since the last full backup, ignoring intermediate differentials. Each differential grows larger as time passes since the full backup, but restoration requires only two sets: the full backup plus the most recent differential. This represents a middle ground between full and incremental approaches. The same file server with 5% daily change rate and weekly full backups produces differentials of approximately 25 GB on Monday, growing to 150 GB by Saturday.

A synthetic full backup constructs a complete backup image by combining the previous full backup with subsequent incrementals, producing a new full backup without reading source data again. The backup server performs this assembly during off-peak hours, reducing impact on production systems and network bandwidth. Synthetic fulls enable weekly full backup images while running only incrementals against production systems.

+------------------------------------------------------------------+
|                    BACKUP TYPE COMPARISON                        |
+------------------------------------------------------------------+
|                                                                  |
|  FULL BACKUP (Sunday)                                            |
|  +------------------+                                            |
|  | Complete copy    |  500 GB                                    |
|  | Self-contained   |                                            |
|  +------------------+                                            |
|                                                                  |
|  INCREMENTAL CHAIN (Monday-Saturday)                             |
|  +------+  +------+  +------+  +------+  +------+  +------+      |
|  | Mon  |->| Tue  |->| Wed  |->| Thu  |->| Fri  |->| Sat  |      |
|  | 25GB |  | 25GB |  | 25GB |  | 25GB |  | 25GB |  | 25GB |      |
|  +------+  +------+  +------+  +------+  +------+  +------+      |
|  Restore Saturday: Full + Mon + Tue + Wed + Thu + Fri + Sat      |
|  Total backup storage: 650 GB                                    |
|                                                                  |
|  DIFFERENTIAL CHAIN (Monday-Saturday)                            |
|  +------+  +------+  +------+  +------+  +------+  +------+      |
|  | Mon  |  | Tue  |  | Wed  |  | Thu  |  | Fri  |  | Sat  |      |
|  | 25GB |  | 50GB |  | 75GB |  | 100GB|  | 125GB|  | 150GB|      |
|  +------+  +------+  +------+  +------+  +------+  +------+      |
|  Restore Saturday: Full + Sat differential only                  |
|  Total backup storage: 1025 GB                                   |
|                                                                  |
+------------------------------------------------------------------+

Figure 1: Backup type storage and restoration requirements for a 500 GB dataset with 5% daily change

The selection between incremental and differential backups involves trading storage efficiency against restoration simplicity. Incrementals consume less storage but require sequential processing of each backup in the chain during restoration. A corrupted Wednesday incremental renders Thursday through Saturday incrementals unusable. Differentials consume more storage but depend only on the base full backup, reducing single points of failure in the chain.

Architecture Patterns

Backup architecture determines where backup data resides, how it travels from source to destination, and what redundancy protects against media failure. Four patterns address different combinations of recovery requirements, budget constraints, and geographic distribution.

Local Backup

Local backup stores copies on media physically connected to or located near the source systems. Direct-attached storage, network-attached storage in the same facility, or dedicated backup appliances in the server room constitute local backup infrastructure. Local backup provides the fastest backup and restoration speeds since data moves across local networks or internal buses rather than wide-area links.

+------------------------------------------------------------------+
|                    LOCAL BACKUP ARCHITECTURE                     |
+------------------------------------------------------------------+
|                                                                  |
|  +------------------+         +------------------+               |
|  |  Production      |         |  Backup          |               |
|  |  Servers         |         |  Storage         |               |
|  |                  |         |                  |               |
|  |  +------+        |   LAN   |  +-------+       |               |
|  |  | VM 1 |--------+----+--->|  | Disk  |       |               |
|  |  +------+        |    |    |  | Array |       |               |
|  |  +------+        |    |    |  +-------+       |               |
|  |  | VM 2 |--------+----+    |       |          |               |
|  |  +------+        |    |    |       v          |               |
|  |  +------+        |    |    |  +-------+       |               |
|  |  | DB   |--------+----+    |  | Tape  |       |               |
|  |  +------+        |         |  | Lib   |       |               |
|  +------------------+         |  +-------+       |               |
|                               +------------------+               |
|                                                                  |
|  Backup speed: 100-500 MB/s (limited by storage throughput)      |
|  Restore speed: 100-500 MB/s                                     |
|  Protection: Hardware failure only (not site disaster)           |
|                                                                  |
+------------------------------------------------------------------+

Figure 2: Local backup architecture with disk-to-disk-to-tape staging

Local backup alone fails to protect against site-level disasters: fire, flood, theft, or ransomware that propagates across the local network can destroy both production data and backup copies simultaneously. Local backup serves as the first tier in multi-tier architectures, providing rapid recovery for common failure scenarios while other tiers protect against catastrophic events.

Remote Backup

Remote backup transmits copies to storage at a geographically separate location, protecting against site-level disasters. The separation distance depends on the risk profile: a secondary office 50 kilometres away protects against building fires but not regional earthquakes; a site 500 kilometres away in a different seismic zone provides broader protection.

Remote backup introduces network bandwidth as a constraint. A 100 Mbps WAN link transmits approximately 45 GB per hour under ideal conditions, requiring 11 hours to transfer a 500 GB full backup. Organisations with large datasets and limited bandwidth implement incremental-forever strategies that transmit only changes after an initial seed, or physically transport storage media for the initial full backup.

Latency affects backup performance for applications that checkpoint frequently or use synchronous backup modes. A 50 millisecond round-trip time between source and remote storage limits transaction-consistent database backups to approximately 20 transactions per second if each transaction must confirm remote write completion before proceeding.

Cloud Backup

Cloud backup transmits copies to storage services operated by cloud providers, eliminating the need to provision and maintain secondary infrastructure. Cloud storage pricing follows consumption-based models where costs scale with stored volume, retrieval frequency, and data transfer.

Storage tiers in cloud environments offer different cost and performance characteristics. Hot storage provides immediate access at higher per-gigabyte costs. Archive storage costs 5-10x less per gigabyte but imposes retrieval delays of hours to days and per-retrieval charges. A 10 TB backup archive stored in cold tier at $0.004 per GB per month costs $40 monthly for storage, but retrieving that data at $0.02 per GB adds $200 to the monthly bill.

Cloud backup introduces data sovereignty considerations. Backup data containing personal information falls under the same regulatory requirements as production data. Storing backups in a different jurisdiction than production systems creates compliance complexity when regulations restrict cross-border data transfer. Major cloud providers offer region-specific storage with guarantees about data location, but organisations must verify that backup software respects these constraints and does not inadvertently replicate to other regions.

Hybrid Architecture

Hybrid backup combines local and remote tiers to balance recovery speed against disaster protection. Local copies serve rapid recovery for common scenarios: accidental deletion, file corruption, or hardware failure. Remote or cloud copies provide disaster recovery capability when the primary site becomes unavailable.

+------------------------------------------------------------------+
|                    HYBRID BACKUP ARCHITECTURE                    |
+------------------------------------------------------------------+
|                                                                  |
|  PRIMARY SITE                       SECONDARY SITE / CLOUD       |
|  +--------------------+             +--------------------+       |
|  |                    |             |                    |       |
|  |  +------+          |   WAN /     |  +--------+        |       |
|  |  | Prod |          |   Internet  |  | Remote |        |       |
|  |  | Data |          |             |  | Backup |        |       |
|  |  +--+---+          |             |  | Store  |        |       |
|  |     |              |             |  +---+----+        |       |
|  |     | Backup       |             |      ^             |       |
|  |     v              |             |      |             |       |
|  |  +-------+         |             |      |             |       |
|  |  | Local |---------+-------------+------+             |       |
|  |  | Backup|    Replicate          |                    |       |
|  |  | Store |         |             |                    |       |
|  |  +-------+         |             +--------------------+       |
|  |                    |                                          |
|  +--------------------+                                          |
|                                                                  |
|  Restore scenarios:                                              |
|  - File recovery: Local (minutes)                                |
|  - Server failure: Local (hours)                                 |
|  - Site disaster: Remote (hours to days)                         |
|                                                                  |
+------------------------------------------------------------------+

Figure 3: Hybrid architecture with local backup replicated to remote storage

The 3-2-1 rule provides a framework for hybrid architecture: maintain 3 copies of data on 2 different media types with 1 copy offsite. Applied to a file server, this translates to the production data (copy 1), local backup on disk or tape (copy 2, different media), and cloud backup (copy 3, offsite). The rule predates cloud computing but remains valid as a minimum standard for data protection.

+------------------------------------------------------------------+
|                    3-2-1 BACKUP IMPLEMENTATION                   |
+------------------------------------------------------------------+
|                                                                  |
|                         PRODUCTION DATA                          |
|                         (Copy 1)                                 |
|                              |                                   |
|              +---------------+---------------+                   |
|              |                               |                   |
|              v                               v                   |
|  +--------------------+         +--------------------+           |
|  |   LOCAL BACKUP     |         |   CLOUD BACKUP     |           |
|  |   (Copy 2)         |         |   (Copy 3)         |           |
|  |                    |         |                    |           |
|  |   Media: Disk      |         |   Media: Object    |           |
|  |   Location: Onsite |         |   Location: Offsite|           |
|  |   Retention: 30d   |         |   Retention: 1yr   |           |
|  +--------------------+         +--------------------+           |
|                                                                  |
|  3 copies: Production + Local + Cloud                            |
|  2 media types: Production disk + Backup disk + Cloud object     |
|  1 offsite: Cloud storage in different region                    |
|                                                                  |
+------------------------------------------------------------------+

Figure 4: 3-2-1 rule implementation with local and cloud tiers

Scheduling and Windows

Backup scheduling determines when backup operations execute, balancing recovery point objectives against system availability and resource constraints. The backup window defines the time available for backup operations to complete without impacting production workloads.

Nightly batch backups represent the traditional scheduling pattern: full system backups run during overnight hours when user activity falls and network bandwidth becomes available. An organisation operating 08:00-18:00 in a single timezone gains a 14-hour window for backup operations. This window shrinks for organisations spanning multiple timezones or operating 24-hour services.

Continuous data protection eliminates scheduled windows by capturing changes as they occur. Journal-based systems record every write operation to a change log, enabling point-in-time recovery to any moment rather than to scheduled backup points. This approach achieves RPO measured in seconds rather than hours but generates substantial storage overhead as every change propagates to backup storage.

Application-aware scheduling coordinates backups with application state to ensure consistency. Database backups execute during transaction lulls or use snapshot mechanisms that capture a consistent point-in-time image. Email servers quiesce connections before backup and resume afterward. Backup software integrates with applications through agents or APIs that coordinate these transitions.

The backup window calculation considers data volume, change rate, and available bandwidth. A 2 TB dataset with 10% daily change rate requires backing up 200 GB of changed data nightly using incremental strategy. At 100 MB/s throughput, this completes in approximately 35 minutes. Weekly full backups of the entire 2 TB require 5.5 hours. Scheduling must accommodate both the rapid nightly incrementals and the extended weekly full backup window.

Retention Implementation

Retention policies specify how long backup copies remain available before deletion. These policies balance recovery capability against storage costs and compliance requirements. A simple retention policy keeping 30 daily backups provides one month of recovery points. More sophisticated policies implement tiered retention with different periods for daily, weekly, monthly, and yearly backups.

A grandfather-father-son (GFS) rotation scheme maintains three retention tiers. Daily backups (sons) rotate through a short cycle, weekly backups (fathers) through a longer cycle, and monthly or yearly backups (grandfathers) persist for extended periods. A typical GFS implementation retains 7 daily backups, 4 weekly backups, and 12 monthly backups, providing granular recovery within the past week, weekly recovery points for the past month, and monthly recovery points for the past year.

# Example retention configuration (restic format)
KEEP_DAILY=7
KEEP_WEEKLY=4
KEEP_MONTHLY=12
KEEP_YEARLY=3

This configuration produces approximately 26 backup generations: 7 daily + 4 weekly + 12 monthly + 3 yearly. Storage requirements depend on deduplication efficiency; a 500 GB dataset with 5% daily change and effective deduplication might require 800 GB total storage rather than 13 TB (26 × 500 GB) without deduplication.

Compliance requirements from donors, regulators, or organisational policy impose minimum retention periods. Financial records under UK law require 6-year retention. GDPR constrains maximum retention for personal data to what is necessary for the processing purpose. Backup systems must support both minimum and maximum retention requirements, automatically deleting data that exceeds maximum retention even when storage capacity permits longer retention.

Legal holds suspend normal retention processing when litigation or investigation requires preserving specific data. Backup systems must support holds that prevent deletion of designated backups regardless of normal retention policy expiration. Hold management requires clear procedures and designated authority to impose and release holds.

Encryption and Security

Backup data requires protection commensurate with the sensitivity of the source data. Encryption prevents unauthorised access to backup media, whether in storage, transit, or after loss or theft. Access controls limit who can initiate backups, view backup contents, and perform restorations.

Encryption at rest protects stored backup data using symmetric encryption algorithms. AES-256 represents the current standard, providing security against both current and anticipated future attack capabilities. The encryption key becomes the critical security element: backup data is recoverable only by parties possessing the correct key.

Key management determines whether encryption delivers actual security or merely complexity. Storing encryption keys alongside encrypted backup data provides no protection; an attacker gaining access to storage gains keys and data together. Secure key management stores keys separately from encrypted data, maintains key escrow for organisational continuity, and rotates keys periodically without re-encrypting historical data.

# Encryption configuration example
ENCRYPTION_ALGORITHM=AES-256-GCM
KEY_DERIVATION=PBKDF2-SHA256
KEY_ITERATIONS=600000
KEY_SOURCE=external-kms
KEY_ID=backup-master-2024

Encryption in transit protects data moving between source systems and backup storage. TLS 1.3 encrypts network connections; additional payload encryption protects against compromised network infrastructure. VPN tunnels or dedicated circuits provide alternatives for organisations with specific network security requirements.

Immutability protects backups against modification or deletion after creation, defending against ransomware that attempts to destroy backup copies. Object storage with object lock, WORM (write-once-read-many) tape, or air-gapped systems that disconnect from networks after backup completion provide immutability guarantees. Immutable backups require careful retention planning since data cannot be deleted until the immutability period expires.

Access control restricts backup operations to authorised personnel. Role separation ensures that system administrators responsible for production systems do not have unsupervised access to delete or modify backups. The backup administrator role holds authority over backup configuration and restoration; the security administrator role holds authority over encryption keys; neither role alone can both access and decrypt backup data without audit.

Deduplication and Compression

Deduplication identifies and eliminates redundant data blocks across backup sets, dramatically reducing storage consumption when backing up similar or unchanged data. Source-side deduplication performs this analysis before transmission, reducing network bandwidth. Target-side deduplication performs analysis at the backup storage, simplifying client configuration at the cost of full data transmission.

Block-level deduplication segments data into chunks (typically 4-64 KB), computes hash values for each chunk, and stores only unique chunks. A 1 MB file modified with 100 KB of changes produces only 100 KB of new storage consumption when deduplication identifies and references the unchanged 900 KB from existing storage.

Deduplication ratios measure storage efficiency, expressed as the ratio of original data size to stored data size. A 20:1 deduplication ratio means 20 TB of backup data occupies 1 TB of physical storage. Actual ratios depend on data characteristics: virtual machine backups with common operating system images achieve 30:1 or higher; encrypted or already-compressed data achieves minimal deduplication near 1:1.

Global deduplication compares data across all backup jobs and clients, maximising storage efficiency. Ten virtual machines running identical operating systems deduplicate the shared operating system blocks once rather than ten times. Global deduplication requires more computational resources and memory to maintain the global index of known blocks.

Compression reduces storage requirements for unique data blocks. LZ4 provides fast compression with moderate ratios suitable for backup workloads where throughput matters. ZSTD offers higher compression ratios with configurable CPU usage. Compression applies after deduplication to the unique blocks.

Combined deduplication and compression produces dramatic storage reduction for typical backup workloads:

The storage efficiency calculation affects both capacity planning and cost estimation. Cloud backup pricing based on stored volume makes deduplication a direct cost control mechanism. A 15 TB file server backup archive costing $60/month at $0.004/GB compressed cloud storage rate would cost $750/month without deduplication and compression.

Workload-Specific Backup

Different workload types require specific backup approaches to ensure data consistency and application recoverability. A file-level backup of a running database captures inconsistent state; proper database backup coordinates with the database engine to capture a consistent point-in-time image.

Virtual Machine Backup

Virtual machine backup operates at the hypervisor level, capturing entire VM images including operating system, applications, and data. Hypervisor integration enables snapshot-based backup that freezes VM state, copies data, and releases the freeze with minimal disruption.

Changed Block Tracking (CBT) optimises incremental VM backup by recording which disk blocks changed since the last backup. The backup operation reads only changed blocks rather than scanning entire virtual disks. A 500 GB virtual disk with 5 GB daily change completes incremental backup by reading 5 GB rather than scanning 500 GB to identify changes.

Application consistency requires coordination with guest operating systems. VMware Tools or Hyper-V Integration Services signal guest applications to quiesce before snapshot creation, ensuring consistent application state. Database engines flush transactions to disk; file systems complete pending writes. Without guest coordination, snapshots capture crash-consistent rather than application-consistent images.

Database Backup

Database backup captures logically consistent copies of database contents, enabling point-in-time recovery to any transaction. Native database backup tools understand transaction boundaries and produce consistent backups without application downtime.

Transaction log backup captures the sequence of changes since the last backup, enabling recovery to any point in time covered by retained logs. SQL Server, PostgreSQL, and MySQL all support transaction log backup with point-in-time recovery. Losing transaction logs limits recovery to the last full backup, potentially losing hours of transactions.

The backup sequence for transactional databases combines full backups, differential backups, and transaction log backups. A typical strategy executes weekly full backups, daily differential backups, and hourly transaction log backups. Recovery to a specific point in time applies the most recent full backup, the most recent differential, and all transaction logs up to the recovery target.

# PostgreSQL backup configuration example
# Full backup: Sunday 02:00
pg_basebackup -D /backup/full/$(date +%Y%m%d) -Ft -z -P

# Transaction log archiving: continuous
archive_command = 'cp %p /backup/wal/%f'

# Recovery command for point-in-time recovery
restore_command = 'cp /backup/wal/%f %p'
recovery_target_time = '2024-03-15 14:30:00'

SaaS Application Backup

SaaS application backup addresses the shared responsibility model where providers ensure service availability but organisations remain responsible for data protection. Microsoft 365, Google Workspace, and Salesforce provide recycle bins and version history but not comprehensive backup and long-term retention.

Third-party backup tools connect via API to extract data from SaaS applications. Backup scope includes email, calendar, contacts, files, and application-specific data. Restoration capabilities vary: some tools restore to the original location; others export to local storage for manual re-import.

API rate limits constrain SaaS backup throughput. Microsoft Graph API permits 10,000 requests per 10 minutes per application; large tenants require multiple days for initial full backup. Incremental backup uses delta queries to identify changes since last backup, operating within rate limits for ongoing protection.

Licensing costs for SaaS backup add to operational expenses. Per-user pricing from $3-10 per user per month makes backup cost proportional to organisation size. A 500-user organisation pays $1,500-5,000 monthly for comprehensive SaaS backup coverage.

Endpoint Backup

Endpoint backup protects data on laptops, desktops, and mobile devices. The challenge differs from server backup: endpoints disconnect from networks, operate on battery power, and contain data intermixed with user-specific application state.

Continuous or frequent incremental backup suits endpoints better than scheduled nightly windows. Users work throughout the day; a nightly backup window misses data created in the hours before the next scheduled backup. Continuous backup captures changes as users save files.

Bandwidth management prevents endpoint backup from consuming network capacity. Throttling limits backup throughput during working hours; background priority yields to user traffic; deduplication minimises transmitted data. A well-configured endpoint backup client operates invisibly, consuming minimal battery and bandwidth.

The scope of endpoint backup requires policy decisions. Operating system files reinstall from media; application data restores from servers; only user-created files require backup. Exclusion rules skip system directories, caches, and media libraries available from other sources. A typical endpoint backup policy protects Desktop, Documents, and application data directories while excluding Downloads, system files, and large media collections.

Field Office Backup

Field offices present unique backup challenges: intermittent connectivity, limited bandwidth, unreliable power, and physical security risks. Standard backup architectures designed for headquarters environments require adaptation.

Bandwidth constraints limit the data volume transferable to central backup infrastructure. A 2 Mbps satellite link transmits approximately 900 MB per hour; backing up 100 GB requires 110 hours of continuous transmission. Strategies for bandwidth-constrained environments include aggressive local deduplication, extended backup windows spanning multiple nights, and initial seed via physical media transport.

Connectivity interruptions require backup systems that resume gracefully after network outages. Checkpoint-based protocols track transfer progress and resume from the last confirmed point rather than restarting. A 50 GB incremental backup interrupted at 40 GB continues from 40 GB rather than restarting.

Local backup provides protection independent of connectivity. Field office servers maintain local backup copies that protect against hardware failure and human error without requiring central connectivity. USB drives, NAS devices, or dedicated backup appliances store local copies. Physical security measures protect local backup media from theft: locked cabinets, encryption at rest, and geographically distributed copies within the field location.

Power reliability affects backup completion. Uninterruptible power supplies (UPS) provide runtime to complete in-progress backups during brief outages. Backup scheduling coordinates with generator operation windows where fuel conservation limits generator runtime. Solar-powered sites schedule intensive backup operations during peak solar production when power availability is highest.

Encryption becomes critical when backup media might be lost, stolen, or seized. Field environments carry higher risks of physical access by unauthorised parties. All field backup media should use strong encryption with keys stored separately from the media. A lost encrypted USB drive reveals nothing to the finder; an unencrypted drive exposes all backup contents.

Verification Principles

Backup verification confirms that backup operations complete successfully and that backed-up data remains recoverable. Verification operates at multiple levels: job completion, data integrity, and restoration capability.

Job completion monitoring confirms that scheduled backups execute and finish within expected parameters. Backup management consoles report job status, duration, and data volume. Alerting notifies administrators when jobs fail, run longer than expected, or back up less data than historical patterns predict. A file server normally backing up 50 GB nightly that suddenly backs up only 5 GB warrants investigation.

Data integrity verification confirms that stored backup data remains uncorrupted and readable. Checksums computed during backup compare against checksums verified during periodic integrity scans. Media verification reads backup data and confirms it matches original checksums. Tape libraries perform verification reads after writes; disk-based systems schedule periodic verification scans.

Restoration testing provides the definitive verification: attempting actual recovery and confirming success. Monthly restoration tests select random files and complete restoration to alternate locations. Quarterly tests perform full system restoration to non-production infrastructure. Annual disaster recovery exercises test complete recovery procedures including personnel, documentation, and infrastructure provisioning.

The verification schedule balances thoroughness against operational burden. More frequent testing catches problems earlier but consumes administrator time and infrastructure resources. A minimum viable verification programme includes daily job completion monitoring, weekly integrity spot checks, monthly file restoration tests, and annual full system recovery tests.

Technology Options

Backup software ranges from single-purpose utilities to enterprise platforms integrating backup, disaster recovery, and data management. Selection criteria include workload support, scalability, operational complexity, and total cost.

Open Source

Restic provides encrypted, deduplicated backup to local storage, cloud object storage (S3, Azure Blob, Google Cloud Storage, Backblaze B2), or SFTP targets. The command-line interface suits automation and scripting. Restic lacks centralised management for multiple clients; each installation operates independently.

BorgBackup offers deduplication, compression, and encryption with a focus on efficiency and reliability. Like Restic, Borg operates via command line and suits technical users comfortable with scripting. BorgBackup requires SSH access between clients and backup storage.

Bacula provides enterprise-scale backup with central management, tape support, and multi-platform clients. Bacula Community Edition is open source; Bacula Enterprise adds commercial support and additional features. The architecture separates director (management), storage daemon, and file daemon (client) roles, scaling to large environments.

Bareos forked from Bacula and continues independent development with similar architecture. Bareos emphasises active development and community engagement. Both Bacula and Bareos require more configuration expertise than simpler tools.

Proxmox Backup Server integrates with Proxmox virtualisation but also backs up individual Linux hosts. Deduplication, compression, and encryption are built in. The web interface provides management without command-line expertise. Proxmox suits organisations already using Proxmox VE for virtualisation.

Commercial with Nonprofit Programmes

Veeam provides comprehensive backup for virtual machines, physical servers, cloud workloads, and SaaS applications. Veeam Community Edition supports up to 10 workloads free of charge. Larger deployments require licensing; Veeam offers nonprofit pricing through resellers.

Acronis combines backup with cybersecurity features including anti-ransomware protection. Acronis provides cloud backup infrastructure, eliminating the need for separate cloud storage accounts. Nonprofit pricing is available.

Duplicati operates as open source with optional commercial support. The web interface makes configuration accessible to non-technical users. Duplicati supports numerous cloud storage backends.

Commvault and Veritas NetBackup target large enterprises with heterogeneous environments. Licensing costs are substantial but both vendors offer nonprofit programmes. These platforms suit organisations with dedicated backup administrators and complex requirements spanning multiple data centres.

Selection Criteria

Implementation Considerations

For organisations with limited IT capacity

A single IT person managing backup alongside other responsibilities benefits from simpler tools with less configuration overhead. Restic or Duplicati provide effective backup with minimal ongoing management. Cloud storage backends eliminate local backup infrastructure. A basic implementation protects servers with nightly backup to cloud storage:

1. Deploy Restic on each server
2. Configure cloud storage credentials
3. Create shell scripts for backup and retention
4. Schedule via cron
5. Configure email alerts for failures

This approach achieves 3-2-1 compliance (production, local cache, cloud) with a few hours of initial setup and minimal ongoing maintenance. Start with file servers and databases; add endpoints if capacity permits.

For organisations with established IT functions

Larger IT teams can justify more sophisticated backup infrastructure with central management, policy-based configuration, and integrated monitoring. Veeam or a mature open source platform like Bacula provides enterprise features. Consider implementing:

1. Dedicated backup infrastructure (server, storage, network segment)
2. Central management console with delegated administration
3. Policy-based backup configuration by workload type
4. Integrated monitoring with service management
5. Documented restore procedures and regular testing
6. Encryption key management integrated with organisational KMS

For field deployments

Field office backup requires specific attention to connectivity, power, and physical security:

1. Local backup to encrypted storage provides connectivity-independent protection
2. WAN backup uses aggressive deduplication and resumable transfers
3. Backup scheduling coordinates with power availability and connectivity windows
4. Encryption protects all local media
5. Physical security measures protect backup devices
6. Periodic physical transport of encrypted media to headquarters supplements electronic transfer

See also

• Backup and Recovery Standard
• Backup Verification
• Data Backup and Recovery
• High Availability and Disaster Recovery
• Storage Architecture
• Cloud Compute and Storage