Feature

Automatic Mac backups

Azivault schedules encrypted backups for selected Mac folders through a bundled background helper. The main app can close, while schedule state, permissions, credentials, storage availability, and macOS policy determine when a due run can actually start.

Last technically reviewed: July 10, 2026.

Azivault backup plan screen showing the selected folder, storage, schedule, and recent activity

What automatic backup means on macOS

Automatic backup is not merely a timer inside an open window. A Mac application needs an approved background execution path, durable access to sandboxed folders, access to repository keys and provider credentials, and a policy for missed or blocked runs.

Azivault bundles a login-item helper named Azivault Scheduler. It owns the menu-bar status item and scheduled execution while the main UI is closed. Plan state is shared through the app group rather than inferred from paths or an open document.

System-managed and exact-time schedules

Azivault supports two scheduling modes.

System-managed scheduling is the default. You choose an hourly, daily, or weekly cadence. Azivault registers background activity and macOS chooses the precise opportunity based on system conditions. This is appropriate when regular execution matters more than a specific minute.

Exact-time scheduling records a requested time. The helper uses its due-run timer while available. Exact time is a preference, not a promise that a sleeping or powered-off Mac will wake and run at that exact second.

What happens after a missed backup time?

A due plan is not silently marked complete because its preferred time passed. If the helper launches after a missed due time, it evaluates stored plan state and treats the overdue plan as still due.

Work can remain blocked until required conditions return. For example, an external disk may need to mount, a NAS may need to reconnect, or the Mac may need a logged-in file-provider session before cloud-only source bytes can download.

Once a backup run actually starts, the next schedule advances according to the shared schedule policy. Failures that occur before execution starts should not pretend the scheduled work happened.

Does the Azivault app need to stay open?

No. The main app window can close. The scheduler helper is separately bundled, sandboxed, and registered through macOS background-item services.

macOS may require approval in System Settings. If the background item is disabled or rejected, scheduled work cannot run. Existing repositories remain restorable because background backup permission and read-only recovery are separate capabilities.

How automatic backups access selected folders

A sandboxed helper cannot rely on a stored path such as /Users/name/Documents. During plan creation or folder reconnection, Azivault creates separate security-scoped bookmarks for scheduled source and folder-destination access.

The helper requires those approved bookmarks and does not fall back to direct stored paths. This is safer, but it means moving, replacing, or reformatting a source or destination can require explicit reconnection.

Repository keys and S3 credentials required for unattended work use a shared Data Protection Keychain access group. Recovery keys remain purpose-specific and can retain stronger user-presence protections.

Automatic backups to external disks

An external disk must be attached, mounted, and reachable through the saved bookmark. A laptop cannot write to a disk left at a desk, and a schedule cannot make unavailable hardware appear.

Use external storage for fast local recovery, but avoid treating a disk stored beside the Mac as the only backup. Theft, fire, water, or one damaged bag can remove both copies.

Automatic backups to a NAS or network drive

A NAS or network share must be mounted or otherwise reachable under the configured access path. Wi-Fi, VPN, credentials, server availability, share names, and filesystem permissions can all block a due run.

The scheduler should report the blocked condition rather than advancing the plan as if it completed. Reconnect the destination after server migrations or share-path changes, then run a manual verification backup.

Automatic S3-compatible backups

S3-compatible plans require network availability, a valid bucket, endpoint and region settings, scoped credentials, and an active provider account. Azivault uploads changed immutable blobs with create-if-absent behavior and mirrors mutable repository metadata only after the relevant local catalog work succeeds.

Cancellation is checked before remote writes, and cancelled S3 operations are not blindly retried. Multipart uploads can leave provider-billable parts on some services, so provider lifecycle rules should clean incomplete multipart uploads without deleting completed repository objects.

Cloud-only files during unattended runs

iCloud Drive and other file providers can leave dataless placeholders on disk. New Azivault plans default to downloading only cloud-only files that appear new or changed. Unchanged placeholders reuse the previously backed-up object.

Materialization depends on the provider process in the logged-in user session. At the login window, a provider may not download file contents. Choose whether the plan should report, skip, or download changed cloud-only files, and understand that skipping them makes the repository intentionally incomplete for those items.

Azivault cannot run while the Mac is powered off. Sleep and macOS background policy may delay work. Laptop power rules can also block execution to avoid unexpected battery use.

An exact-time label should therefore be read as a preferred due time. If minute-level execution is operationally critical, use an always-on Mac with stable power, network, destination access, and a monitored schedule—then test the behavior under the actual deployment conditions.

Subscription access and automatic runs

The helper refreshes entitlement state before starting due work. Active trial, subscription, or applicable grace access permits new backup runs. Expired access blocks scheduled and manual backup creation.

Restore remains available for existing repositories. This separation matters: billing state should stop new writes without holding previously created backup data hostage.

How to confirm automatic backup is working

Create a plan with a small test folder and appropriate schedule.
Approve the Azivault background item if macOS requests it.
Close the main app and change a test file.
Allow the plan to become due.
Check the menu-bar status and recent activity for a completed run.
Reveal that run in Finder and restore the changed file to a temporary folder.
Repeat after changing storage, credentials, permissions, or schedule settings.

The restore is the important step. A timer firing proves scheduling; a successful restored file proves scheduling, access, encryption, repository commit, and recovery worked together.

Automatic backup or continuous sync?

Azivault creates scheduled repository history. It is not a real-time bidirectional sync engine. If the goal is immediate collaboration or the same current file on several devices, use a sync service. If the goal is recovery from deletion, bad edits, ransomware, or device loss, preserve independent completed backup runs.

FAQs

Can Azivault back up automatically when the main app is closed?

Yes. The approved Azivault Scheduler login-item helper evaluates due plans and runs backups while the main app UI is closed.

Does an exact-time backup always start at the exact minute?

No. Sleep, power, login state, macOS scheduling, permissions, network access, and destination availability can delay execution. An overdue plan remains due.

Can automatic backups run when a Mac is powered off?

No. The Mac and required storage or network services must be available.

What happens to scheduled backups after a subscription expires?

New backup runs require active access. Existing backups remain available for Finder and CLI restore.