Provider guide

Mac Backup to Wasabi: Encrypted Offsite Storage

Wasabi is an S3-compatible storage provider with regional service URLs. Azivault can use a Wasabi bucket as an encrypted offsite backup destination.

When this setup makes sense

Users who want S3-compatible offsite backup storage with explicit regional endpoints and a storage account they manage directly.

Can Azivault back up a Mac to Wasabi?

Yes. Wasabi is the offsite storage layer in this setup. Azivault creates the encrypted backup repository and writes encrypted repository objects to a private Wasabi bucket. Storage billing, bucket access, and account recovery stay with Wasabi; backup and restore behavior stays with Azivault.

Wasabi setup at a glance

Create a private bucket and note its region.
Use the Wasabi service URL that matches that region.
Create an access key with access to the backup bucket.
Run Azivault's storage test, then complete a real backup and file restore.

What to enter in Azivault

In Azivault, choose Create New Plan, select the source folder, then go to Storage. Set Destination type to S3 compatible.

Bucket name: the bucket dedicated to the Azivault repository.
Region: Use the bucket's Wasabi region. If you move to a different Wasabi region, create a new bucket and update the Azivault plan accordingly.
Custom endpoint: Choose the Wasabi service URL that matches the bucket location, such as a regional s3.<region>.wasabisys.com endpoint.
Use path-style requests: Azivault turns this on by default when a custom endpoint is present, unless you manually change the toggle.
Access key ID and secret access key: Use a Wasabi access key pair that has permission to read and write the backup bucket. Avoid reusing broad account keys when a narrower key is available.
Session token: optional. Use it only if the provider issued one for the credentials.

Setup checklist

Create a private Wasabi bucket in the region you want.
Copy the service URL for that region from Wasabi's documentation or console.
Enter the bucket, region, service URL, access key, and secret key in Azivault.
Run a first backup and restore one test file before treating the setup as complete.
Click Test in Azivault and wait for a healthy result before adding the plan.
Finish the schedule and recovery password steps, then add the plan.

What the storage test verifies

Azivault's S3 test is a real read/write check. It writes a small object under .azivault-health-check/, confirms the object exists, lists that prefix, reads the object back, and deletes it. If the test fails, review the bucket, region, endpoint URL, credentials, path-style setting, and network access.

Common Wasabi connection problems

The service URL does not match the bucket's region.
The bucket name is correct, but the access key lacks read, write, list, or delete access needed by the health check.
A copied endpoint includes a console URL or bucket path instead of the regional S3 service URL.
Minimum-storage-duration and retention choices were not considered before using the bucket for production backups.

Restore and disaster recovery

Existing backups remain restorable even if a subscription expires, but you still need the repository data, provider access, and the Azivault recovery password or synced Keychain key. For S3-compatible storage, plan how you would hydrate or copy the remote repository objects to a local folder, then import that repository folder into Azivault for restore browsing.

Wasabi backup risks

Object lock support: Wasabi supports immutable bucket configurations, but retention can also make accidental repository growth or bad lifecycle choices harder to undo. Decide whether immutability is part of your threat model before first production use.
Lifecycle rules: Lifecycle expiration can remove backup objects that still matter to older snapshots. If you use lifecycle rules, start with a separate test bucket and run an actual restore after the rule has affected objects.
Egress costs: Wasabi markets no egress or API request fees, but account terms, minimum storage duration, and fair-use details still matter. Check the current pricing page before assuming a large restore will be cost-free.
Regional durability: Choose the region for both latency and failure planning. A single-region bucket is not the same thing as a second independent offsite copy in another provider or geography.
Access key scope: Prefer a key pair dedicated to the backup bucket. If you use a general account key, rotating it later can break multiple tools at once, including scheduled backups.
Restore gotchas: Wasabi service URLs are regional. During a restore, the bucket location and service URL must match, or otherwise-correct credentials can look broken.

Provider notes

The service URL must match the bucket location.
Storage policies and minimum retention or billing details are provider-side account choices, not Azivault settings.

Provider details can change. Check Wasabi regional service URL docs before creating a production backup plan.

FAQs

Can Azivault back up to Wasabi?

Yes. Azivault can use Wasabi as an S3-compatible backup destination with the bucket, region, endpoint, and access credentials described on this page.

Are files encrypted before they reach the provider?

Yes. Azivault encrypts repository contents locally before repository objects are written to folder or S3-compatible destinations.

What does Azivault's S3 test button check?

For S3-compatible destinations, Azivault writes a small health-check object, confirms it exists, lists the health-check prefix, reads it back, and deletes it.

How do I recover if the original Mac is gone?

Keep the provider account, storage credentials, and Azivault recovery password available. For remote S3-compatible repositories, hydrate or copy the repository objects to a local repository folder before importing it into Azivault.

What Wasabi settings does Azivault need?

Azivault needs the bucket name, the bucket's Wasabi region and matching service URL, plus an access key ID and secret key that can read and write the backup bucket.