Ask ten Linux administrators how they back up their servers and you will get ten different answers — and most of them will involve a shell script, a cron entry, and a strong opinion about why their approach is the only sane one. That fragmentation isn’t a failure of the ecosystem; it’s a reflection of how differently Linux systems get used. A single-purpose web server, a multi-tenant file share, and a fleet of container hosts have almost nothing in common operationally, and the right backup command line tool for one is often the wrong choice for another.
This guide surveys the real options — from raw rsync scripting to purpose-built deduplicating backup tools — and lays out the selection criteria that actually matter: deduplication, encryption, incremental support, remote and cloud targets, and, critically, whether restores get tested at all. It closes with guidance on when a fifteen-line script is the right call and when it’s time to adopt a dedicated tool.
The Case for Scripting: rsync and tar
For a long time, the default Linux backup command line toolkit was whatever shipped in the base OS image: rsync, tar, cron, and maybe ssh for offsite transfer. That combination still works, and for a narrow set of use cases it remains the right answer.
rsync excels at synchronizing file trees efficiently — it transfers only the bytes that changed, which makes it fast for repeated runs against large directory structures. A typical pattern pairs rsync with hard-link rotation (the classic --link-dest approach) to fake incremental snapshots on top of a tool that doesn’t natively understand backup history. It’s simple, well-documented, and installed everywhere, which is precisely its appeal for administrators who want something they can read and modify in five minutes at 2 a.m.
tar, usually invoked from a cron job, takes a different approach: it produces a single archive file, optionally piped through gzip or zstd for compression, and optionally through ssh or an object storage CLI for offsite delivery. tar’s incremental mode (--listed-incremental) provides a genuine incremental backup capability, tracking which files changed since the last run using a snapshot metadata file. Combined with a rotation script for weekly fulls and daily incrementals, this reproduces a fair approximation of “real” backup software using only coreutils-class tools — see our companion piece on incremental vs differential backup for the tradeoffs between that approach and differential schemes.
The honest limitation of both tools is that neither was designed as a backup system. rsync has no native encryption, no deduplication beyond delta-transfer efficiency, and no built-in retention policy — you build all of that yourself, in shell, and you maintain it yourself. tar’s incremental chains are notoriously fragile if a snapshot file is lost or corrupted, and neither tool verifies restorability without you writing that logic separately. For a detailed walkthrough of building a script that handles these gaps responsibly, see our rsync backup script guide.
Purpose-Built Tools: Restic and BorgBackup
Over the past decade, a newer generation of command-line backup tools emerged specifically to solve what rsync and tar leave undone: content-defined deduplication, authenticated encryption, and backup-aware retention policies, all through a single static binary or well-packaged install.
Restic and BorgBackup are the two most commonly cited examples in this category, and they share a broadly similar architecture: both chunk file data, deduplicate chunks across snapshots (so unchanged data is stored once regardless of how many backup runs reference it), encrypt client-side before data leaves the host, and support pruning old snapshots without breaking the chain of remaining ones. Both support a wide range of remote targets — SFTP, S3-compatible object storage, and various cloud backends — which matters enormously for anyone implementing the 3-2-1 backup rule across on-premises and cloud storage tiers.
Where they diverge is mostly in operational philosophy. One tends to favor a repository model with more configuration knobs around compression and chunking, while the other emphasizes a simpler snapshot/restore command surface with strong defaults. Neither is objectively superior across every scenario — teams typically pick based on repository format preferences, existing familiarity, and how their target storage backend is exposed. Both are mature enough that “which one to use” is now the default entry point for practitioners choosing modern command-line backup software, rather than a foundational script.
Encrypted, Incremental Backups: duplicity and Beyond
duplicity predates both of the tools above and remains relevant for a specific reason: it was one of the first widely used Linux backup utilities to combine rsync-style delta transfer (using the librsync algorithm) with strong client-side encryption and a genuine full/incremental backup chain, all shipped as a scriptable command-line utility.
Its architecture — periodic full backups with a chain of incremental deltas layered on top, all GPG-encrypted before upload — was, for years, the closest thing Linux had to an out-of-the-box answer to “how do I get encrypted incremental backups to cloud storage from the command line.” It remains a defensible choice today, particularly in environments already standardized on GPG key management, though its incremental chains carry the same fragility concern as tar’s: lose or corrupt a link in the chain, and the following incrementals become harder to restore in isolation.
Where duplicity has lost ground to the deduplicating tools described above is efficiency at scale. Its incremental model tracks changed files rather than deduplicating content blocks, so it doesn’t shrink storage footprints the way content-defined chunking does when the same data recurs across many machines or snapshots. It’s a solid, encryption-first option; it’s just no longer the newest idea in the room.
Enterprise-Class Command Line Backup: Bacula and Bareos
Everything covered so far assumes a single host or a small, homogeneous fleet managed by one administrator with direct shell access to each machine. That assumption breaks down at enterprise scale, which is the gap that Bacula — and its widely deployed fork, Bareos — fills.
Both are client-server backup systems with a director process, a storage daemon, and file-daemon agents deployed across potentially hundreds of Linux, Unix, and Windows hosts, all driven from a central catalog database and a command-line (or scripted) console. This architecture buys centralized job scheduling, tape and disk pooling, retention policy enforcement across an entire fleet, and reporting that a collection of independent per-host scripts simply cannot replicate. The tradeoff is real: standing up a director, a catalog database, and a fleet of file daemons is a meaningfully larger operational commitment than dropping a static binary onto a box and adding a cron line.
The decision point is less about which tool is “better” and more about scale and governance requirements. A five-server environment rarely justifies a director/catalog architecture. A two-hundred-host environment with compliance reporting obligations usually can’t avoid it.
Selection Criteria That Actually Matter
Marketing copy for backup tools tends to emphasize speed. Speed matters, but it is rarely the deciding factor once you look past the surface. These are the criteria worth weighing deliberately:
Deduplication. Content-defined chunking dramatically reduces storage consumption when backing up similar data repeatedly — full VM images, container layers, or many hosts running the same OS. Tools without it (tar, plain rsync) rely entirely on your retention policy to control storage growth.
Encryption. Client-side encryption, applied before data leaves the source host, matters most when the backup destination is untrusted or third-party infrastructure — including most cloud storage. Server-side encryption at the destination protects data at rest there, but doesn’t protect it in transit or from a compromised storage provider.
Incremental support. True incremental backup, where only changed data is captured after an initial full backup, is what makes frequent backup schedules operationally realistic. The distinction from differential backup — where each backup captures everything since the last full — has direct consequences for restore time and storage; it’s covered in depth separately.
Remote and cloud targets. SFTP, S3-compatible object storage, and other cloud backends are now baseline expectations. This matters especially for anyone building toward an air-gapped backup strategy or evaluating S3 immutable backup with Object Lock, since not every command-line tool integrates cleanly with object-lock or write-once retention semantics.
Restore testing. This is the criterion most often skipped, and the one that matters most. A backup that has never been restored is a hypothesis, not a backup. Any selection process should include a documented, repeatable restore test — not a one-time proof of concept, but a recurring exercise.
Ransomware Resilience and Immutability
No survey of Linux backup command-line tools is complete without addressing the threat model that now dominates backup strategy conversations: ransomware that specifically targets backup repositories before encrypting production data. Attackers who gain administrative access increasingly search for and delete or encrypt accessible backup targets first, precisely because a viable backup is the difference between a ransom negotiation and a routine restore.
This is why offline and immutable backup targets have moved from “nice to have” to a baseline recommendation in federal guidance. CISA’s guidance on backing up business data recommends maintaining backups that are kept offline, encrypted, and regularly tested for restore integrity, specifically because ransomware variants actively seek out and destroy backups they can reach over the network. Command-line tools that support write-once object storage, offline media rotation, or repositories with append-only permissions are directly relevant here — see our deeper treatment of immutable backups and ransomware recovery for implementation patterns.
Script or Dedicated Tool: Making the Call
Given all of the above, when does a lightweight rsync or tar script remain the right choice, and when should a team adopt a dedicated tool?
A script-based approach is defensible when the environment is small and homogeneous, the administrator maintaining it has the time and discipline to test restores regularly, and the data being protected doesn’t carry regulatory retention or encryption requirements. It’s also a reasonable stopgap while evaluating dedicated tools — nothing about adopting Restic or Borg later requires having used them from day one.
A dedicated tool becomes the better call once any of these show up: multiple hosts that would benefit from shared deduplication, a compliance requirement for encryption at rest and in transit, retention policies that need to survive administrator turnover without living only in one person’s head, or a scale where manual script maintenance becomes its own operational risk. NIST’s contingency planning guidance (SP 800-34 Rev. 1) frames this well: backup frequency and method should be driven by data criticality and system impact level, not by whatever happened to be easiest to script first.
It’s also worth noting, as a point of history rather than a recommendation either way, that this corner of the open-source ecosystem has deep roots — an early command-line backup tool for GNU/Linux systems that dates back to the mid-2000s helped establish patterns (configuration-driven full/incremental scheduling, archive rotation) that later tools refined considerably. That lineage is a useful reminder that today’s dedicated tools solve problems the ecosystem has been iterating on for two decades, not a new invention arriving from nowhere.
Whichever path a team takes, the tool choice matters less than the discipline around it: documented retention, tested restores, and a clear-eyed view of RPO vs RTO targets that the chosen approach can actually meet. A perfectly configured tool with untested restores is not meaningfully safer than RAID is not a backup thinking dressed up in better software.
Frequently Asked Questions
Is rsync alone enough for backups?
For a single host with modest requirements, a well-built rsync script with hard-link rotation can function as a backup system, but it provides no native encryption or deduplication and requires you to build retention and restore-testing logic yourself. It’s a reasonable starting point, not a long-term enterprise answer.
What’s the difference between Borg and Restic?
Both provide deduplicating, encrypted, incremental backups from the command line to local or remote/cloud storage. They differ mainly in repository architecture, configuration depth, and default operational style — the practical choice usually comes down to target storage compatibility and team familiarity rather than a clear technical winner.
Do I need encryption for local backups?
Even local-only backups benefit from encryption if the storage media could be lost, stolen, or accessed by unauthorized users — external drives and NAS shares are common exposure points. For any backup leaving the source host, client-side encryption before transit is standard practice.
How often should incremental backups run, and when is a full backup needed?
Frequency should map to data criticality and acceptable recovery point objectives, not convenience. Most schedules run frequent incrementals (hourly to daily) against periodic full backups (weekly to monthly) to bound how many incremental layers a restore must replay.
Can command-line backup tools satisfy compliance requirements?
Yes, provided the tool’s encryption, retention, and access-control capabilities are configured to match the applicable framework and the organization documents and tests its restore process. The tool itself rarely determines compliance — how it’s configured, monitored, and verified does.