Feature
S3-compatible backup for Mac
Azivault backs up selected Mac folders to Amazon S3 and compatible object-storage providers while keeping the repository encrypted, provider-independent, and recoverable through Finder or the azi command-line tool.
Last technically reviewed: July 10, 2026.

What S3-compatible backup means
Amazon S3 defines a widely implemented object-storage API. Third-party services reproduce enough of that API to accept S3-style authenticated requests, buckets, object keys, uploads, listings, reads, and deletes.
Compatibility is not perfect uniformity. Providers can differ in endpoint format, region handling, path-style requirements, object-lock support, multipart behavior, consistency, pricing, and lifecycle rules. “S3-compatible” describes a protocol family, not an identical service contract.
Azivault supports Amazon S3 and custom S3-compatible endpoints through one provider family. Google Drive, Dropbox, SFTP, and other non-S3 backends are not currently first-class destinations.
How Azivault writes a repository to object storage
Folder and S3-compatible plans share the same repository format. S3 is not a separate proprietary cloud backup format.
The local repository or cache remains the control plane for catalog metadata, Finder restore browsing, and CLI operations. During backup, changed encrypted blobs can upload directly to remote storage without retaining a full duplicate of every remote blob locally.
Immutable content-addressed blobs use create-if-absent behavior. Mutable repository metadata is mirrored after the local catalog update succeeds. The catalog must not reference an object until its upload or validation has succeeded.
Are files encrypted before upload?
Yes. Azivault compresses and encrypts file content locally with authenticated AES-256-GCM containers. Current file and directory paths are encrypted in catalog rows and checkpoint manifests.
The provider receives repository objects, not a plaintext mirror of the selected Mac folder. Provider TLS still protects requests in transit, while repository encryption protects stored content from the provider or anyone who obtains the raw bucket objects without recovery material.
Encryption does not prevent deletion by a credential or account with destructive permissions. Provider access control, MFA, bucket policy, versioning, retention, and object lock remain separate considerations.
What settings does an S3 backup need?
An Azivault S3-compatible plan needs:
- A provider account and bucket.
- The bucket name.
- A matching region or provider-specific region value.
- A custom endpoint for third-party services when required.
- An access key ID and secret access key.
- Path-style behavior compatible with the provider.
Use the provider’s current documentation rather than copying settings from a different service. A region mismatch or incorrect endpoint can produce authentication errors that look like bad credentials.
Amazon S3 versus a custom endpoint
For Amazon S3, standard AWS endpoint and virtual-host behavior is usually appropriate. For services such as Cloudflare R2, Wasabi, Backblaze B2, MinIO, Tigris, or a self-hosted deployment, enter the provider’s documented S3 endpoint and region behavior.
Azivault uses SDK-free URLSession requests with AWS Signature Version 4 signing. Standard AWS requests use virtual-host addressing; custom endpoints can use path-style requests when that is the compatible form.
Virtual-host and path-style requests
Virtual-host style places the bucket in the hostname, such as bucket.s3.region.amazonaws.com. Path style places the bucket in the URL path, such as storage.example.com/bucket/object.
AWS generally uses virtual-host style. Custom services, local MinIO deployments, TLS certificates, DNS arrangements, or reverse proxies may require path style. Azivault’s effective path-style selection accounts for custom endpoints rather than assuming every provider behaves like AWS.
Credentials and least privilege
Create credentials specifically for backup rather than reusing a root or broad administrative key. The plan needs enough access to test and operate its repository: write objects, confirm them, list the relevant prefix, read objects for restore, and remove temporary health-check data.
Scope credentials to the backup bucket or prefix when the provider supports it. Store account recovery separately, enable MFA, rotate exposed keys, and document which Mac plan owns the repository.
Azivault stores S3 secrets in Keychain rather than repository metadata. The portable repository must not contain access keys, secret keys, bearer tokens, or signed URLs.
What the connection test verifies
A useful S3 test must prove more than authentication. Azivault writes a small health-check object, confirms it exists, lists the health-check prefix, reads the object back, and deletes it.
That sequence catches common policy gaps where credentials can list but not write, write but not read, or create objects that cannot be cleaned up. Passing the test does not prove long-term account billing, lifecycle, retention, or every large-upload behavior.
Upload cancellation and multipart cleanup
Single-object uploads should be absent or visible as complete objects. Multipart uploads are not normal objects until completed, but uploaded parts may remain billable after interruption.
Azivault checks cancellation before remote writes and does not blindly retry cancelled S3 operations. Configure provider lifecycle rules to abort incomplete multipart uploads after a reasonable period. Do not use a broad lifecycle expiration rule that deletes completed repository objects merely because they are old.
Storage pricing and restore costs
Object-storage bills can include capacity, write requests, list requests, retrieval, and egress. Some providers include egress or use minimum-storage-duration rules. Others price requests or downloads separately.
Estimate:
- Initial selected-folder size.
- Monthly changed data.
- Expected retained history.
- Request volume from many small files.
- Cost and time to download the full repository during an emergency.
The cheapest stored gigabyte is not necessarily the cheapest tested recovery.
Finder restore from S3-compatible storage
Finder browsing uses local catalog metadata. When requested file content is not cached locally, the app-owned restore service fetches the missing encrypted blob from S3-compatible storage, validates and decrypts it, and materializes a temporary readable file for Finder.
This design avoids presenting the remote bucket as a normal filesystem and preserves the repository contract. Remote restore currently exists for S3-compatible storage; future provider families would need equivalent object and restore-fetch implementations.
Recovering after the original Mac is gone
Keep the provider login, bucket, endpoint, region, credentials or credential-recovery route, and Azivault recovery password outside the original Mac.
The azi CLI can hydrate an S3-compatible repository to a local folder. After hydration, use verify, list-runs, search, restore, or export with recovery material. Hydration rebuilds a local recovery surface; it does not turn the remote bucket into a directly browsable plaintext tree.
Which S3-compatible provider should I use?
Choose based on region, durability, account recovery, pricing, egress, API compatibility, support quality, object-lock requirements, and your willingness to manage credentials.
Azivault provides setup guides for Amazon S3, Backblaze B2, Cloudflare R2, Wasabi, MinIO, and Tigris. Provider pages should be checked against current vendor documentation before configuration.
S3 backup limitations
Azivault is younger and narrower than Arq, Duplicati, or restic. It does not currently provide broad non-S3 destination support, bundled hosted storage, web restore, or provider-level immutable backup records.
Use Arq when mature retention, broad providers, Windows support, or supported object-lock workflows matter most. Use a managed service such as Backblaze Computer Backup when you do not want to configure storage at all. Use Azivault when a native Mac app, mandatory encryption, S3-compatible storage, Finder browsing, and documented CLI recovery are the preferred trade.
Related technical reading
- S3-compatible backup setup guide
- Cloud backup for Mac
- Encrypted backup repositories
- Azivault repository design
FAQs
Can Azivault back up a Mac to Amazon S3?
Yes. Azivault supports Amazon S3 and third-party S3-compatible storage using bucket, region, endpoint, and credential settings.
Are files encrypted before upload?
Yes. Supported Azivault repositories encrypt file contents and sensitive path metadata locally before repository objects are uploaded.
Does Azivault include S3 storage?
No. You create and pay for the provider account and bucket separately.
Can I restore if the original Mac is gone?
Yes, if you retain provider access and recovery material. The azi CLI can hydrate an S3-compatible repository to local storage for verification, search, restore, or export.