From FTP/SFTP to Cloudflare R2: A Smarter Way to Move Files to Object Storage

Method 2: Transfer Files from FTP/SFTP to Cloudflare R2 with Rclone

If your team is comfortable living in a terminal, rclone is one of the most practical ways to move data from a classic FTP/SFTP server into modern object storage. The key idea is simple: rclone treats each endpoint as a “remote” and lets you copy between them directly, without turning the browser into your upload tool.

First, install rclone on a machine with stable connectivity, then run rclone config to create two remotes: one for your FTP/SFTP server and one for Cloudflare R2. If you’re working with R2 specifically, Cloudflare notes you should use rclone v1.59 or newer for best S3 compatibility. (Cloudflare R2 rclone guide)

• FTP or SFTP remote: Choose ftp or sftp during setup and enter your host, port, and authentication details. FTP is typically username/password, while SFTP commonly uses SSH credentials (password or key-based auth). The official backend pages are handy if you want the exact prompt meanings: rclone FTP docs and rclone SFTP docs.
• Cloudflare R2 remote: In rclone, R2 is configured through the S3 backend. In the wizard you typically select s3 (Amazon S3 compatible), then pick Cloudflare R2 as the provider and enter an R2 Access Key ID / Secret. Cloudflare’s example config also uses an endpoint in the format https://<accountid>.r2.cloudflarestorage.com. (Cloudflare R2 endpoint example) If you’re using object-scoped tokens, Cloudflare mentions you may need no_check_bucket = true to avoid bucket check errors. (Cloudflare notes on object-level permissions)

Once both remotes exist, the transfer is just a command. In most migrations, copy is the “safer” default because it uploads what’s missing or changed, but it won’t delete anything in the destination. Cloudflare’s R2 example even highlights rclone copy for moving objects in and out of buckets. (R2 + rclone copy example)

Example: copy a folder from SFTP into an R2 bucket prefix:

rclone copy sftp:/data/projects r2:my-bucket/projects --progress

If your goal is a strict mirror (destination becomes “exactly like” the source), then sync is the right tool — but it can delete destination files that no longer exist at the source. Rclone’s own sync docs explicitly warn: if you don’t want deletions, use copy instead. (rclone sync docs)

Example: mirror an FTP export directory into R2 (and filter out logs):

rclone sync ftp:/exports r2:my-bucket/exports --progress --exclude "*.log"

Before you run anything large, use --dry-run to preview what rclone would upload and (for sync) what it would remove. It’s a quick way to catch path mistakes, filters that are too broad, or a destination prefix that doesn’t match your expected layout.

Rclone is excellent when you want repeatable transfers you can script, schedule, and tune (filters, retries, rate limits, etc.). The trade-off is that you’re managing credentials and command execution yourself, and long runs are still tied to the machine you execute them on. For teams that don’t want to babysit a terminal session—or need transfers to keep running even if a laptop sleeps—cloud-based transfer options can be a better operational fit.

Method 3: Cloud-to-Cloud Transfer from FTP/SFTP to Cloudflare R2 with CloudsLinker

Sign in to app.cloudslinker.com and open your dashboard. Click Add Cloud, then choose FTP or SFTP from the supported list.

Enter your server endpoint (host/IP). The endpoint must be reachable from the public internet — if it only exists inside a private network, CloudsLinker’s cloud workers won’t be able to connect. Then fill in the port (SFTP typically uses 22 by default), along with your username and password.

If your account is intentionally scoped (or you want extra safety), set the Access Path to the specific folder you want to migrate. It’s a simple way to keep the task focused and avoid accidentally pulling data outside the intended directory tree.

Next, add Cloudflare R2 as the destination cloud. R2 is accessed through S3-compatible credentials, so you’ll need three pieces of information from your Cloudflare account: Access Key ID, Secret Access Key, and the R2 endpoint.

In CloudsLinker, paste the Access Key ID and Secret Access Key into the credential fields, then enter your R2 endpoint (the interactive S3 endpoint Cloudflare provides for your account). After authorization, select the target bucket where the data should land.

If you maintain multiple buckets (for example: backups, media, exports), choosing the bucket up front keeps the migration clean and avoids the “everything went into the wrong place” problem that shows up later in production.

Open the Transfer page. On the left, select your connected FTP/SFTP source and browse to the folders you want to move. On the right, select Cloudflare R2, choose the destination bucket, and set the target folder (prefix) inside that bucket.

This is the moment where it helps to think “object storage” instead of “file server.” FTP/SFTP directories usually reflect operational history—dates, batch runs, system modules, partner drops. In R2, you can map those same folders into clearer prefixes that match how the data will be used later (by application, environment, customer, or pipeline stage).

Start the transfer and monitor it from the task panel. CloudsLinker shows status updates, transferred file counts, and error details if anything fails mid-way. You can pause and resume when needed—useful when you want to adjust filters, re-scope a path, or reduce load on the source server.

When the task completes, you’ll get a summary of what succeeded and what was skipped or retried. Your data will be available inside your Cloudflare R2 bucket, ready for use in storage, delivery, or downstream processing workflows.

If you’re moving a large dataset—or you simply don’t want a desktop upload to be the weakest link—this approach removes the usual friction: no local downloads, no fragile long-running terminal sessions, and no keeping a workstation awake for hours. Everything runs online through CloudsLinker.