Backup tool selection - choosing the right tool for the workload · Linux

Choosing the right backup tool is a function of workload size, recovery requirements, and operational fit. This lesson covers the decision framework.

Decision framework

Choose the tool based on:

Data volume: 1 GB vs 1 TB vs 1 PB.
Application type: files vs databases vs VMs.
Recovery time: minutes vs hours vs days.
Retention: 7 days vs 30 days vs 7 years.
Compliance: SOC2, PCI-DSS, HIPAA, GDPR.
Operational fit: team skills, existing stack.

Tool choices by workload

Small workload (1-100 GB)

BorgBackup or Restic for self-managed.
S3 + Object Lock for immutable offsite.
Weekly test restore.

Medium workload (100 GB - 10 TB)

BorgBackup or Restic for self-managed.
Veeam if application-aware needed.
S3 + Object Lock or tape rotation.

Large workload (10 TB - 1 PB)

NetBackup, Rubrik, Cohesity, Commvault for central management.
Deduplication, replication, cloud tier.
Comprehensive compliance features.

VM-heavy workload

Hypervisor-level snapshots (VMware, KVM, etc.).
Veeam, Rubrik, Cohesity for VM-aware backup.
Application-aware backup for database VMs.

Match the tool to the recovery requirements

Requirement	Tool
RTO 1 hour, RPO 15 min	Enterprise with replication
RTO 4 hours, RPO 1 day	BorgBackup + S3
RTO 24 hours, RPO 1 week	`tar` to LTO via `mt`, or Bacula/Bareos to a tape library
Compliance: 7-year retention	Enterprise with archive tier

rsync cannot write to tape

“rsync + tape” appears in a lot of backup plans and it does not work. rsync synchronises directory trees: it stats the destination, compares, and writes files at arbitrary offsets. A tape drive is a sequential character device — /dev/nst0 has no directory, nothing to stat, and no seek. rsync has no tape support of any kind.

What writes tape is a program that produces one sequential stream: tar or dd positioned with mt, or a backup server (Bacula, Bareos, Amanda, or a commercial product) that owns the drive and the media catalogue. The catalogue is the part people skip and then regret — without it, “which tape holds /etc from March?” is answered by mounting tapes until one matches.

The workable pattern if you already have rsync in the design is two hops: rsync to disk, then stream that disk tree to tape with tar. Do not plan for the one-hop version, because you will find out it is impossible on the day you first try to write the tape.

Avoid over-engineering

A small workload does not need an enterprise backup tool. A 1-host setup with 10 GB does not need Rubrik. The right tool is the one that meets the requirements without unnecessary complexity.

Common over-engineering:

Enterprise backup tooling for a 5-host fleet.
30-day retention when the compliance requirement is 7 days.
Deduplication on a dataset small enough that it buys nothing.
Cross-region synchronous replication when an asynchronous nightly copy already meets the RPO.

Not over-engineering, at any scale:

The offsite copy. It is the 1 in 3-2-1, and the only control that survives the loss of the site — fire, flood, theft, or a ransomware event that reaches the local backup target. Scale how you do it, never whether: an encrypted nightly push to object storage costs very little and is a complete offsite copy.

'DR is unlikely' is not a reason to skip the offsite copy

Every organisation that lost its backups to ransomware had assessed DR as unlikely. The relevant property of a site-loss event is not its probability but that it takes the local backup with it — which is precisely the condition under which you need a backup.

Disaster scenarios puts ransomware at the top of the list for most organisations post-2020, and ransomware specifically targets reachable backup shares. A local-only backup is not a degraded version of 3-2-1; for the most common modern scenario it is no backup at all.

The judgement call that is legitimate here is RPO and cost: nightly versus continuous, object storage versus a second site, immutable retention versus versioning. Make that decision explicitly, and record it. “We decided the offsite copy was not worth it” is a decision that has to be signed off by whoever owns the consequence, not made implicitly by an engineer sizing a backup tool.

When to upgrade tools

Upgrade when:

The fleet grows beyond what the current tool handles.
The compliance requirements change.
The recovery time is too slow.
The operational cost is too high.

Do not upgrade before the requirements demand it.