Backup, archive, and object storage

Store snapshots, archives, and backups on Quake AI's S3-compatible object storage. You operate backup schedules, retention rules, and restore workflows; Quake AI provides Object Storage buckets, EC2-compatible credentials, and the networking path your backup agents reach over HTTPS.

What this is for#

Teams that need an off-site or secondary copy of snapshots, database dumps, and archives store them in S3-compatible object storage without per-gigabyte egress charges on restore. Quake AI provides the bucket, EC2-compatible credentials, and the HTTPS endpoint; you operate the backup tooling, schedules, and retention. The outcome is a durable backup target your existing restic, rclone, or backup agent can write to, deployable from a validated OpenTofu template and its companion tutorial.

Reference architecture#

Download diagram: SVG, PNG, and PDF.

The base is a single validated template: S3 Storage with ACLs provisions the bucket, its ACL policy, and the credentials endpoint. Everything else (source data and the backup agents) runs on your side and reaches the bucket through the Object Storage S3 gateway over HTTPS.

1. Source data. VMs, databases, and file stores produce snapshots and dumps on a schedule you control.

2. Backup agents. Tools such as restic, rclone, or a backup product read source data and write objects to Quake AI over HTTPS using EC2-compatible credentials.

3. S3 gateway. Quake AI exposes an S3-compatible endpoint (OpenStack Swift with the S3 API) that backup agents target with a bucket name, region string, and endpoint URL.

4. Object Storage bucket. Backups land in an Object Storage bucket with the ACL policy you define. The S3 Storage with ACLs template provisions the bucket, ACL, and credentials endpoint. Restores read objects back out on demand.

Services involved#

Get started#

• S3 Storage with ACLs template and its deploy tutorial: OpenTofu pattern that provisions a private bucket with ACLs on Quake AI Object Storage.
• Back up to Quake AI: rclone, restic, and cron patterns for ongoing backups into Object Storage.
• Upload objects to Object Storage: verify credentials and bucket access before you run bulk sync jobs.
• OpenTofu template library: browse validated IaC starting points for backup and archive layouts.

Estimate the cost#

Migrating an existing backup / archive estate?#

Move a backup or archive estate that already lives on Amazon S3, Google Cloud Storage, Azure Blob Storage, Backblaze B2, Wasabi, or another S3-compatible provider. The outcome is the same data on Quake AI Object Storage with retention rules, scheduled jobs, and restore paths cut over in a controlled order.

Follow this cutover path. Each step links an existing migration page; this section composes those pages into a workload-shaped sequence rather than duplicating their steps.

1. Map your source provider. Start with the concept-translation page for your current cloud: Coming from AWS, Coming from Azure, Coming from GCP, Coming from DigitalOcean, or Coming from Hetzner. For Backblaze B2 or Wasabi, start with the matching object migration page in step 3.

2. Stand up the target shape on Quake AI. Provision the migration target bucket with the S3 Storage with ACLs template so backup agents have a bucket, ACL, and credentials endpoint to write to.

3. Bulk-copy existing backups and archives. Choose the primitive page that matches your source object store: Migrate from S3, Migrate from GCS, or Migrate from Azure Blob Storage. For Backblaze B2 or Wasabi, follow Migrate from Backblaze or Migrate from Wasabi.

4. Configure ongoing backup jobs on Quake AI. After the historical copy completes, wire scheduled backups with Back up to Quake AI.

5. Run dual-write or phased sync if needed. When you cannot pause writers during the copy window, use Multi-cloud sync to keep source and target buckets aligned until cutover.

6. Switch backup tooling to Quake AI. Update bucket names, region strings, and the S3 endpoint URL in restic, rclone, or your backup agent. See How to update your application's S3 endpoint for Quake AI.

Workload-specific cutover callouts#

• Bulk object sync. Plan capacity and transfer time for full-bucket copies before you disable source jobs. Resume interrupted syncs; compare object counts and total size on source and target when the copy finishes.
• Retention and lifecycle re-creation. Quake AI Object Storage does not mirror every source lifecycle API one-to-one. Re-create expiration, transition, and legal-hold behavior in your backup product or in bucket policy after you map what the source rules did.
• Integrity verification (ETag/checksum). Validate spot checks and checksum or ETag comparisons on restore-critical objects after bulk sync. Treat mismatches as copy failures before you retire the source bucket.
• Endpoint update in backup tooling. Issue Quake AI EC2-compatible credentials, set the S3 gateway endpoint your region documents, and run a test backup and restore on a non-production prefix before you redirect production schedules.

Considerations and limits#

• You operate the backup tooling. Quake AI provides the bucket and credentials; schedules, retention, encryption, and restore testing are yours under the shared responsibility model.
• Lifecycle parity is not one-to-one. Quake AI Object Storage does not mirror every source lifecycle API. Re-create expiration, transition, and legal-hold behavior in your backup product or bucket policy.
• Flat egress. Quake AI applies a no-egress-fee policy for outbound transfer, which keeps restore and disaster-recovery reads predictable.
• Three US regions. All current regions are in the United States. Cross-region redundancy requires a copy strategy you operate across regions.
• Compliance posture. Quake AI holds SOC 2 Type I and Type II attestations and SOC 3. See Compliance and certifications for the platform scope.