Skip to content

Articles

Proton Drive Is Hard to Migrate To or From. Blober Makes It Easy.

Proton Drive Is Hard to Migrate To or From. Blober Makes It Easy. Browser login, no password stored, Google Drive/Dropbox/S3 to Proton in one step.

The Privacy-First Cloud Storage That's Hard to Move Files Into

Section titled "The Privacy-First Cloud Storage That's Hard to Move Files Into"

Proton Drive is one of the most privacy-respecting cloud storage services available. End-to-end PGP encryption. Swiss jurisdiction. Open-source clients. Zero-access architecture, so not even Proton can read your files. Over 100 million accounts trust it. If privacy is your priority, Proton Drive is a strong choice.

But there's a catch: Proton built great sync clients, not transfer tools.

Their official apps sync a folder between your device and Proton Drive. That works perfectly when Proton Drive is your only cloud. The moment you need to move files from Google Drive, from Dropbox, from AWS S3, or to Proton Drive from another provider, you're on your own. Download everything locally, then re-upload. For a few gigabytes, that's fine. For 500 GB of photos across three Google accounts, it's a weekend you don't get back.

Where Proton Drive Is Officially Supported

Section titled "Where Proton Drive Is Officially Supported"

Proton offers native clients on four platforms, plus web access:

PlatformClientSyncFile BrowserBulk Transfer From
Other Clouds
Windows✅ Desktop app✅ Folder sync✅ Via web
macOS✅ Desktop app✅ Folder sync✅ Via web
iOS✅ Mobile app✅ Photo backup✅ In-app
Android✅ Mobile app✅ Photo backup✅ In-app
LinuxNo client✅ Web only
Web✅ Browser

Notice the last column. Across every platform, on every client, there is no built-in way to transfer files from another cloud provider into Proton Drive. The official path is: download to your machine, then let the sync client pick it up. That means you need enough free local storage to hold everything in transit.

And if you're on Linux, there is no desktop client at all. You get the web interface, which works but doesn't support drag-and-drop bulk uploads from other services either.

What The Proton Client Does Well (And What It Doesn't)

Section titled "What The Proton Client Does Well (And What It Doesn't)"

The Proton Drive clients are well-built for their intended purpose, which is sync, not migration:

What they do well:

  • Folder sync between your device and Proton Drive
  • Automatic photo backup on mobile
  • End-to-end encryption handled transparently
  • Proton Docs and Sheets integration

What they're not built for:

  • Moving files between Proton Drive and another cloud
  • Browsing or selecting files from another cloud as part of a transfer
  • Repeatable transfer workflows
  • Linux without a browser

That's the gap Blober fills.

rclone is the canonical open-source tool for cloud storage. It supports 70+ backends and is genuinely excellent at what it does. Its Proton Drive backend works, with a couple of things worth knowing up front:

  • Tier 4 (Experimental). rclone classifies its Proton Drive support as Tier 4, meaning it's community-maintained and flagged as "use with care." Known gaps include unsupported modification times, draft conflicts on retries, and stale caching when other clients touch the same files. The underlying Proton-API-Bridge library notes there are "likely quite a few errors."
  • Password-based auth. To set up rclone with Proton Drive, you provide your Proton email, password, 2FA, and (if applicable) mailbox password through rclone config. These end up in rclone's config file on disk.

If you're already in the rclone ecosystem and these tradeoffs work for you, rclone is a perfectly good fit. Blober is a different style of tool for a different style of user, and the rest of this article is about that.

How Blober Handles Proton Drive Differently

Section titled "How Blober Handles Proton Drive Differently"

Blober takes a different approach to Proton Drive: instead of asking for your credentials in a config file, it asks Proton for them.

When you connect Proton Drive in Blober, a browser window opens to account.proton.me, which is Proton's own login page. You sign in with your email, password, and 2FA exactly as you would in any browser. Your password never touches Blober. It stays inside the isolated browser session, the same way it does when you log in at drive.proton.me.

What Blober Supports With Proton Drive

Section titled "What Blober Supports With Proton Drive"
OperationSupportedDetails
BrowseNavigate your full folder tree
DownloadParallel, resumable downloads
UploadParallel uploads, auto-creates folders
DeleteMoves to Proton Trash (recoverable)
MetadataFilename, size, created/modified dates
Multiple accountsEach account gets its own session. Run transfers in parallel

What Blober Does That Proton's Client Can't

Section titled "What Blober Does That Proton's Client Can't"
  1. Transfer from any supported provider directly to Proton Drive. Google Drive, Dropbox, AWS S3, Azure Blob, Backblaze B2, Cloudflare R2, DigitalOcean Spaces, Wasabi, Rabata, GoPro Cloud, local disk. No intermediate downloads.
  2. Transfer from Proton Drive to any other provider. Moving away from Proton? Moving a subset of files to cold storage on Backblaze? Blober handles it.
  3. Selective file transfer. Browse your source, pick exactly the files you want, transfer only those. Not a full sync of everything.
  4. Saved workflows. Set up "Dropbox to Proton Drive" once, run it whenever you want. The workflow remembers your source path, destination path, filters, and file naming templates.
  5. Works on Linux. Blober runs on Windows, macOS, and Linux. Since Proton doesn't ship a Linux desktop client, Blober is one of the few ways to get a desktop-native Proton Drive experience on Linux without using a browser.
  6. Resumable transfers. If your session expires mid-transfer, Blober prompts you to re-authenticate and picks up where it left off. No files are lost or duplicated.

Here's the situation Blober is built for:

You're on Google Drive or Dropbox. You've decided to move to Proton Drive for privacy. You have 200 GB of documents and photos spread across folders. Today, your options are:

Option A: Manual download and re-upload

  1. Download 200 GB from Google Drive to your local machine (hours, needs free disk space)
  2. Wait for Proton Drive sync client to upload it all (hours more, CPU-intensive due to encryption)
  3. Repeat for Dropbox
  4. Hope nothing failed silently

Option B: Google Takeout + manual upload

  1. Request a Takeout archive (can take days)
  2. Download the archive(s)
  3. Extract, organize, upload to Proton Drive
  4. Storage used: 3× (source cloud + local archive + Proton)

Option C: rclone

  1. Run rclone config to set up your Google/Dropbox and Proton remotes
  2. Provide your Proton credentials when prompted
  3. Run rclone copy gdrive: protondrive: with the flags that fit your scenario
  4. Drive everything from the CLI, including monitoring and restart

Option D: Blober

  1. Sign in to Google Drive (OAuth) or Dropbox (OAuth)
  2. Sign in to Proton Drive (browser login)
  3. Select the files you want
  4. Start the transfer, then come back and re-run the same workflow whenever you need to

Blober vs rclone for Proton Drive: Side by Side

Section titled "Blober vs rclone for Proton Drive: Side by Side"
Bloberrclone
Auth methodBrowser login via Proton's own pageCredentials in rclone config
InterfaceNative desktop GUICLI
Modification timesPreserved from sourceNot preserved
Resume on failureAutomaticManual restart
LinuxNative desktop appCLI
Cross-provider transferBuilt-in (select source and destination)rclone copy source: dest:
Multiple Proton accountsEach one its own sessionSeparate config remotes
Scriptable automationWorkflows, no cronCron-friendly CLI
Mount as filesystemNot supportedSupported (FUSE)

Blober is a good fit if:

  • You're migrating into Proton Drive from Google Drive, Dropbox, or another cloud
  • You're moving out of Proton Drive to another provider, or shifting a subset to cold storage
  • You're on Linux and want a desktop-native way to manage Proton Drive files
  • You'd rather log in through a browser than configure credentials in a file
  • You want a repeatable, named workflow you can re-run later

rclone is a good fit if:

  • You're already in the rclone ecosystem and want one tool for everything
  • You need scriptable, cron-based automation
  • You want to mount Proton Drive as a filesystem (FUSE)
  • You prefer CLI control over a GUI

Proton Drive is a genuine privacy-first storage service. End-to-end PGP. Zero-knowledge architecture. Open clients. The trade-off Proton makes for that privacy is that getting files in or out, at scale, isn't a first-class experience.

That's where Blober comes in. You sign in to Proton Drive through Proton's own login page, pick the cloud you're moving from or to (Google Drive, Dropbox, S3, Backblaze B2, R2, Wasabi, GoPro, NAS, or local disk), choose what you want to move, and let it run. No config files, no CLI, no separate sync clients to install. The same workflow runs on Linux, macOS, and Windows.

If you have files in other clouds and you want them in Proton Drive, or files in Proton Drive you want elsewhere: that's what Blober is for.

Rabata.io: Where It Fits and Where It Doesn't

Rabata.io: Where It Fits and Where It Doesn't - benchmarks, pricing, and comparison with AWS, Backblaze, R2, Wasabi, iDrive

Rabata.io is an S3-compatible object storage provider from RCS Technologies (UK) with two products: Hot Storage, general-purpose object storage at $0.01/GB/month in us-east-1, designed for applications, media, and frequently accessed data, and Backup, bulk archival storage at $49/10TB flat in eu-west-2, intended for backups, disaster recovery, and cold data. Both use standard AWS SigV4 authentication, work with any S3 SDK or CLI, and require no code changes to migrate from AWS S3. You swap the endpoint and credentials.

That is the entire product. No compute layer, no managed databases, no dashboard file browser: you cannot preview or view objects through Rabata's web UI, so you need an S3 client or a tool like Blober to actually see what's in your buckets. Just storage with an S3 API.

Rabata published benchmarks using MinIO warp v1.0.7 (released January 2025, now superseded by v1.5.0) on a Debian 13 VM in us-east-1 with 8 concurrent threads in September 2025. The methodology is public.

According to their numbers, Rabata wins upload speed by a small margin (1,462 MB/s vs AWS's 1,444) and mixed operations by 2.3x over AWS. It loses on downloads to both Backblaze (2,075 MB/s) and AWS (1,816), and loses small object throughput to iDrive e2 (962 ops/s vs 696).

The mixed operations number is the most relevant for production workloads. Real applications read, write, list, stat, and delete concurrently. Rabata scored 2.3x higher than AWS S3 in that test.

These are same-region tests (us-east-1 to us-east-1). Performance from other geographies is unknown, and Rabata only operates in two regions. The runs are 30 seconds to 10 minutes with 8 threads, so they measure burst, not sustained multi-TB daily throughput over months. The warp version used (v1.0.7, January 2025) was already 8 months old at the time of testing and is now over a year outdated, and newer versions may produce different results. AWS S3 publishes 99.999999999% durability. Rabata publishes no durability SLA, and their terms include a broad "as is" disclaimer with zero liability for data loss.

Rabata fits a specific profile:

Write-heavy S3 workloads that need to stay cheap. If you're ingesting backup pipelines, media uploads, log aggregation, or AI training data, and your bottleneck is upload throughput plus cost, Rabata's upload speed at $0.01/GB is competitive, roughly 57% less than AWS's $0.023/GB first-tier pricing (AWS discounts at volume).

The Backup tier at $49/10TB ($0.0048/GB) is priced below Backblaze B2 ($6.95/TB, ~$0.007/GB) and Wasabi ($6.99/TB, ~$0.007/GB, increasing to $7.99/TB in July 2026). Wasabi enforces a 90-day minimum retention. Rabata's Backup tier has no documented minimum retention, but note: egress is capped at 2x your storage amount and billing is in 10TB increments rounded up: store 1TB and you pay for 10TB.

GDPR-compliant EU storage. The eu-west-2 Backup tier gives you EU data residency, which Rabata calls out explicitly. Worth noting: Rabata's parent company (RCS Technologies) operates under UK law, not EU law. Hetzner also offers EU-based S3-compatible storage with three EU regions (NBG1, FSN1, HEL1) versus Rabata's single EU region. For European companies that need S3-compatible storage with data residency guarantees, both are worth evaluating.

No-friction evaluation. 30-day trial, no credit card required per Rabata's signup page.

  • Download-heavy workloads. If you're serving content to users, Backblaze B2 (2,075 MB/s downloads, ~$0.007/GB) or Cloudflare R2 ($0.015/GB storage, zero egress, weak throughput but free delivery) are better choices depending on whether you're optimizing for speed or cost.
  • Global distribution. Two regions. If you need worldwide low-latency access, this is not the product.
  • Enterprise compliance requirements. No published durability SLA, no SOC 2 mention, limited public track record, benchmarks not independently verified.
  • Ecosystem depth. No lifecycle policies, no event notifications, no cross-region replication, no versioning (or at least none documented), no dashboard file browser. AWS S3 has all of these. Rabata does not.

Based on Rabata's own benchmarks (no independent verification available), they offer three things at once that no other single provider does:

  1. Fastest mixed workload performance in their published benchmarks
  2. Simple pricing at $0.01/GB with $0.01/GB egress (Backup tier: egress capped at 2x storage)
  3. No-barrier trial with no credit card required

AWS is faster on downloads but 2-3x more expensive. Backblaze is comparable on storage (~$0.007/GB) but slower on uploads. Cloudflare R2 has zero egress but performs 3-8x worse. Wasabi has no egress fees but enforces 90-day minimums. iDrive wins on small objects but falls behind on mixed workloads.

If your workload is "ingest data via S3 API, store it cheaply, occasionally read it back," Rabata is worth testing. If your workload needs more features, more regions, or a long track record, look elsewhere.

Blober supports Rabata.io as a native provider. Connect with your access key and secret key, and Blober detects your buckets across both regions (Hot Storage and Backup). You can use Rabata as a source or destination in any workflow: migrate to it from AWS S3, sync from Dropbox, back up from Google Drive, or download files from Rabata to your local machine. Since Rabata's dashboard has no built-in file browser, Blober is one of the easiest ways to actually see and manage what's in your buckets.

What Blober supports with Rabata:

  • Browse: list buckets and objects across both regions (something Rabata's own dashboard doesn't offer)
  • Upload: write files to Hot Storage or Backup buckets
  • Download: pull files from Rabata to local storage or stream to another provider
  • Copy/Move: transfer objects between buckets
  • Delete: remove objects

Blober handles the region routing automatically. If a bucket lives in eu-west-2, operations go through the eu-west-2 endpoint. No manual configuration needed.

For setup details, see the Rabata.io provider documentation.

How to Bulk Change Azure Blob Storage Access Tiers (Hot, Cool, Cold, Archive)

Change Azure Blob Storage tiers without code using Blober mutations

Azure Storage Tiers and the Problem with Managing Them

Section titled "Azure Storage Tiers and the Problem with Managing Them"

Azure Blob Storage offers four generally available access tiers for block blob data: Hot, Cool, Cold, and Archive. Each tier has different storage and retrieval costs. The idea is straightforward: keep frequently accessed data on Hot, move older data to Cool or Cold, and archive rarely needed files to Archive for the lowest per-GB rate[1].

In practice, managing tiers is not that simple. The Azure portal is fine for occasional manual changes, but repeatable bulk work usually means PowerShell, Azure CLI, direct API calls, or lifecycle management policies. If you want to move 500 blobs from Hot to Archive right now, you are either doing manual portal work or writing and testing a script.

Lifecycle policies help with automated transitions, but they operate on rules and schedules. They are not designed for the case where you look at a set of files and decide, right now, that these specific blobs need to be on a different tier.

Hot, Cool, Cold, and Archive: The Tiers at a Glance

Section titled "Hot, Cool, Cold, and Archive: The Tiers at a Glance"

Azure Blob Storage has four access tiers. The colder the tier, the less you pay to store data and the more you pay, in both money and time, to read it back. Here is the practical comparison.

TierStorage costRead costMinimum retentionTime to first byteBest for
HotHighestLowestNoneMillisecondsData in active use
CoolLowerHigher30 daysMillisecondsBackups, data read about monthly
ColdLower stillHigher still90 daysMillisecondsRarely touched data you still want instantly
ArchiveLowestHighest180 daysHours (rehydration)Long-term archive and compliance copies

Two things catch people out:

  • Archive is offline. You cannot read an archived blob directly. You first rehydrate it to Hot, Cool, or Cold, which can take up to 15 hours. Plan for that latency before you archive anything you might need quickly.
  • Early deletion penalty. If you delete, overwrite, or move a blob out of Cool (30 days), Cold (90 days), or Archive (180 days) before its minimum retention elapses, Azure charges a prorated early deletion fee. Moving a blob to Archive and pulling it back two weeks later is not free.

Moving an online blob to another online tier, or down to Archive, is an immediate tier operation. Only the reverse, rehydrating from Archive to an online tier, is a pending restore workflow that can take hours[2].

Blober is a desktop app that connects to Azure Blob Storage as one of its supported providers. Beyond the usual read, write, list, and delete operations, Blober supports something called mutations for Azure Blob. Mutations let you change properties of existing blobs without transferring any data.

Today, Blober supports two types of Azure mutations:

Select any number of blobs in the Blober file browser, choose a target tier (Hot, Cool, Cold, or Archive), and run the mutation. Every selected blob gets moved to the new tier. No re-upload, no script, no waiting for a lifecycle policy to kick in.

This is useful when you realize a project is finished and its assets should move to Archive, or when you need to bring archived files back to Cool for a review cycle.

Azure containers can be set to Private, Blob-level public access, or Container-level public access. Changing access levels usually means navigating to each container in the portal and updating the setting. With Blober, you select the containers you want to modify, pick the access level, and apply.

A Real Example: Post-Production Archival

Section titled "A Real Example: Post-Production Archival"

Say you run a media production company. You have a container called project-alpine-2025 with 800 GB of raw footage sitting on Hot storage. The project wrapped three months ago and no one is accessing those files. You are paying Hot rates for storage that should be on Archive.

With Azure CLI, you would write something like:

az storage blob list --container-name project-alpine-2025 --output tsv | \
while read line; do
az storage blob set-tier --container-name project-alpine-2025 --name "$line" --tier Archive
done

This works, but you need to set up authentication, handle pagination for large containers, deal with blobs that are already archived, and test the script before running it on production data.

With Blober, you open your Azure Blob connection, navigate to the container, select all files, choose "Archive" as the target tier, and click run. Done.

Tier changes and access levels are the first mutations Blober supports for Azure. The architecture is designed to extend this to other providers and other types of modifications. Future mutations could include things like metadata updates, blob tagging, or replication settings. The goal is to give you the same visual, point-and-click control over blob properties that you already have for transfers.

Setting Up Azure Blob Storage in Blober

Section titled "Setting Up Azure Blob Storage in Blober"

Connecting Azure to Blober takes about a minute:

  1. Open Blober and add a new provider
  2. Select Azure Blob Storage
  3. Paste your connection string (the same one you would use with Azure Storage Explorer or the SDK)
  4. Blober verifies the connection and lists your containers

From there, you can browse blobs, transfer files to or from Azure, and run mutations on existing blobs.

When using Azure as a destination, Blober lets you configure:

  • Storage Tier: Choose which tier new uploads land on (Hot, Cool, Cold, or Archive)
  • Write Behavior: Overwrite existing blobs, skip if a blob already exists, or skip only if the blob is archived

These options are set per-workflow, so you can have one workflow that uploads to Hot and another that uploads directly to Archive.

  • DevOps teams managing storage costs across multiple containers and projects
  • Media companies archiving completed project assets
  • Backup administrators moving cold data to cheaper tiers
  • Anyone who has outgrown Azure Portal's one-blob-at-a-time tier management

Common Questions About Azure Blob Tiers

Section titled "Common Questions About Azure Blob Tiers"

Does changing a blob's access tier create a new version? No. Changing the tier with the Set Blob Tier operation does not create a new blob version. When versioning is enabled, the operations that create a version are writes: Put Blob, Put Block List, Copy Blob, and Set Blob Metadata. Set Blob Tier is not one of them; Azure documents tiering as an access-tier operation that can be applied to a blob version[3][4]. If you already keep multiple versions, each version holds its own tier, and explicitly tiering a version changes how that version is billed, but no new version is generated.

Is this different from changing an Amazon S3 storage class? Yes. Azure has a Set Blob Tier operation for changing a blob or version's tier. In S3, an immediate manual storage-class change is copy-based: AWS documents changing an existing object's storage class with a copy to the same object URI, and CopyObject returns the version ID of the newly created copy when versioning is enabled[5]. S3 Lifecycle transitions are different: they transition the current or noncurrent object version selected by the rule rather than creating a new current version[6]. See Azure Blob Tiers vs AWS S3 Storage Classes for the full comparison.

Can I set the tier per file share or only per storage account? That question is about Azure Files, which is separate from Azure Blob Storage. For Azure Blob, the tier is a property of each blob, so you set it per blob, and Blober changes many at once. For Azure Files, pay-as-you-go classic file shares have access tiers such as transaction optimized, hot, and cool, while the SSD/HDD media tier is a file-share planning choice. Microsoft documents that after you create a file share in a storage account, you cannot directly move it to a different media tier; to move from HDD to SSD, for example, you create a new share and copy the data[7]. Blober's bulk tier change applies to Azure Blob blobs.

How long does a tier change take? Moving from a warmer tier to a cooler one, such as Hot to Cool or Cool to Archive, is instantaneous. Bringing a blob back from Archive to an online tier is a rehydration that can take up to 15 hours, depending on the priority you choose.

Can I move blobs to Archive in bulk without PowerShell? Yes. Select the blobs in Blober, choose Archive as the target tier, and run the mutation. No script, no lifecycle policy, no Azure CLI. The same works in reverse to rehydrate selected blobs to Hot, Cool, or Cold.

Will changing tiers re-upload my data? No. A tier change is a service-side access-tier operation on the blob. Nothing is downloaded or re-uploaded by Blober, so there is no tool-side data transfer for the change itself. Azure still bills the Set Blob Tier request as a write operation for tier-down and a read operation for tier-up[8].

Blober is a one-time purchase. No subscriptions. No transfer fees. No transfer limits.

Download Blober at blober.io

How to Cancel GoPro Plus Without Losing Your Footage

Cancel GoPro Plus without losing your footage by downloading everything with Blober

GoPro Plus (now sold as GoPro Premium) costs $59.99/year. It gives you unlimited cloud storage for your GoPro footage, camera replacement coverage, and discounts on accessories. For active GoPro users, that's a reasonable deal.

The problem shows up when you want to leave.

GoPro Plus auto-uploads your footage to GoPro Cloud. Over time, you might have hundreds of gigabytes sitting there. When you cancel, you lose access to those files. GoPro does not give you a bulk export tool, there's no API, and the web interface lets you download at most 25 files at a time in zip bundles.

If you have 500 videos from two years of travel, surfing, or family events, downloading them 25 at a time is not practical. And the zip downloads often fail on larger batches.

When your GoPro Plus subscription ends:

  • You can no longer view or access your cloud footage
  • Your files remain on GoPro's servers for a limited time (the exact retention policy is not published)
  • No third-party tool has API access to help you
  • You lose camera replacement coverage and store discounts

The footage does not transfer anywhere. It sits in GoPro's cloud until they delete it. If you did not download it before cancelling, it may be gone.

How to Save Everything Before Cancelling

Section titled "How to Save Everything Before Cancelling"

Blober is the only desktop app that connects to GoPro Cloud. It was built specifically because no other tool can access GoPro's proprietary storage system.

Step 1: Download Blober and Connect GoPro Cloud

Section titled "Step 1: Download Blober and Connect GoPro Cloud"

Install Blober on your Mac, Windows, or Linux computer. Add GoPro Cloud as a provider and sign in with your GoPro account. Blober captures your session and gives you a visual file browser showing your entire cloud library.

Step 2: Choose Where to Save Your Footage

Section titled "Step 2: Choose Where to Save Your Footage"

You have several options:

Local hard drive or SSD The simplest option. Select all your GoPro Cloud files, pick a local folder as the destination, and transfer. Your footage downloads to your computer at full quality.

External drive or NAS If your internal drive does not have enough space, point Blober to an external drive, SD card, or network-attached storage (Synology, QNAP, etc.).

Backblaze B2 (cheapest cloud option) If you want your footage in the cloud but do not want to pay $59.99/year, Backblaze B2 stores data at $6.95/TB/month. For 1 TB of GoPro footage, that is about $83/year with no subscription lock-in, no download limits, and full API access.

Dropbox, Google Drive, or AWS S3 If you already use another cloud provider, Blober can transfer your GoPro footage directly there. No double-download needed.

Select your files (or select all), choose the destination, and click run. Blober transfers with parallel streams, auto-resume on failure, and progress tracking. For large libraries, you can leave it running overnight.

Once your footage is safely stored elsewhere, cancel your subscription through the GoPro app or website. Your files are yours, on storage you control.

Cost Comparison: GoPro Plus vs Alternatives

Section titled "Cost Comparison: GoPro Plus vs Alternatives"
Storage OptionCost (1 TB/year)Download LimitsAPI Access
GoPro Plus$59.99/year25 files at a timeNone
Backblaze B2~$83/yearUnlimitedS3-compatible
Wasabi~$84/yearUnlimitedS3-compatible
Local hard driveOne-time ~$40 (4TB HDD)N/AN/A
Google Drive (2TB)$100/yearUnlimitedYes

GoPro Plus is actually the cheapest cloud option per TB, but it comes with restrictions that the others do not have: no bulk downloads, no third-party tool access, and your footage is inaccessible the moment you cancel.

This is not a case of "just use rclone" or "try MultCloud." GoPro Cloud is a proprietary system with no published API. No transfer tool, CLI, or cloud sync service has ever supported it.

  • rclone: No GoPro backend. Never had one.
  • MultCloud: Does not list GoPro Cloud as a provider.
  • Flexify: No GoPro support.
  • CloudHQ, Mover, Movebot: None support GoPro Cloud.

Blober connects to GoPro Cloud through the same authentication path as GoPro's own web app. It is the only third-party tool that can read, download, and transfer your GoPro Cloud files.

What If You Want to Keep GoPro Cloud?

Section titled "What If You Want to Keep GoPro Cloud?"

Not everyone needs to cancel. If you shoot regularly and use GoPro's highlight tools, Plus is a solid deal. But even if you keep your subscription, having a backup somewhere else is just good practice.

Use Blober to mirror your GoPro Cloud to a local drive or Backblaze B2 as a safety net. That way, if GoPro changes their terms, raises prices, or has a service issue, your footage is protected.

Blober is a one-time purchase with a lifetime license. No subscription, no per-GB fees.

Download Blober at blober.io

How to Migrate from DigitalOcean Spaces to AWS S3

Migrate from DigitalOcean Spaces to AWS S3 with Blober

Growing Out of DigitalOcean Spaces

Section titled "Growing Out of DigitalOcean Spaces"

DigitalOcean Spaces is a good starting point for object storage. It is simple, affordable ($5/month for 250 GB + 1 TB transfer), and S3-compatible. For small to mid-size projects, it does the job.

But as your storage needs grow, you run into limitations:

  • Region constraints. Spaces are region-scoped. Each region only sees its own Spaces. Cross-region replication is not available.
  • No storage tiers. Everything is stored at the same tier. There is no equivalent to S3's Glacier or Intelligent-Tiering for cost optimization.
  • Limited ecosystem. AWS S3 integrates with hundreds of services: Lambda, CloudFront, Athena, Step Functions, SageMaker. DigitalOcean's ecosystem is smaller.
  • Bandwidth limits. The included 1 TB transfer can be burned through quickly on busy applications.

When a project outgrows Spaces, AWS S3 is the most common destination.

DigitalOcean runs Spaces across 7 regions: NYC3, SFO3, AMS3, SGP1, FRA1, SYD1, and BLR1. If you have Spaces in multiple regions, you need to handle each region separately.

Blober detects all your Spaces across all DigitalOcean regions automatically. When you connect your DigitalOcean account, Blober probes all 7 regions in parallel and presents a unified view of all your Spaces. You do not need to configure each region separately.

DigitalOcean recently introduced cold storage tiers for Spaces. Blober detects whether a Space is using Standard or Cold storage and flags it accordingly. This helps you make informed decisions about which S3 storage class to target.

Step 1: Connect DigitalOcean Spaces

Section titled "Step 1: Connect DigitalOcean Spaces"

Add DigitalOcean Spaces as a provider in Blober. You can use either:

  • S3-compatible credentials (Access Key + Secret Key) for basic access
  • Personal Access Token for richer bucket listing with project metadata

Blober discovers all your Spaces across all regions.

Add AWS S3 with your Access Key ID, Secret Access Key, and preferred region. Blober lists your S3 buckets.

Create a workflow with DigitalOcean as the source and S3 as the destination. Browse your Spaces, select files or entire Spaces, and choose the target S3 bucket and storage class.

Options for the destination:

  • Storage class: Standard, Intelligent-Tiering, Standard-IA, Glacier Instant Retrieval, Glacier, or Deep Archive
  • Target bucket: Any existing S3 bucket (or create one in the AWS console first)

Blober handles the transfer with parallel multipart uploads on both sides. S3-to-S3-compatible transfers are efficient because both services speak the same protocol.

DigitalOcean SpacesAWS S3 StandardAWS S3 Standard-IA
Storage (1 TB)$5/mo (250 GB included) + $20/mo extra$23/mo$12.50/mo
Bandwidth (1 TB)Included$90/mo$90/mo
PUT requests (100K)$0.50$0.50$1.00

DigitalOcean is cheaper for simple, low-traffic use cases. S3 is more cost-effective at scale with its tiering options, especially if you use Intelligent-Tiering or Glacier for archival data.

One-time purchase. Transfer as much as you need.

Download Blober at blober.io