Restic S3 backups: AWS S3 vs Cloudflare R2, Backblaze B2, Wasabi, and MinIO

For most small teams, choose a managed object store that is outside the production server’s failure domain and that your responders can access during an outage. Amazon S3 is the practical default when you already operate AWS identity and incident access. Cloudflare R2, Backblaze B2, and Wasabi are viable managed alternatives when an independent provider, their account model, or their current commercial terms better fit your recovery plan. Use MinIO only when you already have the people and independent infrastructure to operate storage itself.

All five can store a restic repository, but they do not create the same recovery burden. A managed provider operates the object-storage service; you still own its account access, bucket policy, recovery credentials, and restore test. With MinIO, you also own the storage service’s disks, redundancy, TLS, upgrades, monitoring, and disaster recovery. That distinction matters more than whether an endpoint accepts an S3 request.

Start with the amount of data you can afford to lose—your recovery point objective (RPO)—and the time in which you need service back—your recovery time objective (RTO). Then test whether the chosen storage account, credential process, network path, and repository password let a different machine restore the required data inside that plan. A green upload proves only that one backup run completed; it does not prove recovery.

• Best default for an existing AWS team: Amazon S3, with a dedicated bucket or repository prefix and a non-root credential scoped to that repository.
• Lower-operations independent option: compare Cloudflare R2, Backblaze B2, and Wasabi using their current pricing, data-location, retrieval, support, credential-recovery, and egress terms. Those terms can change, so do not choose from an old price comparison.
• Higher-resilience option: use a managed provider in a separate account or administrative boundary from production, protect break-glass access, and rehearse restores from a clean host. Add an independently operated second copy if your recovery plan requires it.
• Use MinIO when it is already operated across an independent failure domain. A MinIO instance on the same server, rack, cluster, or administrator boundary as production is not an independent off-site backup.

This ranking is based on recovery-day operational effort: who runs the storage service, whether the team already has a tested identity path, and whether the storage can remain available when the production host or account is not. It is not a durability, performance, feature, or price ranking. Validate current provider terms and the exact endpoint before making a production choice.

The table is deliberately compact. Every choice still needs a repository initialization test, a normal backup, retention maintenance where you plan to use it, a repository check, and an isolated restore. Provider documentation is the authority for current endpoint format, regions, access-key creation, lifecycle behavior, and account limits.

• Pick AWS S3 when AWS IAM, account recovery, audit access, and incident responders are already in place.
• Pick R2, B2, or Wasabi after testing their current S3-compatible endpoint and the account path needed to issue or recover a restore credential.
• Pick MinIO only when its own storage recovery is already a maintained operational responsibility, not a side effect of installing an S3-compatible service.

Restic encrypts and deduplicates data on the machine being backed up, then writes repository objects to storage. Moving from Amazon S3 to an S3-compatible service changes the endpoint and credentials; it does not change restic’s repository format or hand the provider your plaintext files.

That narrows the provider decision. Check that the service supports the S3 operations restic needs, that credentials can be limited appropriately, and that the endpoint will be reachable during recovery. Account security, data location, provider availability, request charges, download or retrieval behavior, and support arrangements are separate operational decisions. Prices change too often to be a sound architectural shortcut.

• Do not treat client-side encryption as a substitute for storage-account security. An attacker who can obtain the repository password and usable storage access may still be able to read or destroy backups.
• Do not assume an S3-compatible label proves compatibility with your workflow. Test the exact provider, endpoint, bucket, credential policy, retention operation, and restore path you will run.

All five options can hold a restic repository. The useful dividing line is who must recover the storage service before restic can recover your files.

If the team already handles incidents in AWS, Amazon S3 keeps identity, audit logs, and regional recovery in that system. Cloudflare R2, Backblaze B2, and Wasabi are managed alternatives with different account and retrieval models; compare their current terms against your backup size and restore pattern. MinIO is different: it is software you operate, so its disks, replicas, TLS, upgrades, monitoring, and recovery plan become prerequisites for every restic restore.

• Existing AWS estate: S3 is usually the least surprising choice because IAM and incident access already exist. Scope one machine role or key to the repository prefix.
• Independent managed copy: R2, B2, or Wasabi can keep backups outside the production cloud account. Check credential recovery, data location, egress or retrieval rules, and support before choosing between them.
• Existing private storage platform: MinIO is reasonable when another team already operates it across an independent failure domain. Installing it beside the server being backed up does not create an off-site backup.
• Small team without object-storage operations: prefer a managed service. Owning fewer storage components is more valuable on recovery day than matching an existing S3 API perfectly.

A restic S3 repository combines an endpoint, bucket, and optional prefix. Copy the endpoint and region from the provider’s documentation or console rather than guessing them: a mismatch can appear as a redirect, signature, TLS, or access error. The correct settings for a bucket are provider- and region-specific.

Keep the selected endpoint, bucket, region, and prefix in a recovery record that is available when the source server is gone. Include the repository identifier, the credential-issuance procedure, the location of the restic password or recovery key, and the documented restore owner. Store that record separately from the server and do not put secrets in a ticket, shell history, Compose file, or source repository.

For a broader configuration and recovery record checklist, use the [restic S3 backup checklist](https://restedbackups.com/blog/keyword-restic-s3-backup-checklist). It is especially useful when the endpoint configuration is not the default AWS path.

• Amazon S3: record the bucket’s intended region and use the endpoint and region expected by your chosen restic configuration.
• Cloudflare R2, Backblaze B2, and Wasabi: use the provider’s S3-compatible API endpoint, not an unrelated account, web-console, or management endpoint.
• MinIO: use the S3 API address rather than the administrative or Console address, and make sure the backup host trusts the HTTPS certificate.

An active restic repository needs to list, read, write, and delete objects. Read access is needed for indexes, snapshots, and restores. Write access creates repository data and locks. Delete access matters when restic removes locks and when retention runs forget and prune. Amazon S3 clients may also need s3:GetBucketLocation. A write-only credential may complete part of an upload and still leave you with an unusable maintenance or restore path.

Create a dedicated credential for backup work instead of reusing a root or account-owner key. Scope it to the repository bucket and, where the provider’s policy model supports it reliably, to the repository prefix. Prefix controls are provider-specific: Amazon IAM conditions, Backblaze file-name restrictions, R2 bucket selection, Wasabi policies, and MinIO policies use different syntax and have different edge cases.

Separate the routine backup credential from a documented emergency path where practical. The emergency path may be a protected process to issue a temporary credential rather than a long-lived key stored on the production server. Either way, test it from a host that does not have the original server’s environment or cached credentials.

• Before production use, prove that the backup credential can initialize or open the intended repository, back up data, list snapshots, run your planned maintenance, and restore to a separate target.
• If list access fails at the bucket or prefix boundary, restic may be unable to find repository metadata even when uploads appear to work.
• Review least privilege against the provider’s current policy documentation. The [minimum S3 permissions for restic backups and pruning](https://restedbackups.com/blog/restic-s3-permissions) guide explains why backup and retention operations need more than write access.