Compare / ShardHex vs rclone

ShardHex vs rclone

rclone and ShardHex both touch cloud storage but solve genuinely different problems. This page lays out who each is built for, and when you'd want both in your toolbox.

Quick verdict

rclone is a Swiss Army knife CLI for moving and mounting files between 70+ cloud providers. Think "rsync for the cloud". ShardHex is a purpose-built backup tool that splits a single file into encrypted erasure-coded shards across multiple clouds, surviving the loss of any one provider. They overlap on "tools that talk to clouds" and almost nowhere else.

Side-by-side comparison

Property rclone ShardHex
Primary use Sync, copy, mount cloud storage Multi-cloud erasure-coded backup
Number of providers supported 70+ (effectively any) 12 curated
Splits files across providers No — one file, one destination Yes — Reed-Solomon N-of-K
Survives losing a cloud No — file lives on one cloud Yes — any K of N restore
Encryption Optional via "crypt" remote (AES-256) Always on, AES-256-CTR
Interface CLI (rclone WebUI exists but is minimal) Native desktop GUI
Mount-as-filesystem Yes (FUSE / WinFsp) No
Sync model Continuous, scriptable Snapshot, on-demand
Open source Yes (MIT) No
Platforms Win / Mac / Linux / BSD / Plan 9 Windows (Mac/Linux planned)
Pricing Free Free local; $19.99 one-time Pro
Learning curve Steep — read the docs Click-through GUI

What each tool actually does

rclone

rclone is a command-line tool for managing files on cloud storage. Its design center is "rsync for cloud providers" — you point it at any of 70+ supported backends and it syncs, copies, mounts, lists, deletes, deduplicates, with the same set of commands. Backends include Google Drive, OneDrive, Dropbox, S3 and S3-compatible (every flavor), SFTP, WebDAV, Backblaze B2, Mega, Yandex, plus dozens of more obscure ones.

rclone has an optional "crypt" remote that wraps another remote with AES-256 encryption — files become opaque to the underlying provider. There's also a "union" remote that combines multiple backends into one virtual namespace, and an "alias" remote, and a "compress" remote. They compose, sysadmin-style.

What rclone does not do: split a single file across multiple providers. Each file lives on exactly one backend. If that backend disappears, the file is gone. The "union" remote distributes different files across backends, which is a different problem.

ShardHex

ShardHex takes a single file and splits it into N erasure-coded shards using Reed-Solomon. Each shard is AES-256 encrypted before leaving your device, then uploaded to a different cloud provider. Any K of the N shards can mathematically reconstruct the original.

The point is "single file, distributed risk". When Google bans your account, OneDrive deletes your files, or Dropbox suspends your subscription, ShardHex can rebuild the original from shards on K other providers. This is a different problem than rclone is built to solve.

ShardHex supports 12 providers (vs rclone's 70+) — curated for the redundancy use case. It's a desktop GUI app, not a CLI, optimized for snapshot backups rather than continuous sync.

When rclone is the right answer

  • You want one tool to talk to dozens of different cloud providers from the command line.
  • You're building a sync pipeline (cron jobs, CI scripts, server-side data migration).
  • You want to mount a cloud as a local filesystem.
  • You're moving files between clouds (one-time migration or ongoing sync).
  • You're a sysadmin or developer who lives in a terminal.
  • You need an obscure backend that ShardHex doesn't support (Hidrive, Yandex, Mega in some regions, internet archive, etc.).
  • You're OK with each file living on one cloud and being responsible for cross-cloud redundancy yourself.

When ShardHex is the right answer

  • You specifically want a single file's data distributed across multiple clouds with mathematical redundancy.
  • You've experienced or fear a cloud account ban / data loss event, and want a tool that survives it by design.
  • You want a GUI rather than a CLI.
  • You want encryption that's always on and can't accidentally be skipped via a misconfigured remote.
  • You want self-healing repair — if some shards go missing, ShardHex can regenerate them from the survivors and re-upload.
  • You'd rather not script your own erasure coding on top of rclone (this is possible, but a non-trivial project).

Can you use both? Yes — they don't overlap.

A reasonable combined setup:

  • rclone for active workflows: continuous sync of a working folder to your primary cloud, mounting cloud storage as a virtual drive, scripted migrations between providers.
  • ShardHex for important snapshots: monthly or quarterly backup of irreplaceable files (tax documents, photo archives, recovery keys, family videos), distributed across multiple providers for genuine redundancy.

Some advanced users have asked about using rclone as a transport under ShardHex (so ShardHex could leverage rclone's 70+ provider list). That's not how either tool currently works — ShardHex talks to providers directly via their native APIs — but the architectural separation means there's no conflict if you run both for different purposes.

Honest summary

rclone is a foundational utility for anyone who works with cloud storage seriously — it's mature, fast, supports practically every backend, and has years of refinement behind it. If you only have time to learn one cloud-storage tool and you're comfortable with a CLI, learn rclone.

ShardHex solves one specific problem rclone doesn't: splitting a file's data across multiple clouds with mathematical redundancy. If you have that specific need, ShardHex is purpose-built for it. If you don't, rclone alone is enough.

Related