Rclone vs. Rsync

It’s common for infrastructure teams to synchronize files between servers, but the choice between rclone and rsync matters far more than you might think. Both are command-line tools designed for different purposes, and choosing the wrong one can cost you months of failed backups, bandwidth overages, and missed recovery time objectives.

Here’s the hard truth: your backup tool is only as fast as your storage infrastructure allows. We’ve seen teams deploy rclone expecting dramatic speed improvements only to see it bottlenecked by storage systems that can’t handle parallel operations. We’ve watched rsync choke on petabyte-scale migrations that should have completed in weeks, not months.

This guide walks you through the actual differences between these tools, shows you real performance data from independent testing, and explains the gotchas nobody mentions until you hit them in production.

About This Guide: Performance benchmarks cited are from independent testing and community reports. Configuration examples are provided for illustration and should be tested in your specific environment before production deployment. Storage performance characteristics discussed are based on general architectural principles.

What Is Rclone? The Cloud-Native Sync Tool

Rclone is a command-line tool specifically designed for copying files between cloud storage providers and servers. Think of it as the bridge between your infrastructure and the cloud—it speaks the language of S3, Azure Blob, Google Cloud Storage, and 50+ other cloud providers natively.

Core characteristics:

• Cloud-first design: Built specifically for object storage APIs
• Unidirectional: Copies from source to destination (not bidirectional sync)
• Parallel transfers: Processes multiple files simultaneously for speed
• Recovery-capable: Can resume interrupted transfers without restarting
• Lightweight: No system daemons or background services required

Rclone excels when you’re working with cloud storage—whether that’s initial migration, ongoing sync, or cloud-to-cloud replication. It supports Amazon S3 buckets, Microsoft Azure Blob and File Storage, Google Cloud Storage, Dropbox, OneDrive, and many others.

The critical insight: rclone’s parallelism means it can saturate high-bandwidth connections if your storage backend can keep up. If your storage can’t deliver sufficient IOPS, rclone could just sit waiting.

What Is Rsync? The Bidirectional Delta Specialist

Rsync is the battle-tested utility that’s been part of Unix/Linux systems for decades. Unlike rclone, rsync performs true synchronization—it compares source and destination, identifies differences, and copies only what’s changed.

Core characteristics:

• Bidirectional sync: Files can be updated on either source or destination
• Delta algorithm: Transmits only changed portions of files, not full files
• Attribute preservation: Maintains file permissions, ownership, timestamps
• Single-threaded: Processes one file at a time (mostly)
• SSH-native: Integrates seamlessly with SSH for secure transport

Rsync is unbeatable for keeping two systems in sync—especially when bandwidth efficiency matters. It’s the foundation of incremental backup strategies across enterprises because it minimizes data transmission.

The critical limitation: rsync’s single-threaded nature means it can’t saturate modern high-bandwidth connections. On high-speed networks, rsync typically achieves a fraction of available bandwidth, with the rest of the pipe sitting idle.

Performance Showdown: When Speed Actually Matters

Let’s be direct about the performance difference, because this is where tool selection gets consequential.

Independent performance testing by Jeff Geerling revealed dramatic differences between the two tools:

Test Scenario	Tool	Time	Speed Advantage
10,000 files, ~100GB over network	Rsync (default)	8 minutes 54 seconds	Baseline
Same workload	Rclone (–transfers 16)	3 minutes 54 seconds	2.3x faster

Key findings from testing:

• Rclone’s multi-threaded approach processes multiple files simultaneously
• Rsync’s single-threaded design creates a sequential bottleneck
• For large file counts, the parallelism advantage compounds dramatically

The Storage Performance Factor

Here’s the critical variable most comparisons miss: your storage backend determines whether rclone’s parallelism advantage is realized or wasted.

How storage architecture impacts sync performance:

Storage Characteristic	Impact on Parallel Tools	Impact on Serial Tools
High latency (10-50ms)	Parallel operations queue waiting for storage responses	Single-threaded already slow; latency adds marginally
Low concurrent operation limit	Parallelism bottlenecks at storage ceiling	Less affected—already serial
Sub-millisecond response times	Parallel operations complete rapidly; full tool advantage realized	Marginal improvement—still serial bottleneck
High IOPS capacity	Multiple streams can operate simultaneously at full speed	Single stream underutilizes available capacity

What this means practically:

• Deploying rclone on storage with 20ms latency and 200 concurrent operations limit won’t give you 4x speed improvement
• The tool can only go as fast as your storage allows
• High-performance all-flash storage with sub-millisecond latency removes storage as the bottleneck, allowing rclone to show its true performance advantage

When to Use Rclone

Use rclone if:

• Cloud storage is your source or destination (AWS S3, Azure Blob, GCS, etc.)
• You need maximum transfer speed over high-bandwidth connections
• Unidirectional copy is acceptable (you don’t need bidirectional sync)
• You’re handling millions of small files (cloud parallelism advantage is massive)
• Connection reliability is a concern—you need to resume interrupted transfers
• You want to avoid cloud egress fees by syncing within-cloud (AWS → Azure)
• You’re seeding initial cloud backups before switching to incremental

Don’t use rclone if:

• You need bidirectional synchronization (files update on both sides)
• You must preserve extended file attributes (especially Mac extended attributes—rclone can’t copy them¹)
• Your workflow depends on deleting files from one side and having deletion reflected elsewhere
• You’re working entirely with local/on-premises NFS/SMB shares

When to Use Rsync

Use rsync if:

• You need true bidirectional synchronization with delta validation
• File attributes (permissions, ownership, timestamps) must be preserved
• Bandwidth efficiency is critical—you can’t afford to retransmit unchanged data
• You’re working over SSH between Unix/Linux systems
• You need simple, battle-tested, zero-dependencies implementation
• Incremental backups of large file sets where 95% doesn’t change
• You’re synchronizing between data centers with limited bandwidth

Don’t use rsync if:

• Your primary destination is cloud object storage (rsync isn’t designed for it)
• You need to saturate modern multi-gigabit network connections
• You’re migrating hundreds of terabytes—timeline matters more than bandwidth cost
• You need fast recovery from network interruptions (rsync often restarts from scratch)

When to Use BOTH (The Winning Architecture)

The most sophisticated backup architectures use both tools in complementary roles:

Initial Cloud Seeding: Rclone parallel upload to seed cloud backup

• Fast: Weeks instead of months to move petabytes
• Bandwidth-intensive: But acceptable for one-time operation

Ongoing Incremental Sync: Rsync delta transfers between datacenters

• Efficient: Only transmits changed data
• Bandwidth-conservative: Fits within production network constraints

Result: You get rclone’s speed for initial movement and rsync’s efficiency for ongoing incremental updates—optimal cost/performance for your backup window.

Honest Assessment: Common Pitfalls and How to Avoid Them

Every tool has gotchas. Knowing them beforehand saves your bacon when you’re troubleshooting at 3 AM.

Rclone Gotchas (Learn From Others’ Pain)

Broken Symlinks Cause Silent Failures

The problem: Rclone errors on symlinks pointing to non-existent targets (like old lock files or temporary directories that were deleted)¹

What happens: Rclone hits its error threshold and stops without completing the transfer—you don’t notice immediately because the tool exits normally

How to avoid:

Mac Extended Attributes Get Lost

The problem: Rclone cannot copy extended attributes from Mac to Mac.¹ This includes resource forks, Finder metadata, and other Mac-specific file information

What happens: Your Mac backup lacks filesystem metadata; recovered files won’t behave identically

How to avoid: Use rsync for Mac-to-Mac backups; use rclone only when destination is cloud storage

MD5 Verification Slows Transfers

The problem: By default, rclone computes checksums after transfers for integrity verification. Community users report this can be “extremely slow” and negate overall speed advantages

What happens: You get the overhead of parallelism without the speed benefit

How to avoid:

Large File Lists Consume Excessive Memory

The problem: Rclone loads entire file list into memory before starting transfers. With tens of millions of files, this can exceed available RAM

How to avoid:

Rsync Gotchas (The Classic Mistakes)

Single-Threaded Performance Ceiling

The problem: Rsync processes one file at a time, maximum. Even on high-speed networks, you’ll see only a fraction of available bandwidth utilized

What happens: You can’t saturate your network pipe; backup windows extend beyond acceptable maintenance windows

How to work around:

Not a True Backup System

The problem: Rsync doesn’t maintain version history. If you delete a file from source, rsync deletes it from destination too—no recovery possible

What happens: Accidental deletion or ransomware that corrupts files on source propagates to backup

How to avoid: Combine rsync with snapshot-based storage or immutable backup destinations:

–checksum Flag Destroys Performance

The problem: Adding –checksum forces rsync to read entire files and compute checksums instead of relying on modification time. This can dramatically increase backup time

What happens: Backups that should fit in 4-hour maintenance window take significantly longer

How to avoid:

Large Backup Sets Need RAM Planning

The problem: Rsync must scan both source and destination before starting transfers. With millions of files, this memory requirement is substantial

What happens: rsync dies with “out of memory” on systems with insufficient RAM

Rough estimate: 1 million files needs approximately 500MB RAM for rsync operations

How to avoid:

Security & Compliance: What Nobody Tells You

Backup tools handle sensitive data. Security can’t be an afterthought.

Encryption Requirements

Scenario	Rsync over SSH	Rclone with Crypt	Rclone to S3 with KMS	Considerations
In-transit encryption	✓ (SSH tunnel)	✓ (TLS)	✓ (HTTPS)	All three encrypt data traveling over network
At-rest encryption	✗ (depends on destination)	✓ (client-side AES-256)	✓ (provider-managed)	Rclone offers client-side option
Key management	Manual SSH keys	Passphrase-based	Cloud provider KMS	Trade-off: complexity vs security
Compliance	Data seen by destination admin	Data encrypted before provider sees it	Provider has encryption keys	Client-side may be required for sensitive data

Encryption Implementation

Rsync over SSH (encryption in transit only):

Rclone with Client-Side Encryption (data encrypted before upload):

Rclone to S3 with Cloud Provider Encryption:

Immutable Backup Destinations

Here’s the critical point nobody mentions until ransomware hits: both rsync and rclone can be weaponized by attackers.

If ransomware compromises the system running your backups, it can:

• Delete all backups via rclone/rsync commands
• Corrupt backups by overwriting with encrypted versions
• Disable backup retention policies

Solution: Storage-layer immutability

Modern storage platforms offer immutable snapshots that cannot be deleted or modified even by administrators with full privileges. This storage-layer protection provides your last line of defense:

This architecture aligns with NIST Cybersecurity Framework 2.0 guidance that backup systems must be resilient to compromise.

Building Enterprise Disaster Recovery Architecture

Modern DR requires more than just backup scripts. It demands an integrated architecture with clear RPO/RTO objectives at each tier.

Tiered Recovery Strategy

Tier	Technology Approach	RPO	RTO	Use Case
Tier 1: Instant Recovery	Local immutable snapshots	5-60 minutes	< 1 minute	Corrupted data, accidental deletion, rapid rollback
Tier 2: Geographic Replication	Rsync to remote datacenter	4-24 hours	1-4 hours	Disaster affecting primary site, regional outage
Tier 3: Cloud Archive	Rclone to object storage	24 hours	4-24 hours	Long-term retention, compliance requirements
Tier 4: Orchestrated DR	Disaster recovery automation platform	Continuous	< 15 minutes	Mission-critical apps requiring guaranteed RTO

Architecture Diagram: How These Pieces Work Together

How the tiers work together:

Tier 1 provides instant recovery from immutable local snapshots—when ransomware encrypts files or admins accidentally delete critical data, you restore in seconds without waiting for remote transfers.

Tier 2 protects against site-wide failures through geographic replication. Rsync’s delta efficiency means continuous synchronization doesn’t overwhelm WAN links.

Tier 3 delivers long-term archive and compliance retention in cost-effective cloud storage. Rclone’s parallelism makes initial seeding feasible even for petabyte-scale datasets.

Tier 4 adds orchestration and automation—instead of running scripts manually during disasters, automated recovery platforms ensure consistent, tested recovery procedures.

Best Practices: What Actually Works at Scale

For Rclone Deployments

1. Tune Parallelism Based on Your Infrastructure

2. Always Override Defaults for Production

3. Test With Representative Data Before Production

4. Implement Monitoring and Alerting

For Rsync Deployments

1. Always Test Before Deploying to Production

2. Avoid Performance-Killing Flags

3. Plan Resources for Large File Sets

4. Use Appropriate Flags for WAN/Unreliable Links

Understanding How Storage Impacts Your Results

Your tool choice matters, but your storage architecture determines whether those tools can achieve their design performance.

Storage Performance Characteristics That Matter

For parallel tools like rclone:

• Concurrent operation capacity: Can the storage handle 32/64/128 simultaneous reads or writes?
• Latency under load: Does response time degrade when handling many parallel requests?
• IOPS ceiling: Is there a hard limit where additional parallel operations queue?

For serial tools like rsync:

• Sequential throughput: Maximum sustained read/write speed for large files
• Metadata performance: How quickly can it scan millions of files?
• Network interface: Is the storage network connection the bottleneck?

General Storage Architecture Principles

Traditional NAS/SAN systems often have:

• Higher latency (5-50ms depending on configuration)
• Limited concurrent operation capacity
• Scale-up architecture with single-controller bottlenecks

Modern all-flash storage typically provides:

• Sub-millisecond latency (< 1ms)
• High concurrent operation capacity
• Scale-out architecture supporting parallel workloads

The practical impact:

If your storage has 20ms latency and supports 200 concurrent operations, rclone with –transfers 64 won’t be much faster than –transfers 16 because you’ll hit the storage ceiling.

High-performance storage with sub-millisecond latency and thousands of concurrent operations removes storage as the bottleneck, allowing your sync tools to achieve their maximum designed throughput.

How to Identify If Storage Is Your Bottleneck

Symptoms that storage is limiting sync performance:

• Rclone with high transfer count isn’t significantly faster than low transfer count
• CPU and network utilization are low during sync operations
• Storage system shows high latency or queue depths during operations
• Adding more parallel transfers doesn’t improve overall speed

How to test:

Moving Forward: Implementation Checklist

Before you deploy:

• Map your backup architecture tiers (Tier 1-4)
• Define RPO/RTO requirements for each tier
• Identify which tool fits each tier’s needs
• Assess whether storage performance will limit tool effectiveness
• Plan for immutability and ransomware protection at storage layer
• Set up comprehensive logging, monitoring, and alerting
• Test with representative data (1-10% of production) before full deployment
• Document configuration and operational procedures
• Create disaster recovery runbooks with clear procedures
• Schedule regular DR testing (quarterly recommended)

Architecture decisions checklist:

• Cloud-only backups? → Consider rclone + cloud storage
• On-premises incremental? → Rsync from source to backup server
• Hybrid (fast seeding + efficient incremental)? → Rclone initial + Rsync ongoing
• Need ransomware protection? → Require immutable storage layer
• Mission-critical applications? → Add orchestrated DR platform
• Multi-cloud strategy? → Rclone supports 50+ cloud providers
• Compliance requirements? → Ensure encryption, audit trails, retention policies

Conclusion: Build the Right Architecture

The honest truth: choosing between rclone and rsync isn’t about picking the “better” tool—it’s about building the right architecture for your specific backup and disaster recovery requirements.

Rclone’s parallelism gives you speed when you need to move massive data quickly. Rsync’s delta algorithm gives you efficiency when bandwidth is precious. The most sophisticated backup systems use both tools in complementary roles, optimizing for both RTO and TCO.

But here’s the critical insight: tool selection is only half the equation. Your actual performance depends on:

1. Storage infrastructure supporting the concurrent operations your tools require
2. Network capacity matching your throughput needs
3. Immutable protection ensuring backups survive ransomware attacks
4. Testing and validation confirming recovery procedures actually work

The teams getting backup right aren’t picking the best tool. They’re building the right architecture—with complementary tools, performant storage, immutable protection, and tested procedures.

Making the Decision

Start with your requirements:

• What are your RPO/RTO objectives?
• What’s your data volume and change rate?
• Where does data need to be protected (cloud, remote datacenter, both)?
• What compliance and security requirements must you meet?

Then choose your architecture:

• Use rclone for cloud interactions and bulk data movement
• Use rsync for incremental sync and bandwidth efficiency
• Implement immutable storage to protect backup destinations
• Add orchestration for mission-critical applications

Verify your storage won’t be the bottleneck:

• Test with realistic workloads
• Monitor concurrent operation capacity
• Ensure latency stays low under load
• Plan capacity for growth

The difference between backup systems that work and backup systems that fail isn’t the tool—it’s the architecture, the testing, and the discipline to validate that recovery actually works before you need it.

Learn More About Backup Architecture

Explore related content on building resilient data protection strategies:

• Disaster Recovery Planning: Learn about comprehensive DR approaches beyond file sync
• Storage for Databases: Specialized backup considerations for database workloads
• Understanding Blob vs File Storage: Choose the right storage type for your backup destination

Share Your Experience

Found this guide helpful? Have additional insights or gotchas to share? Connect with the Pure Storage community to discuss backup strategies and tool experiences.

FAQ