data management

Archiving Large Research and Scientific Datasets Across Clouds

Jun 24, 2026

The Shape of Research Data

Research datasets are large, occasionally needed years later, and often spread across storage paid for by different grants or collaborators. Archiving them well means picking durable storage, moving the data without a scripting project, and using transfers that resume when a multi-day run gets interrupted.

Anyone who has managed a lab's data knows the pattern. A dataset lives on a cluster's object store, a copy sits in a collaborator's account, and the grant that funded the original storage is ending. The data has to move, it is enormous, and nobody wants to own the migration.

Choose Storage That Suits an Archive

Active analysis and long-term archive have different needs. For the archive, the priorities are durability and a cost model that fits data you read back rarely:

Object storage such as Backblaze B2, Wasabi, or Cloudflare R2 is built for exactly this: large objects, high durability, S3-compatible so your existing tools work.
Compare on egress and minimum storage duration, not the headline rate. For an archive you touch a few times a year, those terms decide the real cost far more than the storage price.
Keep a second copy. A single archive is one copy. Durable does not mean infallible, and a second location is what the 3-2-1 rule is for.

Moving the Data Without a Scripting Project

The usual options at this scale are command-line tools and custom scripts, which is fine if you have an engineer to spare and a problem when you do not. The bottleneck is rarely the copy itself. It is listing millions of small files, keeping throughput up with parallelism, and resuming cleanly when a run that takes days gets interrupted.

Blober handles those parts from a desktop app. It connects to S3, B2, Wasabi, R2, DigitalOcean Spaces, Azure Blob, and local storage, copies between them directly without staging a full copy on disk, runs transfers in parallel, and has skip-existing so a paused or failed run picks up where it left off instead of starting over. For a dataset larger than any one machine's disk, that combination is the difference between a finished archive and an abandoned one.

Document What You Moved

An archive nobody can navigate is only half useful. As you move data, keep a simple record: what went where, when, and the rough file count, so a future you or a future student can find a dataset without reverse-engineering the folder tree. A short README in the destination bucket pays for itself the first time someone needs the data after you have moved on.

Frequently Asked Questions

Where should I archive large research datasets? Durable object storage such as Backblaze B2, Wasabi, or Cloudflare R2, chosen on egress and minimum storage duration rather than the headline rate, with a second copy in another location.

How do I move a multi-terabyte dataset between clouds? Use a tool that transfers directly, runs in parallel, and resumes. Blober copies between object stores and local storage from a desktop app, with skip-existing so interrupted runs continue rather than restart.

What makes large transfers fail? At scale, listing millions of small files and surviving interruptions are the hard parts, not the copy. Parallelism and resumable, skip-existing transfers are what get a multi-day run to finish.

Is object storage good for research archives? Yes. It is durable, built for large objects, and usually S3-compatible, so existing tools work. Keep a second copy elsewhere to satisfy 3-2-1.

Get Blober

Move multi-terabyte datasets between object stores and local storage without a scripting project. Blober transfers in parallel, preserves structure, and resumes interrupted runs.

Download Blober at blober.io

Cloudflare R2 for AI Training Data: Why Zero Egress Changes the Math

Jun 24, 2026

Why Egress Is the Hidden Tax on Training Data

Training a model means reading the same dataset over and over, once per epoch, often from GPUs that sit outside your storage provider's network. On most object stores you pay an egress fee every time that data leaves the bucket. Cloudflare R2 does not charge egress fees, so reading a dataset a hundred times costs the same in transfer as reading it once. For read-heavy AI work, that quietly changes the math.

People size storage by the price per terabyte and then get surprised by the transfer line on the bill. For an archive you rarely open, egress barely matters. For a training set you stream through a data loader thousands of times, egress is the cost.

What Makes Training Data Different From an Archive

Training data has a few traits that make egress the deciding factor:

It is read many times. Every epoch reads the whole set again. Hyperparameter sweeps and multiple runs multiply that.
It is large. Image, video, audio, and text corpora run to terabytes, and embeddings pile on more.
The compute is often elsewhere. GPUs in another cloud or a rented cluster mean the data crosses a network boundary on every read, which is exactly what egress charges for.

Put those together and a metered-egress store can cost more to read than to hold.

Why R2 Fits the Job

Two properties do the work. First, R2 does not charge egress fees, so repeated reads from outside Cloudflare do not accumulate transfer cost. Second, R2 is S3-compatible, so the data loaders, SDKs, and tools your pipeline already uses point at it by changing the endpoint and the keys. You do not rewrite your training code to adopt it.

A couple of honest caveats, because the math is not free in every direction. R2 has its own operation and request considerations, and throughput depends on how your loader and network are set up. If your training compute lives in the same cloud as your current data, reads inside that cloud may already avoid egress, so R2's advantage is largest when storage and compute would otherwise sit on different networks. Confirm Cloudflare's current terms before you commit a pipeline to them.

Getting a Dataset Into R2

A training corpus rarely starts life in one place. It is scraped to a local disk, staged in an S3 bucket, or scattered across a few accounts from different collaborators. Consolidating it into one R2 bucket is the setup step.

Blober moves data into R2 directly from AWS S3, Backblaze B2, Wasabi, DigitalOcean Spaces, Azure Blob, Dropbox, Google Drive, or local storage. It copies in parallel, keeps the folder structure intact, and has skip-existing, so the first run stages the whole corpus and later runs only carry the new files as the dataset grows. You are not downloading the set to a laptop and pushing it back up, which matters when the corpus is bigger than any one machine's disk.

A Practical Setup

Choose R2 as the dataset home if your training compute reads it repeatedly from outside Cloudflare.
Stage the corpus into an R2 bucket with Blober, in parallel and with structure preserved.
Point your S3-compatible data loader at the R2 endpoint and train.
Re-run Blober with skip-existing as you add data, so only the new files move.

Keep a second copy somewhere else as well. One bucket is one copy, and the 3-2-1 rule applies to a dataset you cannot easily recreate just as much as to family photos.

Frequently Asked Questions

Does Cloudflare R2 charge egress fees? No. R2 does not charge egress fees for reading your data out, which is its main draw for read-heavy workloads like model training. Confirm the current terms on Cloudflare's site before committing.

Is Cloudflare R2 good for machine learning datasets? Yes, especially when your training compute reads the dataset repeatedly from outside Cloudflare's network. Zero egress removes the per-read transfer cost that dominates training storage bills.

Is R2 S3-compatible for data loaders? Yes. R2 exposes an S3-compatible API, so existing S3 data loaders, SDKs, and tools work by changing the endpoint and credentials.

How do I move my training data into R2? Use a tool that transfers directly and in parallel. Blober stages datasets into R2 from S3, B2, Wasabi, Spaces, Azure Blob, and local storage, with skip-existing for incremental updates.

Get Blober

Stage your training data into R2 without a scripting project. Blober moves datasets into R2 from S3, B2, Wasabi, Spaces, Azure Blob, and local storage, in parallel and with structure intact.

Download Blober at blober.io

Consolidating Multiple Cloud Accounts Into One (Without Losing Folder Structure)

Jun 24, 2026

Merging Scattered Cloud Accounts, Done Right

To consolidate files spread across several clouds, pick one destination, then copy each source into its own folder there so nothing collides, keeping the original folder tree intact. The hard part is not the copying. It is doing it without flattening your structure or creating a thousand duplicates.

Most people accumulate clouds by accident: a personal Dropbox, a work Google Drive, an old S3 bucket from a project, a free account that came with a device. Finding one file means remembering which silo it is in. Consolidating fixes that, if you do it carefully.

Decide the Destination First

Before moving anything, choose where everything will live. Match it to how you work:

Google Drive or Dropbox if you mostly open and share documents and want easy collaboration.
A NAS or external drive if you want the files under your own roof and off a subscription.
Object storage like Backblaze B2 or Wasabi if it is mostly a large archive you rarely touch.

Pick one. Splitting the destination defeats the point.

Preserve the Structure, Avoid Collisions

This is where consolidations go wrong. Two sources both have a folder named "Projects," they merge, and now you cannot tell which file came from where. The fix is simple: give each source its own top-level folder in the destination, for example from-dropbox/, from-drive/, from-old-s3/, and copy each source's tree underneath. You keep every original path, and nothing overwrites anything.

Blober preserves folder structure when it copies, so the tree you had in each source lands intact in the destination. Point it at a source, choose the destination folder, and it recreates the hierarchy rather than dumping files into one flat pile.

Watch for the Native-Format Trap

If one of your sources is Google Drive, remember that Google Docs, Sheets, and Slides are not real files. They are pointers to Google's editor, and copying them without exporting leaves you with empty links. Decide how those should come across before you move them, so your consolidated library holds real documents, not dead shortcuts.

Do It Once, Then Verify

Run the moves source by source rather than all at once, so you can check each as it lands. When everything is in place, open a few files from each from-* folder and confirm the counts look right. Once you trust the consolidated copy, you can retire the old accounts on your own schedule.

Frequently Asked Questions

How do I combine files from different cloud accounts? Choose one destination, then copy each source into its own folder there so nothing collides. A tool like Blober copies between accounts directly and keeps the folder structure intact.

Will consolidating clouds create duplicate files? Not if you give each source its own top-level folder in the destination. That keeps same-named folders from merging and overwriting each other.

Does moving files between clouds keep my folder structure? With Blober, yes. It recreates the source's folder tree in the destination rather than flattening everything into one folder.

What happens to Google Docs when I consolidate? Google Docs, Sheets, and Slides are editor links, not files. Export them to a real format as part of the move, or you will copy empty pointers.

Get Blober

Pull files from every cloud you use into one home, with the folder structure intact. Blober connects to a wide and growing range of cloud providers plus local storage and copies between them directly.

Download Blober at blober.io

How Freelancers Keep Client Files Organized Across Clouds

Jun 24, 2026

The Freelancer File Problem

Freelancers end up with files scattered across every client's cloud plus their own, and the fix is a simple routine: work from your own organized storage, archive each project when it closes, and hand off a clean copy. The trick is making the moves between all those clouds painless enough that you actually keep up with them.

If you freelance, you know the mess. One client lives in Dropbox, another shares through Google Drive, a third dropped files in an S3 bucket two years ago. Your own work sits somewhere else again. Finding a single old deliverable means logging into four accounts.

A Workflow That Holds Up

1. Pull each project into your own organized storage. Whether that is a NAS, a drive, or your own cloud, give every client and project a consistent folder. You work from a structure you control, not from whatever each client happened to set up.

2. Archive when a project closes. Finished work does not need to sit in fast, active storage. Move it to a cheaper archive, object storage like Backblaze B2 or a NAS, and keep your working space lean. You still have it if the client comes back a year later.

3. Hand off a clean copy. When a project wraps, deliver a tidy copy into the client's cloud of choice, with the folder structure intact, so the handoff looks professional and nothing is missing.

Where Blober Fits the Routine

Blober is the part that moves files between all these places without the download-and-reupload slog. It connects to every major cloud provider plus local storage, preserves folder structure, and copies directly between accounts. A few ways freelancers use it:

Pull a client's Dropbox or Drive into your own organized archive at the start of a job.
Move a finished project from active storage to a cheaper archive when it closes.
Deliver the final files into the client's cloud, structured the way they expect.

Because it runs on your machine rather than a third-party server, client files are not passing through someone else's relay, which matters when the work is under NDA.

Keep the Originals, Protect the Relationship

One habit that saves freelancers repeatedly: keep your own archived copy of every project even after handoff. Clients lose files, ask for a re-send months later, or come back for a follow-up. An organized archive turns those moments into a two-minute favor instead of a scramble, and that reliability is part of why they rehire you.

Frequently Asked Questions

How should freelancers organize files across multiple clients? Work from your own consistent folder structure rather than each client's setup. Pull projects into your storage, archive them when they close, and keep an organized copy of everything.

How do I move a client's files out of their Dropbox or Drive? With access to the account, Blober copies the files directly into your own storage, keeping the folder structure intact, without downloading and re-uploading.

Where should I archive finished freelance projects? Cheaper, durable storage such as a NAS or object storage like Backblaze B2. Keep active projects in fast storage and move closed ones to the archive.

Is it safe to move client files with a transfer tool? Blober runs on your own machine with your credentials, so files are not routed through a third-party server. That keeps client work out of an external relay.

Get Blober

Keep client work organized across every cloud you touch. Blober moves files directly between the major cloud providers and local storage, preserves folder structure, and runs on your own machine.

Download Blober at blober.io

Server-to-Server vs Download-and-Reupload: Why the Difference Decides Your Transfer

Jun 24, 2026

The Two Ways to Move Files Between Clouds

There are two ways to move files from one cloud to another. The common way downloads every file to your computer and uploads it again to the destination, which leaves a full copy on your disk and makes your machine the slow part. The other way, often called server-to-server or a direct transfer, streams the data between the two services without staging a full copy on your disk, so local disk space stops being the limit.

The difference is invisible for ten files and decisive for ten thousand. Understanding it saves you from a stalled migration halfway through a terabyte.

A Quick Word on "Server-to-Server"

The label is looser than it sounds. A literal server-to-server copy, where the two providers hand the bytes straight to each other and nothing passes through you, only happens in narrow cases: within a single provider, or between two services that specifically support it. What a desktop tool like Blober gives you instead is a streamed copy. The data flows through the app rather than being staged on your disk, so disk space stops being the limit, though the bytes still travel over your own connection. The win is skipping the second full copy, not escaping your network.

Download-and-Reupload, and Where It Breaks

Drag a cloud folder to your desktop and back into another service, or let a sync client mirror it locally, and you are doing a download-and-reupload. It works, and for small jobs it is fine.

It breaks in three ways at scale. First, disk: a 2 TB move needs 2 TB of free space, which most laptops do not have. Second, time: every byte makes two trips through your machine. Third, fragility: a sync client chewing through thousands of files will choke, duplicate, or stall, and you babysit it.

What a Direct Transfer Changes

A direct transfer connects to both services and streams data from the source to the destination without writing a full local copy to disk. The practical wins:

Disk space stops being the limit. You can move far more than your free disk, because the files are not staged there.
It runs in parallel. Many files move at once instead of one slow queue, which is what actually makes a big library finish.
It skips what is already done. If a transfer drops partway, re-running it carries only the files that did not make it, instead of starting the whole job over.

The Honest Caveats

A direct transfer is not magic, and it helps to know the real boundaries. The data still travels over the connection of wherever the tool runs, so your bandwidth is part of the equation. Egress, what a source provider charges to read your data out, still applies regardless of the tool, so plan the move as one clean pass rather than repeated pulls. What you avoid is the second full copy on your disk and the double handling that comes with it.

Where Your Data Goes (and Does Not)

There is a second axis worth separating from disk: who handles your data. Some cloud-to-cloud services route your files through their own servers, which means a third party touches them. Blober is a desktop app, so it runs on your machine with your credentials, and your data is not parked on someone else's server in the middle. You get the direct-transfer benefit without handing your files to a relay.

Frequently Asked Questions

What is a server-to-server transfer? Strictly, it means the two providers move the data between themselves so it never touches your machine, which only works in specific cases. In practice, most "server-to-server" tools stream the data through the tool instead. Blober does this from your own machine: the files are never staged as a full copy on your disk, though they do travel over your connection.

Do I have to download files to move them between clouds? Not with a direct-transfer tool. Blober streams between the source and destination without writing a full copy to your disk, so disk space is not the limit.

Why is my cloud-to-cloud transfer so slow? A download-and-reupload sends every byte through your machine twice and often runs one file at a time. A parallel direct transfer keeps many files moving at once, which is far faster for large libraries.

Does a direct transfer avoid egress fees? No. Egress is charged by the source provider for reading your data out, no matter which tool you use. A direct transfer avoids the wasted second trip and the local copy, not the provider's egress.

Get Blober

Move large libraries between clouds without filling your disk. Blober streams files directly between a broad, growing set of cloud providers and local storage, in parallel, and runs on your machine rather than a third-party server.

Download Blober at blober.io

The 3-2-1 Backup Rule for People Who Live in the Cloud

Jun 24, 2026

What the 3-2-1 Rule Says

Keep 3 copies of anything you care about, on 2 different kinds of media, with 1 copy off-site. It is an old rule from the server world, and it still holds. The twist for cloud-first people is that "it is in Google Photos" or "it is in Dropbox" counts as a single copy, not three.

A cloud account feels like safety because the company runs the servers. It is still one copy in one place, subject to one account that can be locked, billed, closed, or simply forgotten. That is exactly the single point of failure 3-2-1 exists to remove.

Why One Cloud Is Only One Copy

Account lockouts happen. Subscriptions lapse. A provider changes terms or sunsets a service. Sync can faithfully replicate a deletion or a corruption to every device before you notice. In each case, having everything in one cloud means having one copy, and one copy is the thing the rule warns against.

This is not an argument against your cloud. It is an argument for two more copies.

Building the Other Two Copies

You do not need a server rack. A workable 3-2-1 for a normal cloud library looks like this:

Copy 1: the cloud you already use. Google Photos, Drive, Dropbox, iCloud, GoPro Cloud, whatever holds the originals today.
Copy 2: storage you own. A NAS or an external drive. Different kind of media, under your own roof, reachable even if an account is not.
Copy 3: a second, off-site cloud. Object storage like Backblaze B2, Wasabi, or Cloudflare R2, or a second consumer cloud. This is the off-site leg that survives a fire, theft, or a drive failure at home.

Two kinds of media, one of them off-site. That is the whole rule.

Keeping the Copies Current

A backup made once and never updated slowly stops matching reality. The practical habit is to refresh the owned copy and the off-site copy on a schedule that matches how often the originals change: monthly for a photo library, after each shoot for a working archive.

Blober is the piece that moves data between these copies. It connects to a broad set of cloud providers plus local storage and copies between them directly, without staging a full copy on your disk. It has skip-existing, so a re-run only carries what is new rather than recopying everything, which is what makes "refresh the backup" a five-minute job instead of an afternoon.

A Quick Reality Check

Run one test before you trust any of this: open a few files from the owned copy and the off-site copy. A backup you have never opened is a hope. Two copies you have actually checked are a backup.

Frequently Asked Questions

What is the 3-2-1 backup rule? Keep 3 copies of your data, on 2 different types of media, with 1 copy stored off-site. It protects you from any single failure, whether a drive, an account, or a location.

Does cloud storage count as a backup? A single cloud account is one copy, not a backup. It becomes part of a real backup once you add a second copy on owned storage and a third copy off-site.

What is the easiest second copy for a cloud library? A NAS or an external drive. It is a different kind of media than the cloud and stays reachable even if an account is locked.

How do I keep my backup copies up to date? Re-run the copy on a schedule. A tool with skip-existing, like Blober, only moves what changed, so refreshing the owned and off-site copies is quick.

Get Blober

Build a real 3-2-1 backup without a weekend of manual uploads. Blober moves data between your clouds, your NAS, and local drives, and only copies what changed on a re-run.

Download Blober at blober.io

Data Holders: How Blober Fits Your Workflow

Mar 14, 2026

Who Are Data Holders?

Data holders are individuals and organizations that accumulate, manage, and preserve large volumes of digital files as a core part of their work. They aren't just storing files - they're responsible for keeping data accessible, organized, and safe across years and even decades.

Data holders include:

Photographers and videographers with terabytes of RAW footage and project archives
Researchers and academics maintaining datasets, papers, and experimental outputs
Small businesses managing client records, invoices, contracts, and media assets
IT administrators responsible for infrastructure backups and compliance archives
Content creators with libraries of video, audio, and design files across platforms
Legal and medical professionals bound by retention requirements for sensitive records
Personal archivists preserving family photos, home videos, and documents

What unites them is a common problem: data grows, scatters, and becomes harder to manage over time.

The Data Holder's Problem

Most data holders didn't plan to end up with files in five different places. It happens organically:

Files start local - on a laptop, NAS, or external drive
Cloud adoption fragments storage - Google Drive for sharing, Dropbox for syncing, an S3 bucket for backups
Platform lock-in creeps in - GoPro Cloud holds your footage, iCloud holds your photos, OneDrive holds your documents
Manual management breaks down - folder naming conventions drift, backups become inconsistent, some files have three copies while others have none

The result is a scattered, fragile data footprint where no single tool gives you visibility across all your storage.

Symptom	Root Cause
"I know I have that file somewhere"	Files spread across 3-5 providers with no unified view
"My backup is months out of date"	Manual backup processes that require constant attention
"I'm paying for storage I barely use"	Redundant copies in expensive tiers that should be archived
"I can't move my data without paying egress"	Provider lock-in via egress fees and proprietary APIs
"Organizing everything would take weeks"	Flat folder structures with no metadata-driven automation

How Blober Solves This

Blober is a desktop application purpose-built for data holders who need to move, organize, and back up files across cloud providers and local storage - without recurring fees.

1. One Interface for All Your Storage

Blober connects to the storage providers data holders actually use:

Provider	Typical Use Case
AWS S3	Production infrastructure, enterprise backups
Backblaze B2	Affordable long-term archive
Wasabi	Hot storage with no egress fees
Cloudflare R2	CDN-adjacent delivery, zero egress
Google Cloud Storage	Workspace-integrated projects
Azure Blob Storage	Enterprise and compliance workloads
DigitalOcean Spaces	Dev team object storage
GoPro Cloud	Action camera footage (Blober exclusive)
Dropbox	File sharing and synchronization
Local / NAS	On-premise primary storage

No other single tool covers this range - especially GoPro Cloud, which Blober is the only application to support.

2. Direct Cloud-to-Cloud Transfers

Instead of downloading files to your machine and re-uploading them, Blober transfers data directly between providers. This matters for data holders because:

Saves time - a 2 TB migration doesn't bottleneck on your home internet
Saves bandwidth - your ISP data cap stays intact
Reduces failure points - no half-downloaded files sitting on your local disk

3. Metadata-Driven Organization

Data holders accumulate files over years. Manually sorting them into folders is unsustainable. Blober supports path templates that use file metadata to auto-organize during transfer:

/{year}/{month}/{camera_model}/{filename}

A flat dump of 50,000 files becomes a clean archive:

/2025/06/HERO13 Black/GX015742.MP4
/2025/06/Canon EOS R5/IMG_4521.CR3
/2026/01/iPhone 15 Pro/IMG_0032.HEIC

This works for any transfer - cloud-to-cloud, cloud-to-local, or local-to-cloud.

4. Scheduled and Resumable Transfers

Backup workflows for data holders need to be reliable, not heroic. Blober supports:

Resumable transfers - if your connection drops or your machine restarts, pick up where you left off
Incremental syncs - only transfer files that are new or changed since the last run
Large-file handling - multi-part uploads for files in the tens of gigabytes

No babysitting required. Set up a transfer, let it run, and come back to a completed job.

5. One-Time Pricing

Most cloud migration tools charge per-GB or require annual subscriptions with data caps. For data holders who move terabytes regularly, those costs compound:

Tool	Pricing Model	Cost for 10 TB/year
Flexify.io	~$0.03/GiB per migration	~$300+ (plus egress)
MultCloud	$99.98/year for 2.4 TB cap	~$400+ (need multiple renewals)
rclone	Free but manual	$0 (but hours of CLI configuration)
Blober	One-time purchase	One price, unlimited transfers

You buy Blober once. Transfer 1 TB or 100 TB - the price doesn't change.

Real-World Workflows

The Freelance Videographer

Setup: 8 TB of footage across GoPro Cloud, a local NAS, and Google Drive. Delivers finals via Dropbox.

With Blober:

Connects GoPro Cloud and pulls all footage to Backblaze B2 as a cold archive
Moves finished projects from local NAS to Cloudflare R2 for client delivery
Uses path templates to organize by project date and camera model
Runs periodic syncs from Google Drive to B2 to keep a second backup

Result: One tool replaces four manual processes. Total cost: one Blober license.

The Small Business IT Admin

Setup: 500 GB of compliance documents in Azure Blob Storage. Daily operational files in Google Workspace. Regulatory requirement for off-site backup.

With Blober:

Transfers compliance archive from Azure to Backblaze B2 as a secondary backup
Syncs critical Google Drive folders to a local NAS nightly
Uses Blober's incremental sync so only changed files move each day

Result: Meets audit requirements for geographic redundancy without provisioning a second enterprise cloud account.

The Research Lab

Setup: 12 TB of experimental datasets in AWS S3. New data generated weekly. Grants require data preservation for 10 years.

With Blober:

Migrates completed datasets from S3 Standard to Backblaze B2 (80% storage cost reduction)
Keeps active datasets in S3 for compute-adjacent access
Uses metadata templates to organize by experiment ID and date
Resumable transfers handle multi-GB dataset files without corruption

Result: Storage costs drop dramatically while preservation requirements are met.

Why Not Just Use rclone?

rclone is a powerful open-source CLI tool, and many data holders start there. But it has real limitations for ongoing data management:

Capability	rclone	Blober
GUI for browsing files	No (CLI only)	Yes
GoPro Cloud support	No	Yes (exclusive)
Dropbox support	Yes	Yes
Visual transfer progress	Limited	Full progress dashboard
Resumable multi-part uploads	Partial	Built-in
Path template organization	Manual scripting	Visual template builder
Error handling and retry	Config flags	Automatic
Setup time	Hours (config per remote)	Minutes (OAuth flows)

rclone is great for scripted, automated pipelines. Blober is built for data holders who want reliable transfers without writing shell scripts.

Getting Started as a Data Holder

Audit your storage - list every provider and local device where you keep files
Identify your archive tier - choose an affordable destination like Backblaze B2 or Wasabi for long-term storage
Connect everything in Blober - add each provider via OAuth or API key
Set up your first migration - pick a source, pick a destination, configure a path template
Let Blober handle the rest - resumable transfers, incremental syncs, and metadata organization do the heavy lifting

Your Data, Your Infrastructure

Data holders shouldn't need a subscription to manage their own files. Blober runs locally on your machine - your credentials never pass through third-party servers, your transfer bandwidth isn't metered, and your workflow isn't gated by monthly caps.

One license. Unlimited providers. Unlimited data.

Get Blober and take control of your data workflow.

data management

The Shape of Research Data

Choose Storage That Suits an Archive

Moving the Data Without a Scripting Project

Document What You Moved

Frequently Asked Questions

Related Guides

Get Blober

Why Egress Is the Hidden Tax on Training Data

What Makes Training Data Different From an Archive

Why R2 Fits the Job

Getting a Dataset Into R2

A Practical Setup

Frequently Asked Questions

Related Guides

Get Blober

Merging Scattered Cloud Accounts, Done Right

Decide the Destination First

Preserve the Structure, Avoid Collisions

Watch for the Native-Format Trap

Do It Once, Then Verify

Frequently Asked Questions

Related Guides

Get Blober

The Freelancer File Problem

A Workflow That Holds Up

Where Blober Fits the Routine

Keep the Originals, Protect the Relationship

Frequently Asked Questions

Related Guides

Get Blober

The Two Ways to Move Files Between Clouds

A Quick Word on "Server-to-Server"

Download-and-Reupload, and Where It Breaks

What a Direct Transfer Changes

The Honest Caveats

Where Your Data Goes (and Does Not)

Frequently Asked Questions

Related Guides

Get Blober

What the 3-2-1 Rule Says

Why One Cloud Is Only One Copy

Building the Other Two Copies

Keeping the Copies Current

A Quick Reality Check

Frequently Asked Questions

Related Guides

Get Blober

Who Are Data Holders?

The Data Holder's Problem

How Blober Solves This

1. One Interface for All Your Storage

2. Direct Cloud-to-Cloud Transfers

3. Metadata-Driven Organization

4. Scheduled and Resumable Transfers

5. One-Time Pricing

Real-World Workflows

The Freelance Videographer

The Small Business IT Admin

The Research Lab

Why Not Just Use rclone?

Getting Started as a Data Holder

Your Data, Your Infrastructure