Azivault

Feature

Encrypted backup repositories for Mac

Azivault encrypts backup contents and sensitive path metadata on the Mac before repository objects are written to local, network, external, or S3-compatible storage.

Last technically reviewed: July 10, 2026.

Azivault encryption settings showing a generated recovery password and iCloud Keychain option

What an encrypted backup repository protects

A backup repository contains more than file payloads. Names, directory hierarchy, timestamps, run records, and destination metadata can reveal sensitive information even when file contents are encrypted.

Azivault’s supported repository format protects the file payload and current relative-path metadata. File contents are compressed and sealed in authenticated chunks. File and directory paths in catalog rows and checkpoint manifests are encrypted. Keyed path identifiers allow lookup and differential comparison without storing the plaintext name as the index key.

Repository history deliberately excludes plaintext credentials, recovery passwords, repository keys, security-scoped bookmarks, bearer tokens, and local absolute paths.

How file encryption works

Azivault uses AES-256-GCM authenticated encryption through Apple’s CryptoKit APIs. File content is processed in bounded chunks so a large file does not need to exist entirely in memory. Each chunk is compressed before encryption, and structural fields such as the chunk index and final-chunk marker are authenticated as additional data.

Authenticated encryption matters because privacy is not enough. Restore and verification must also detect a modified header, corrupted ciphertext, incorrect authentication tag, or object that no longer matches the expected repository identity.

Repository keys and recovery passwords

The repository key encrypts repository content. The recovery password does not become the file-encryption key directly. Instead, Azivault derives password key material with PBKDF2-HMAC-SHA256 and uses it to wrap the repository key with AES-256-GCM.

That separation allows the app to retrieve the repository key through Keychain for normal operation while preserving a portable password-based recovery path in repository metadata. The repository stores the wrapped key and algorithm parameters, never the plaintext repository key or password.

New plans can generate a strong recovery password and default to synchronizing the repository key through iCloud Keychain, with an explicit local-only option. Keep the recovery password somewhere reachable without the Mac being backed up.

Is iCloud Keychain required?

No. iCloud Keychain is a convenience and recovery route, not the repository format. You can choose local-only Keychain storage and retain the recovery password separately.

If another Mac has access to the synchronized Keychain item, Azivault may unlock an imported repository without asking for the password. If Keychain is unavailable, the recovery password unwraps the same repository key.

Are filenames and folder names encrypted?

Yes. Current repository catalog rows and checkpoint manifests encrypt relative paths. This prevents a storage provider or someone holding an external disk from casually reading project names, client names, or folder hierarchy from repository metadata.

Some operational metadata necessarily remains visible, including the repository format version, encryption algorithms, object layout, and identifiers required to locate repository objects. Encryption protects content and sensitive names; it does not make the existence or approximate size of a repository secret.

Encryption at local, NAS, and cloud destinations

The same repository format is used across folder and S3-compatible destinations. Azivault does not switch to a provider-specific backup format when data moves offsite.

Destination security still matters. Use provider MFA, scoped credentials, reliable storage, and access controls. Encryption limits what storage possession reveals, but it does not stop an attacker with deletion rights from destroying objects.

Can encrypted backups be verified?

Yes, but meaningful verification requires recovery material. Checking only that ciphertext files exist cannot prove that their authentication tags and encrypted contents are readable.

The azi CLI accepts recovery material to verify encrypted blobs and checkpoints, list and search encrypted paths, restore selected files, or export completed runs. Prefer a password file or environment variable instead of putting the recovery password directly in shell history.

What happens if the app is unavailable?

Azivault treats the repository format and CLI as part of the recovery contract. The documented format identifies algorithms, object layout, catalog behavior, and recovery wrapping. The CLI can inspect, verify, search, restore, and export without relying on the main graphical interface.

This does not eliminate every dependency: you still need compatible recovery software, access to the repository, and the correct recovery material. It does reduce dependence on one UI and one Mac installation.

What encryption does not solve

Encryption cannot repair missing objects, expired provider accounts, forgotten passwords, incorrect retention, or a backup that never completed. It also does not provide provider-level object lock. Azivault currently lacks the immutable backup-record support that mature products such as Arq can use with compatible storage.

A complete design combines encryption with independent credentials, monitored backup runs, storage durability, intentional retention, and regular restore tests.

Test the encrypted recovery path

  1. Complete the first backup run.
  2. Reveal the run through Finder and restore one file to a temporary folder.
  3. Verify the restored file opens and matches the expected version.
  4. Confirm the recovery password is stored outside the protected Mac.
  5. Use azi verify with recovery material for an independent repository check.

FAQs

Are Azivault backups encrypted by default?

Yes. Encryption is mandatory for supported Azivault repositories created by the app.

Are filenames encrypted in an Azivault backup?

Yes. Current repository catalog rows and checkpoint manifests store encrypted file and directory paths rather than plaintext names.

What happens if I lose the recovery password?

A Keychain-held repository key may still unlock the backup. If every copy of the repository key and recovery password is lost, the encrypted repository cannot be recovered.

Can I verify an encrypted repository without decrypting files manually?

Yes. Azivault and the azi CLI can verify authenticated encrypted repository objects when supplied with valid recovery material.