page:migrate:backblaze b2 s3 bucket:public media library

Migrate Backblaze B2 S3 bucket: Public media library

Move object storage from Backblaze B2 S3 bucket to Ample, one component at a time. Destination verified on Ample: an object written to a published bucket with an immutable Cache-Control header, a mapping row, and the CDN URL serving it publicly. Source procedure: Inventory the bucket with rclone size or the B2 dashboard. Not migrated automatically: B2 file versions, lifecycle rules and application-key restrictions are not migrated. Cutover: Switch the app's S3_* environment to the Ample bucket with a redeploy, verify reads and writes, keep B2 read-only until confirmed. Rollback: keep the source untouched until you confirm; nothing at the source is changed or deleted by this guide.

Workload

• Public media library

Migration Source

• Backblaze B2 S3 bucket

Prerequisites

1. Authorized access to the Backblaze B2 S3 bucket source and its export tooling
2. An inventory of every component in scope and out of scope
3. A validated backup or copy before any cutover
4. An Ample account token with servers:write, buckets:write

Resource Requirements

• S3-compatible object storage

Migration Steps

1. Inventory the source
   List what Backblaze B2 S3 bucket provides beyond the component you are moving. Out of scope here: B2 file versions, lifecycle rules and application-key restrictions are not migrated.

2. Source step 1
   Inventory the bucket with rclone size or the B2 dashboard.

3. Source step 2
   Copy objects with rclone sync from the B2 S3-compatible endpoint to the Ample bucket endpoint using the issued credentials (path-style).

4. Source step 3
   Verify a sample of objects by size and checksum after the copy.

5. Create the destination bucket and copy
   Create the bucket, copy with rclone or the S3 CLI in path-style mode using the issued credentials, then pass the credentials to the app as encrypted S3_* variables.

   ample bucket create --name 

6. Validate before cutover
   Run the app's own checks and, for data, compare counts and checksums; the example checks are the pattern self-tests (/p/public-media-library).

7. Cut over
   Switch the app's S3_* environment to the Ample bucket with a redeploy, verify reads and writes, keep B2 read-only until confirmed.

8. Rollback
   Point DNS or configuration back to the source. The source was never modified; deletion is a separate, user-executed step after validation.

Limitations

• Documentation only: nothing is executed automatically and no execution binding is offered.
• The source-side procedure is documented from Backblaze B2 S3 bucket's standard tooling and was not executed in this catalog's evidence; the destination side was verified with the pattern fixture.
• No full source-product parity is claimed: B2 file versions, lifecycle rules and application-key restrictions are not migrated.

Success Checks

1. Destination app responds on its public URL (/) expecting ample canary express patterns.
2. Public-media-library check from the destination example.
3. Data or object counts and checksums match the source.