# Object Storage FAQ

Source: https://docs.quake.ai/docs/object/faq
Markdown: https://docs.quake.ai/docs/object/faq.md
> Frequently asked questions about Quake AI Object Storage: buckets, S3 compatibility, access control policies, versioning, encryption, CORS, FTP/SFTP, mounting, and migration from AWS S3, GCS, Azure, Backblaze, Wasabi, Hetzner, and DigitalOcean.

---

{/*
--- FAQ: Object Storage service ---
Confidence tiers:

  T1  High-confidence: direct restatement of canonical content.
  T2  Medium-confidence: synthesized across multiple pages.
  T3  Validation-needed: pricing, quotas, regions, SLA, support.

Every question carries a "Source:" line linking to canonical docs.
*/}

# Object storage FAQ

Frequently asked questions about Quake AI Object Storage. For core concepts, see the [Object Storage overview](/docs/object) and [concepts page](/docs/object/concepts/object-storage). For step-by-step instructions, see the [how-to guides](/docs/object/how-to). For moving data from another provider, see the [migration guides](/docs/object/migration).

---

## Getting started





### Q: What is Quake AI Object Storage, and what is it backed by? [T1]


Quake AI Object Storage provides S3-compatible storage for unstructured data: files, backups, media, archives, data lakes, and static assets. It is backed by [OpenStack Swift](https://docs.openstack.org/swift/latest/) with a [Ceph](https://ceph.io/en/) storage backend. The platform exposes both the native Swift API and an S3-compatible API. Data is replicated across multiple storage nodes automatically; you do not manage RAID arrays or backup jobs for durability.

Each dedicated vCPU subscription does not include a bundled object-storage allotment on the current named packs. Object storage is a per-TB add-on. See [Resource tiers](/docs/account/resource-tiers) and the [pricing reference](/docs/account/billing/pricing).

---





### Q: What is a bucket, and how does it differ from a "container"? [T1]


They are the same thing. In OpenStack Swift terminology, the top-level namespace for objects is called a **container**. Quake AI uses **bucket** as the primary user-facing term, matching the S3 vocabulary your tools already expect. If you see "container" in API responses, CLI output, or Swift documentation, it refers to the same concept. Neither term means a Docker container.

---





### Q: What S3 tools and SDKs work with Quake AI? [T1]


Any S3-compatible client works once you point it at the Quake AI endpoint and supply an S3 credential pair. Confirmed working tools:

- **AWS CLI**: pass `--endpoint-url https://object.<region>.rumble.cloud` on every command; set the region to `us-east-1` for SigV4 signing regardless of your Quake AI region.
- **s3cmd**: configure `host_base` and `host_bucket` in `~/.s3cfg`; a pre-filled `.cfg` file is available when you create credentials in the console.
- **rclone**: configure a remote with `type = s3`, `provider = Ceph`, and your region endpoint.
- **MinIO Client (`mc`)**: `mc alias set rumble https://object.<region>.rumble.cloud ...`
- **boto3 (Python)**: pass `endpoint_url` to `boto3.client("s3", ...)`.
- **restic**: use the S3 backend pointed at the Quake AI endpoint.

S3 credentials (access key + secret key) are separate from OpenStack application credentials. Generate them via **API > S3 Credentials** in the console or with `openstack ec2 credentials create`.

---





### Q: What is the S3-compatible endpoint hostname? [T1]


The S3-compatible endpoint hostname uses the `object.` prefix in each region:

| Region | S3 endpoint |
|---|---|
| us-east-1 | `https://object.us-east-1.rumble.cloud` |
| us-east-2 | `https://object.us-east-2.rumble.cloud` |
| us-west-1 | `https://object.us-west-1.rumble.cloud` |

Use the same hostname for the AWS CLI (`--endpoint-url`), boto3 (`endpoint_url`), rclone (`endpoint`), and any other S3 client. When signing requests with SigV4, set the region to `us-east-1` regardless of which Quake AI region you target.

Common mistake from AWS migrators: trying `s3.<region>.rumble.cloud`. That hostname returns DNS NXDOMAIN. The platform's S3 gateway answers only on `object.<region>.rumble.cloud`.

---





### Q: Which S3 features does Quake AI Object Storage support? [T1]


**Core S3 operations:**

| Feature | Notes |
|---|---|
| PUT / GET / DELETE objects | Standard S3 operations via SigV4 signing |
| Multipart uploads | Initiate, upload parts, complete, abort |
| Bucket and object ACLs | GET / PUT ACL on buckets and objects |
| Object versioning | Enable, suspend, list versions, delete markers |
| Server-side encryption | SSE-C (customer-provided) and SSE-OMK (platform-managed) |
| Object tagging | GET / PUT / DELETE object tags |
| Server-side copy | Within the same endpoint |
| Presigned URLs | Time-limited download/upload via SigV4 |
| CORS configuration | Per-bucket CORS rules |
| Batch delete | Multiple objects in a single request |

**Design alternatives:**

| Feature | Alternative |
|---|---|
| Lifecycle policies (transition/expiration) | Use `rclone delete --min-age` on a cron schedule |
| Event notifications (SNS/SQS/Lambda) | Poll with `rclone check --one-way` or handle at the application layer |
| Bucket policies (JSON policy documents) | Use Swift container ACLs (`X-Container-Read`) or S3 ACLs |
| Storage classes (Standard/IA/Glacier) | All data is stored on a single tier |
| Static website hosting | Front your bucket with Nginx or Caddy on a Quake AI VM |
| S3 Select | Download objects and query locally |
| Object Lock / WORM | Contact Quake AI support for compliance workloads |

---





## Core concepts





### Q: How is object storage different from block storage? When should I use each? [T1]


| | Object storage | Block storage (volumes) |
|---|---|---|
| **Access model** | HTTP S3/Swift API | Block device mounted to one instance |
| **Best for** | Backups, media, static assets, data lakes, archives | Databases, application state, OS disks |
| **Scalability** | Petabyte-scale, no filesystem limits | 1 GiB–29,800 GiB per volume |
| **Performance** | High throughput for large sequential reads/writes | Low-latency random I/O |
| **Sharing** | Accessible from anywhere with credentials | Attached to one instance at a time |
| **Modification** | Immutable (overwrite or version) | In-place reads and writes |

Use object storage when your application treats files as whole units (upload once, read many times). Use block storage when your application needs a filesystem with random read/write access, such as a database or OS disk.

---





### Q: How does versioning work, and what are the key behaviors? [T1]


Versioning keeps every version of every object in a bucket. When you overwrite or delete an object, the previous version is retained. You can list, retrieve, or restore any historical version via the S3 API.

Key behaviors to know before enabling:
- Each object version counts against your storage quota.
- Deleting an object in a versioned bucket adds a **delete marker**; the object still exists in previous versions.
- Once enabled, versioning can only be **suspended**, not removed.
- The Quake AI console shows only the current version; all versions are visible via S3 API calls.
- Versioning is configured via the S3-compatible API, there is no versioning toggle in the console.

Enable versioning with `s3cmd setversioning s3://my-bucket enable` or `aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled --endpoint-url "https://object.us-east-1.rumble.cloud"`.

---





### Q: How does server-side encryption work? What are SSE-C and SSE-OMK? [T1]


Quake AI offers two server-side encryption modes. Both use AES-256 and encrypt only object data, not object metadata.

- **SSE-C (customer-provided keys)**: You supply a 256-bit Base64-encoded key with each upload and download request. Quake AI never stores your key; it applies encryption on write and removes the key from memory. HTTPS is mandatory. If you lose the key, the object is permanently unrecoverable. Use SSE-C when compliance requires you to maintain exclusive control of encryption keys.

- **SSE-OMK (object management keys)**: Quake AI manages the encryption keys. Each object is encrypted with a unique key; the key itself is encrypted with a root key that Quake AI rotates on a schedule. No special headers are required on download. Use SSE-OMK for simplicity when key management is not a compliance requirement.

You can configure a bucket to apply SSE-OMK automatically to all new objects using `aws s3api put-bucket-encryption`.

---





### Q: How does CORS work for buckets, and what are the common mistakes? [T1]


CORS (Cross-Origin Resource Sharing) lets browser scripts on one origin access objects on your Quake AI bucket from another origin. Configure per-bucket CORS rules as a JSON policy (AWS CLI) or XML (s3cmd).

Apply a CORS policy:
```bash
# AWS CLI (JSON)
aws s3api put-bucket-cors --bucket your-bucket \
  --cors-configuration file://cors.json

# s3cmd (XML only)
s3cmd setcors /path/to/cors.xml s3://your-bucket
```

**Quake AI-specific pitfall**: CORS preflight requests are not authenticated. You must include the **tenant ID** in the URL provided to browsers for each resource:
```text
https://object.<region>.rumble.cloud/<tenant_id>:bucket/<object>
```
For example: `https://object.us-east-2.rumble.cloud/gT2jQ9uX8pA4vY7fH3kL6dN5mB1rC:bucket/image.jpg`

Common mistakes: using a wildcard `*` for `AllowedOrigins`, forgetting to account for preflight `OPTIONS` requests, omitting custom headers from `AllowedHeaders`, and specifying the wrong protocol or port in origins.

---





### Q: Can I mount object storage as a local drive or filesystem? [T1]


Yes. The recommended tool is **rclone**, which is cross-platform (Windows, macOS, Linux), open source, and actively maintained.

| Client | Platforms | Notes |
|---|---|---|
| **rclone** | All | Recommended; CLI mount and NFS mount |
| **Cyberduck** | Windows, macOS | Free GUI; pre-built Quake AI profiles available |
| **s3fs** | Linux, macOS | FUSE-based |

Configure rclone with `type = s3`, `provider = Ceph`, and your region endpoint, then run `rclone mount quakeai:my-bucket/ /mnt/s3bucket`.

**Important**: Only allow one system to mount a bucket as **writable** at a time. Concurrent writes from multiple systems can cause data loss (last writer wins). Enable versioning as a safety net if multiple systems need write access.

---





### Q: How do I access object storage over FTP, FTPS, or SFTP? [T1]


Object storage does not expose FTP/SFTP natively. The supported path is to set up a **gateway VM** that mounts your bucket using `s3fs` and then runs an FTP/SFTP server on top of that mount.

The recommended approach uses an Ubuntu 24.04 VM with `s3fs` to mount the bucket at `/opt/s3storage`, then exposes the mount over SFTP (which works without extra configuration on Ubuntu), FTPS (via `vsftpd` with SSL), or FTP (via `vsftpd`, but only within a private VPC: FTP sends passwords in plaintext).

Quake AI strongly recommends **SFTP or direct S3** for internet-facing transfers. FTP should only be used on private VPC networks. For Windows or other OS-based gateways, `rclone mount` works identically.

---





## Access control policies





### Q: How do I make a bucket publicly readable? [T1]


Apply a public-read policy using the S3-compatible API. The simplest policy grants `s3:GetObject` to `Principal: "*"` (all users):

```json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PublicReadGetObject",
    "Principal": "*",
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": ["arn:aws:s3::$tenant:$bucket/*"]
  }]
}
```

Replace `$tenant` with your project name and `$bucket` with the bucket name. Apply with `s3cmd setpolicy policy.json s3://my-bucket` or `aws s3api put-bucket-policy --bucket my-bucket --policy file://policy.json --endpoint-url "https://object.us-east-1.rumble.cloud"`. You can also toggle public access in the console under **Storage > Object Storage > Edit Container**.

---





### Q: Why does my public bucket URL return 404 from the browser after I apply a public-read policy? [T2]


Anonymous URLs on the Quake AI S3 gateway require a tenant prefix in the path. Without it the gateway returns `404 Not Found` even when the bucket policy grants public read.

The URL pattern is:

```text
https://object.<region>.rumble.cloud/<tenant_id>:<bucket>/<key>
```

For example, with a project ID of `gT2jQ9uX8pA4vY7fH3kL6dN5mB1rC` and a bucket named `assets`:

```text
https://object.us-east-1.rumble.cloud/gT2jQ9uX8pA4vY7fH3kL6dN5mB1rC:assets/logo.png
```

Find your tenant ID with `openstack token issue -f value -c project_id` or in the Quake AI portal under the project's settings. The bucket-policy ARN format (`arn:aws:s3::<tenant>:<bucket>`) already encodes the tenant; the URL the browser fetches must match that scope at the path level. The same prefix applies to CORS preflight requests; see [CORS setup](/docs/object/how-to/configure-bucket-cors) for the cross-origin specifics.

---





### Q: How do I make a bucket read-only for a specific user? [T1]


Use a read-only policy that explicitly allows `s3:GetObject` and `s3:ListBucket`, and denies all write and delete actions for the specified user. The policy references the user as an ARN in the form `arn:aws:iam::$tenant:user/$user`.

**Warning**: The strict read-only policy (`read-only-policy.mdx`) locks out write access so strongly that the policy itself cannot be removed without admin assistance. If you need the ability to self-revert the policy later, use the **user-reversible read-only policy** instead, which additionally grants `s3:DeleteBucketPolicy` and `s3:PutBucketPolicy` to the named user.

Remove any lifecycle policies before applying either read-only variant.

---





### Q: How do I restrict bucket access to specific IP addresses? [T1]


Use an IP whitelist (source IP) policy with the `aws:SourceIp` condition. Two variants are available:

- **Block all access except from a known IP**: uses `Effect: Deny` with `NotIpAddress` condition on `Principal: "*"`.
- **Allow public read only from a known IP**: uses `Effect: Allow` with `IpAddress` condition on `s3:GetObject` for `Principal: "*"`.

Both use a CIDR block (e.g., `1.2.3.4/32` for a single IP). The `Resource` array covers both the bucket and its objects (`arn:aws:s3:::YourBucket` and `arn:aws:s3:::YourBucket/*`).

---





### Q: How do I allow public read on a bucket but restrict access beyond that? [T1]


Use the **restricted public read** policy, which grants `s3:GetObject` to `Principal: "*"` on all objects in the bucket, but does not grant `s3:ListBucket`. This lets anyone who knows an object's URL download it, while preventing enumeration of bucket contents.

The policy structure is identical to the public-read policy but intentionally omits `ListBucket`:

```json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PublicReadGetObject",
    "Principal": "*",
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": ["arn:aws:s3::$tenant:$bucket/*"]
  }]
}
```

For even finer-grained control (granting different permissions to different users), use the `grant-access-control` how-to, which shows a multi-statement policy granting read/write to one user and read-only to another.

---





### Q: Where do I set CORS rules, lifecycle policies, or bucket policies in the Console? [T2]


The Console exposes only basic bucket operations (create, delete, public-access toggle, file browse, upload, download). CORS configuration, JSON bucket policies, versioning, and per-user access grants live on the S3-compatible API; configure them with `aws s3api`, `s3cmd`, or another S3 client.

Available in the Console:

- Create and delete buckets
- Toggle the bucket's **Public Access** flag at create time or via the row's **Update Access** action
- Browse, upload, and download objects inside a bucket
- Delete individual objects from a bucket

Requires the S3 API or CLI:

| Operation | Command |
|---|---|
| CORS rules | `aws s3api put-bucket-cors` |
| JSON bucket policies (public-read, IP whitelist, read-only) | `aws s3api put-bucket-policy` |
| Versioning | `aws s3api put-bucket-versioning` |
| Server-side encryption configuration | `aws s3api put-bucket-encryption` |
| Multi-user access grants | See [Grant access control](/docs/object/how-to/grant-access-control) |

Quake AI Object Storage does not implement lifecycle rules (object transition and expiration) on any surface. Implement retention with `rclone delete --min-age` on a schedule. The full design-alternatives table sits in the "Which S3 features does Quake AI Object Storage support?" entry above.

---





## Operations and troubleshooting





### Q: Why do Object Storage API curl examples fail before the first request? [T2]


Application-credential `openrc` files do not export the token or protocol-specific URLs that Swift and S3 API examples use. Export them in the same shell before you run curl:

```bash
export OS_TOKEN="$(openstack token issue -f value -c id)"
export OS_PROJECT_ID="$(openstack token issue -f value -c project_id)"
export OS_SWIFT_S3_URL="https://object.${OS_REGION_NAME}.rumble.cloud"
export OS_SWIFT_URL="${OS_SWIFT_S3_URL}/swift/v1/AUTH_${OS_PROJECT_ID}"
```

On macOS, avoid bare `swift post` in tutorials: the system Swift compiler shares that command name. Prefer the curl API paths in the how-to guides or run OpenStack CLI commands from a Linux shell.





### Q: Why am I getting a 403 or 401 error when calling the S3 API? [T1]


The quick triage table from the access runbook:

| Symptom | Most likely cause |
|---|---|
| `InvalidAccessKeyId` | EC2 credentials do not exist or wrong project scope |
| `SignatureDoesNotMatch` | Wrong region in SigV4, clock skew, or wrong endpoint |
| `Access Denied` | Correct credentials but wrong project, or container ACL blocks access |

**The most important distinction**: EC2 (S3) credentials and OpenStack application credentials are different. Application credentials authenticate the OpenStack API; they do **not** work as S3 access keys. You must create EC2 credentials for S3 access via `openstack ec2 credentials create`.

**EC2 credentials are project-scoped**: a key from one project cannot access buckets in another project.

**SigV4 signing**: always set the S3 region to `us-east-1` regardless of which Quake AI region you use. Wrong region produces `SignatureDoesNotMatch` even when the key pair is valid.

Resolution steps:
1. `openstack ec2 credentials list`, confirm credentials exist with the correct `project_id`.
2. If none exist: `openstack ec2 credentials create`.
3. Set the region to `us-east-1` in your S3 client config.
4. Set the endpoint from an environment variable; do not hardcode it.
5. Test: `aws s3 ls --endpoint-url "${YOUR_ENDPOINT}"`.
6. If `SignatureDoesNotMatch` persists after verifying region and endpoint, regenerate credentials.

Escalate if regenerated credentials with correct project and verified SigV4 settings still return 401/403, or if multiple projects fail simultaneously (possible platform identity or gateway issue).

---





### Q: Why do large file uploads fail, and how do I fix it? [T1]


Objects larger than 5 GB require multipart upload. Common failure modes:

| Symptom | Cause |
|---|---|
| `EntityTooLarge` | Single-part upload attempted on an object > 5 GB |
| Transfer stalls or times out | Network timeout during part upload, or stale incomplete multipart upload |
| Errors on objects > a certain size | Swift S3 gateway segment size limits differ from AWS S3's 5 GB per-part maximum |

**Resolution**:

For AWS CLI, multipart kicks in automatically for objects larger than 8 MB. Confirm it is working with `--debug`. For boto3, set `TransferConfig(multipart_threshold=8 * 1024 * 1024, multipart_chunksize=16 * 1024 * 1024)` explicitly.

List and abort stale multipart uploads:
```bash
aws s3api list-multipart-uploads --bucket YOUR_BUCKET --endpoint-url "${YOUR_ENDPOINT}"
aws s3api abort-multipart-upload --bucket YOUR_BUCKET --key YOUR_KEY \
  --upload-id YOUR_UPLOAD_ID --endpoint-url "${YOUR_ENDPOINT}"
```

For large or resumable transfers, **rclone** is the recommended tool. It handles multipart and retries automatically. For objects well above 50 GB, split into smaller objects or use a dedicated bulk transfer tool.

---





## Migration





### Q: Which migration tool should I use? [T1]


Five tools cover the common migration and backup scenarios. Choose based on your primary requirement:

| Scenario | Recommended tool | Why |
|---|---|---|
| **Full migration** from another S3-compatible provider | **rclone** | Direct cloud-to-cloud, no local staging, parallel transfers, checksum verification |
| **Custom metadata must be preserved** | **MinIO Client (`mc`)** | Only tool that copies `x-amz-meta-*` headers between providers |
| **Encrypted, deduplicated backups** | **restic** | Built-in AES-256 encryption, content-defined chunking, retention policies |
| **AWS-centric workflow** | **AWS CLI** | Familiar, but requires local staging for cross-provider transfers |
| **Simple file-level backup** | **rclone** | `rclone copy` with cron: reliable, cross-platform |

Neither rclone, the AWS CLI, nor s3cmd preserves custom `x-amz-meta-*` metadata during cross-provider copies. Use MinIO Client if metadata must survive the transfer.

---





### Q: What is the recommended path to migrate from AWS S3? [T1]


AWS offers free data transfer out when migrating away, so there are no egress fees for this path.

The recommended tool is **rclone**, which copies directly between endpoints without local staging. Configure both AWS and Quake AI as rclone remotes, then:

1. Run an initial `rclone copy aws:my-source-bucket quakeai:my-bucket` (use `copy`, not `sync`, for the initial pass, safer, no deletions).
2. Schedule daily `rclone sync` delta passes until you are ready to cut over.
3. On cutover: run a final `rclone sync`, update your application's S3 endpoint, keep the AWS source for 30 days as a rollback target.

Features that do not transfer and need remediation before migrating: lifecycle policies, event notifications, S3-format JSON bucket policies, and S3 Replication rules. All objects land on a single storage tier on Quake AI (no storage class transitions needed).

If objects have custom `x-amz-meta-*` headers, use MinIO Client's `mc mirror` instead of rclone.

---





### Q: What is the recommended path to migrate from Google Cloud Storage? [T1]


Use **rclone** with a GCS service account JSON key file. Configure the GCS remote with `type = google cloud storage` and the Quake AI remote with `type = s3, provider = Ceph`.

GCS-specific considerations:
- **Egress cost**: GCS charges per-GB egress and does not run a free migration program. Confirm current rates on the [Google Cloud Storage pricing page](https://cloud.google.com/storage/pricing).
- **Storage classes**: Objects in Nearline, Coldline, or Archive have minimum storage duration charges (30, 90, and 365 days). Deleting them before the minimum incurs an early deletion fee.
- **IAM permissions**: GCS IAM roles do not translate to Swift ACLs. Re-apply access controls on Quake AI after migration.
- **Lifecycle rules**: Not supported on Quake AI; implement retention with `rclone delete --min-age`.

---





### Q: What is the recommended path to migrate from Azure Blob Storage? [T1]


Use **rclone** with an Azure SAS token or service principal. Configure the Azure remote with `type = azureblob`.

Azure-specific considerations:
- **Egress cost**: Azure charges per-GB egress and does not run a free migration program. Confirm current rates on the [Azure bandwidth pricing page](https://azure.microsoft.com/en-us/pricing/details/bandwidth/).
- **Archive tier**: objects in Azure Archive must be rehydrated before copying (up to 15 hours, per-GB fee).
- **Access tiers**: Hot, Cool, Cold, and Archive all land on a single tier on Quake AI.
- **RBAC/ABAC**: Azure Entra ID policies do not translate to Swift ACLs. Re-apply access controls using the Quake AI grant-access-control how-to.
- **Lifecycle policies**: not supported on Quake AI; implement with external tooling.

Note: In Azure terminology, "containers" hold "blobs." On Quake AI, "buckets" (also called containers) hold "objects." The rclone config calls the Azure side `azure:my-source-container`.

---





### Q: What is the recommended path to migrate from Backblaze B2? [T1]


B2 supports both its native API and an S3-compatible API; rclone handles both with direct cloud-to-cloud transfer.

Use the **B2-native rclone remote** (`type = b2`) for the source. It has faster listing operations than B2's S3-compatible endpoint.

B2-specific considerations:
- **Egress**: B2 charges per-GB for direct egress. Via the Cloudflare Bandwidth Alliance, egress is free up to 3× your stored data per day, so a Cloudflare-fronted bucket migrates without egress charges. Confirm current rates on the [Backblaze B2 pricing page](https://www.backblaze.com/cloud-storage/pricing).
- **File caps**: B2 allows up to 10 million files per bucket; plan parallel transfers and checkpoint progress near this limit.
- **Lifecycle rules**: do not transfer; implement retention with `rclone delete --min-age`.

---





### Q: What is the recommended path to migrate from Wasabi? [T1]


Both Wasabi and Quake AI use S3-compatible APIs, so rclone copies directly without local staging. Configure a Wasabi remote with `type = s3, provider = Wasabi` and the region-specific endpoint.

Wasabi-specific considerations:
- **Egress**: Wasabi does not charge for egress, provided your egress stays below your total stored data volume. Migrate while data is still stored on Wasabi.
- **90-day minimum storage**: Wasabi bills each object for at least 90 days. Deleting after migration may not immediately save money. Keep the Wasabi source for at least 90 days; if objects are already past the minimum, a 30-day holdover is sufficient.

---





### Q: What is the recommended path to migrate from Hetzner Object Storage? [T1]


Both Hetzner Object Storage and Quake AI use S3-compatible APIs backed by Ceph, making this one of the simplest migration paths. Configure an rclone remote with `type = s3, provider = Other` and the Hetzner region endpoint (`fsn1`, `nbg1`, or `hel1`).

Hetzner-specific considerations:
- **No egress fees**: outbound transfer is included in the Hetzner plan.
- **Custom metadata**: rclone and s3cmd do not preserve `x-amz-meta-*` headers during cross-provider copies. Use MinIO Client if metadata must be preserved.
- **100-bucket limit**: Hetzner limits accounts to 100 buckets; Quake AI does not impose a hard bucket limit.

---





### Q: What is the recommended path to migrate from DigitalOcean Spaces? [T1]


DigitalOcean Spaces and Quake AI both use S3-compatible APIs. Configure an rclone remote with `type = s3, provider = DigitalOcean` and the Spaces endpoint for your region (`nyc3`, `sfo3`, `ams3`, etc.).

DigitalOcean-specific considerations:
- **Egress**: DigitalOcean includes a per-subscription outbound transfer allowance for Spaces and charges per-GiB for overage. Confirm current allowances and rates on the [DigitalOcean Spaces pricing page](https://www.digitalocean.com/pricing/spaces-object-storage).
- **CDN**: the built-in Spaces CDN is not available on Quake AI. Front your Quake AI bucket with Cloudflare or CloudFront after migration.
- **Billing**: Spaces billing ends only when all Spaces are deleted. Delete Spaces after the 30-day holdover period to stop charges.
- **Terminology**: DO calls each bucket a "Space." The rclone workflow is identical to any S3-compatible source.

---





### Q: How do I use Quake AI as a backup target without fully migrating? [T1]


You do not need to migrate your primary storage to use Quake AI as an off-site backup destination. Quake AI works well as the "one off-site copy" in a 3-2-1 strategy (three copies, two media types, one off-site).

Two tools cover the main patterns:
- **rclone**: file-level backups with `rclone copy` on a cron schedule. Use `copy` (not `sync`) for backups so local deletions do not propagate to the backup bucket. Supports PostgreSQL, MySQL, and SQLite dump scripts.
- **restic**: encrypted, deduplicated backups with built-in AES-256 encryption and retention policies (`restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune`). Encrypt before upload; server-side encryption is an additional optional layer.

Object storage on Quake AI is a per-TB add-on, and each dedicated vCPU subscription includes 1 TB at no additional cost. Backups within the included allowance do not add to the bill. For current rates, see the canonical [Quake AI pricing page](https://www.quake.ai/pricing/).

---





### Q: How do I keep Quake AI synchronized with another provider on an ongoing basis? [T1]


Use **rclone** in active-passive replication mode: your application writes to the primary provider, and a cron job on a small Quake AI VM syncs changes to Quake AI on a schedule. Quake AI acts as a read-only replica and failover target.

```bash
rclone sync primary:my-bucket quakeai:my-bucket-replica \
  --transfers 16 --checkers 32 \
  --log-file /var/log/rclone-sync.log --log-level INFO
```

For hourly replication, add that command to cron. Use `--bwlimit` to cap bandwidth during business hours.

For failover: point your application at the Quake AI endpoint, then reverse the sync direction once the primary recovers. After both sides are in sync, revert the application endpoint.

For selective sync (only specific prefixes), use `--include "/backups/**" --include "/media/**"`.

**Note**: rclone `bisync` (bidirectional) is marked experimental and can cause data loss on edge cases. Use append-only naming patterns or prefix partitioning for workloads that write to both sides independently.

---





## Pricing, quotas, availability, and support





### Q: What regions is object storage available in? [T2]


Object storage runs in all three Quake AI regions and exposes one S3-compatible endpoint per region:

- `object.us-east-1.rumble.cloud`
- `object.us-east-2.rumble.cloud`
- `object.us-west-1.rumble.cloud`

Each endpoint serves an independent bucket namespace; a bucket created in one region is not visible from another. No automatic cross-region replication exists. To replicate objects across regions, use a tool from [Migration tools comparison](/docs/object/migration/tools-comparison) (rclone, AWS CLI, or MinIO Client) and run it on a schedule. See [Regions](/docs/platform#regions) for the platform-wide region table.

---





### Q: What is the SLA for object storage? [T2]


The contractual durability target, availability target, and credit schedule are published as part of Quake AI's commercial terms at [rumble.cloud/legal](https://rumble.cloud/legal). The [Service Level Agreement page](/docs/account/sla) explains how to read those terms and how to file a credit claim. Storage-layer replication (the multi-node Ceph cluster behind the S3 API) protects against hardware-level loss within a region. For cross-region durability, replicate objects to a bucket in a second region with the tool of your choice.

---





### Q: How do I get help if something is broken? [T2]


For most access problems, start with the runbook:

- [Object storage access troubleshooting](/docs/operate/runbooks/object-storage-access): S3 403/401 errors, credential confusion (`InvalidAccessKeyId`, `SignatureDoesNotMatch`), and large file upload failures (`EntityTooLarge`).

Before opening a support ticket, gather this evidence (redact all secrets and access keys):

| Artifact | Command |
|---|---|
| EC2 credential rows | `openstack ec2 credentials list` |
| Active project | `openstack project show YOUR_PROJECT_NAME -c id` |
| S3 list test (redacted) | `aws s3 ls --endpoint-url "${YOUR_ENDPOINT}" --debug 2>&1 \| tail -20` |
| Incomplete multipart uploads | `aws s3api list-multipart-uploads --bucket YOUR_BUCKET --endpoint-url "${YOUR_ENDPOINT}"` |
| Failure time (UTC) | `date -u` |

If the runbook does not resolve the issue, [open a support ticket](https://rumble.cloud/support) with the evidence above. [Get help](/docs/get-help) is the canonical decision tree for picking the right starting point based on the symptom, and [Support ticket evidence collection](/docs/operate/troubleshooting/support-ticket-evidence) is the full evidence checklist.

---





## See also

- [Object Storage overview](/docs/object): getting started, how-to index, reference links
- [Object Storage concepts](/docs/object/concepts/object-storage): deep background on how object storage works, S3 API compatibility, and access control
- [Object Storage how-to guides](/docs/object/how-to): step-by-step instructions for every common operation
- [Create S3 credentials](/docs/object/how-to/create-s3-credentials): generate EC2 credentials for S3-compatible tools
- [Grant access control](/docs/object/how-to/grant-access-control): bucket policy structure, apply via CLI or API
- [Enable versioning](/docs/object/how-to/enable-versioning): enable, suspend, and manage object versions
- [Mount S3 storage](/docs/object/how-to/mount-s3-storage): rclone, Cyberduck, and s3fs
- [Server-side encryption](/docs/object/how-to/configure-server-side-encryption): SSE-C and SSE-OMK implementation guide
- [CORS setup](/docs/object/how-to/configure-bucket-cors): configure per-bucket CORS rules
- [FTP, FTPS, and SFTP access](/docs/object/how-to/access-via-ftp-sftp): S3 gateway VM setup
- [Object storage access troubleshooting](/docs/operate/runbooks/object-storage-access): 403/401 errors and large upload failures
- [Plan your migration](/docs/object/migration/plan-your-migration): S3 compatibility matrix, egress cost table, validation checklist
- [Migration tools comparison](/docs/object/migration/tools-comparison): rclone, AWS CLI, s3cmd, MinIO Client, restic
- [Migrate from AWS S3](/docs/object/migration/migrate-from-s3): provider-specific cutover guide
- [Migrate from Google Cloud Storage](/docs/object/migration/migrate-from-gcs)
- [Migrate from Azure Blob Storage](/docs/object/migration/migrate-from-azure)
- [Migrate from Backblaze B2](/docs/object/migration/migrate-from-backblaze)
- [Migrate from Wasabi](/docs/object/migration/migrate-from-wasabi)
- [Migrate from Hetzner Object Storage](/docs/object/migration/migrate-from-hetzner)
- [Migrate from DigitalOcean Spaces](/docs/object/migration/migrate-from-digitalocean)
- [Back up to Quake AI](/docs/object/migration/backup-to-quake-ai): 3-2-1 backups with rclone and restic
- [Multi-cloud sync](/docs/object/migration/multi-cloud-sync): active-passive replication and failover
- [Coming from AWS](/resources/migration/coming-from-aws): service-by-service mapping including S3 → Swift
- [Coming from DigitalOcean](/resources/migration/coming-from-digitalocean): Spaces → Swift mapping