How to migrate from Linode object storage to Quake AI

Linode Object Storage (Akamai Cloud Computing) and Quake AI both expose an S3-compatible API. rclone copies data directly between the two endpoints with no local staging required.

Service mapping#

Prerequisites#

• A Quake AI account with S3 credentials
• A Linode Object Storage access key and secret (created in the Linode Cloud Manager under Object Storage > Access Keys)
• rclone installed (v1.65+)

Before you start#

Read the migration planning guide for the S3/Swift compatibility matrix.

Linode-specific considerations:

• Transfer pool. Linode Object Storage includes a fixed monthly outbound transfer allowance bundled with each plan; overage is per-GiB. For large migrations, estimate the transfer size against your allowance. Confirm current rates on the Akamai Cloud Computing pricing page.
• Endpoint format. Linode endpoints follow <region>.linodeobjects.com (for example, us-east-1.linodeobjects.com, eu-central-1.linodeobjects.com). Pick the endpoint that matches the region your source bucket lives in.
• Bucket and credential scope. A Linode access key can be scoped to one or more buckets and to read-only or read-write. Make sure the key you use for migration has read access to every prefix you plan to copy.
• CDN. If your Linode bucket has a CDN attached (Akamai or a third-party), this is a Linode-side feature. Front your Quake AI bucket with a CDN (Cloudflare, CloudFront) if you need edge caching. See CloudFront CDN setup.
• TLS object lock and lifecycle policies. Confirm against the S3 feature compatibility matrix before you cut over. Swift's S3 gateway does not implement every S3 lifecycle and policy feature.
• Ceph backend. Linode Object Storage is Ceph-backed (similar shape to DigitalOcean Spaces). Standard S3 operations are compatible between the two.

Configure rclone remotes#

Add both remotes to ~/.config/rclone/rclone.conf:

[linode]
type = s3
provider = Other
access_key_id = YOUR_LINODE_ACCESS_KEY
secret_access_key = YOUR_LINODE_SECRET_KEY
endpoint = us-east-1.linodeobjects.com
acl = private

[quakeai]
type = s3
provider = Ceph
access_key_id = YOUR_RUMBLE_ACCESS_KEY
secret_access_key = YOUR_RUMBLE_SECRET_KEY
endpoint = object.us-east-2.rumble.cloud
acl = private

Replace the Linode endpoint with the regional slug for your bucket. Replace the Quake AI endpoint with the region you provisioned credentials in.

Verify both remotes:

rclone lsd linode:
rclone lsd quakeai:

Create the destination bucket#

rclone mkdir quakeai:my-bucket

Run the migration#

Initial copy#

rclone copy linode:my-source-bucket quakeai:my-bucket \
  --transfers 16 \
  --checkers 32 \
  --s3-chunk-size 64M \
  --progress \
  --log-file migration.log \
  --log-level INFO

Delta syncs#

rclone sync linode:my-source-bucket quakeai:my-bucket \
  --transfers 16 \
  --checkers 32 \
  --progress

Schedule daily until cutover.

Verify the migration#

rclone size linode:my-source-bucket
rclone size quakeai:my-bucket

Check file integrity:

rclone check linode:my-source-bucket quakeai:my-bucket \
  --one-way \
  --log-file check.log

See the validation checklist for the full procedure.

Cut over#

1. Run a final rclone sync.
2. Update your application's S3 endpoint configuration. See update application endpoint.
3. If you used a Linode-side CDN, configure an external CDN (Cloudflare, CloudFront) pointing at your Quake AI bucket.
4. Keep the Linode bucket for 30 days as a rollback target.
5. Delete all Linode buckets and access keys to stop Linode Object Storage billing.

See also#

• Plan your migration: compatibility matrix, validation checklist
• Migration tools comparison: rclone configuration and alternatives
• Update application endpoint: swap SDK config to Quake AI