Schedule backups

TenuVault can back up each tenant automatically, daily or weekly, at a time you choose. The Schedule tab walks through the three decisions in order:

1. Where backups are stored: encrypted on this device, or in your own Azure storage account (Pro and MSP). Backups never go to a TenuVault server. See Backup storage and retention.
2. What to back up: the tenant’s saved backup choice.
3. Where backups run: on this computer, inside the TenuVault app as you (this page), or in Azure, as a runbook in your own Automation account with a managed identity, so no computer has to be on or signed in (see Cloud backups in Azure). Both runners can be on at once; the tab says so when they are, because each then makes its own backups into the same storage.

This page covers backups on this computer: how to set up the schedule and how to keep TenuVault running so the schedule is met.

How scheduled backups run

• Each tenant has its own schedule: daily or weekly, at a time in your computer’s local timezone. Daylight saving and timezone changes are followed. A time skipped by the spring clock change moves forward by the clock change. A repeated autumn time uses its first occurrence, with one attempt budget for both occurrences.
• Backups run while TenuVault is running, in the window or in the system tray (the menu bar on macOS) after you close the window.
• TenuVault checks the schedules every minute. The first check runs 30 seconds after TenuVault starts.
• If the computer was off or TenuVault was not running at the scheduled time, the missed backup runs once as soon as TenuVault starts again. Only the most recent missed slot runs, not every missed one.
• When several backups are due, they run one after another.
• A failed scheduled backup is retried after 15 minutes, with up to three attempts in the same slot. Each attempt belongs to the slot when it started. After the third failure, TenuVault waits until the next scheduled time. If that time passed during the failed run, it is due at the next check with a fresh attempt budget. A successful backup resets the attempt count. A backup that saved only some policies counts as a failed attempt: the partial backup stays in storage, and the slot is retried.
• A failed attempt does not count toward the three when the backup saved nothing, got no answer from Microsoft Graph or Azure Storage, and every failure was a connection failure or timeout. It is still retried 15 minutes later. A sleeping Mac wakes for a few seconds at a time for network upkeep, and a backup that starts in such a wake cannot connect. These wakes no longer use up the slot: once the network is back, the backup runs at the first check at least 15 minutes after the last failed attempt.
• Saving a schedule never triggers a catch-up backup for slots before the change.
• Each scheduled backup uses the tenant’s saved backup choice. See Choose what automatic backups cover.

When choosing backup frequency as part of an Intune disaster recovery plan, use the planning checklist on the product site.

Set up a schedule

1. Select the tenant in the tenant switcher.
2. Open Backup & Restore and click the Schedule tab. You can also click Set up automatic backups or Edit schedule on the Dashboard.
3. In step 1, check Backups for tenant name go to and use Change storage when the backups should land somewhere else. The same choice exists in Settings; both open the same chooser.
4. In step 3, choose On this computer. Under Automatic backups, tick Back up tenant name automatically.
5. In Repeat, choose Every day or Every week. For a weekly backup, pick the day.
6. In Time, choose the time. The label shows your computer’s timezone, and Upcoming backups on this computer lists the next runs so you can check them before saving.
7. Click Save.

TenuVault confirms with Schedule saved. The new schedule starts at 02:00 by default, and a weekly schedule starts on Sunday.

If the time is empty or invalid, Choose a time, for example 07:45. appears beside Time. Selecting Save moves focus to that field without saving. Your recurrence and weekday stay selected.

To pause automatic backups on any plan, clear the check box and click Save. TenuVault confirms with Automatic backups paused. The saved recurrence, time, weekday and last result are kept. You can pause an existing daily schedule after moving from Pro or MSP to Community. Its recurrence summary stays visible while it is paused. Enabling daily backups again requires Pro or MSP.

Note

Daily backups are part of Pro and MSP. Before the tenant’s plan information has loaded, Checking plan appears beside Repeat. If the license check has returned but no plan is available for the tenant, Plan not verified appears with the license coverage warning. Daily backups are unavailable in both cases. On Community, Repeat offers Every day (Pro) as an unavailable option and you schedule weekly backups.

If a schedule is saved and the background runner is not installed, the summary shows: Background restart is not installed. Backups run while TenuVault is running. Under Background runner, use Settings > Background runner to open Settings, then select Background runner to manage automatic restarts.

On Community, when a saved or selected weekly schedule is enabled, the editor shows a muted line: A weekly schedule can leave up to six days of changes unprotected. Daily backups are included in Pro. The line has no button and is hidden when no weekly schedule is enabled.

The Status panel

Next to the schedule, Status shows:

Field	What it shows
Scheduled backups run as	You (your sign-in), or the read-only Backup Reader when one is verified for the tenant, with its last reader run or certificate expiry and a link to its settings
Next backup	When the next automatic backup on this computer runs, or Not scheduled
Last automatic backup	When the last successful attempt on this computer ran and its result message. After a failure, the label changes to Last automatic backup attempt failed and shows the failed attempt’s time and message. After a cancelled attempt, it changes to Last automatic backup cancelled, in a neutral tone.
Backups are stored	The tenant’s storage location from step 1.
Cloud backups (Azure)	When cloud backups are set up: their Azure schedule and how the last cloud run ended, reported by the runbook into the backup container.
Kept for	How long backups are kept. See Retention.
Not backed up because of the license	Recent automatic backups TenuVault refused to run, with the time, whether they were scheduled or started from the menu bar or tray icon, and the reason

Choose what automatic backups cover

In step 2, What to back up holds the tenant’s saved backup choice: Everything except apps, Everything or Custom. It is “Used by automatic backups (on this computer and in Azure) and “Back up all tenants now”, and preselected when you run a backup by hand.” For cloud backups it is copied into the setup command, so run the cloud setup again after changing it.

1. Choose the option, or with Custom tick the areas and types to include.
2. Click Save.

A tenant that never saved a choice uses Everything except apps, shown as “(default)”. See What gets backed up for the types in each area.

License and plan checks

Before every automatic backup, TenuVault checks that:

• your license covers the tenant
• the plan includes daily backups, for a daily schedule
• the plan includes Azure storage, when the tenant’s backups go to an Azure storage account

If a check fails, the backup does not run. TenuVault shows a notification, records the refusal under Not backed up because of the license and shows “Not backed up:” with the reason as the schedule’s last result. When the tenant is not licensed, the Schedule tab also says “Your license does not cover” the tenant “right now, so its automatic backups do not run.”

Refusals are kept on this device, not in the tenant’s audit log, because the tenant’s storage is not opened without a license. TenuVault keeps the 200 most recent refusals across all tenants.

When a scheduled backup fails

• TenuVault shows a notification: “Scheduled backup of tenant failed”, with the reason. A backup started from the tray uses “Tray backup of tenant failed”. Click either notification to bring TenuVault to the front and open that tenant’s Schedule tab, even if its window was closed.
• If a tray request and a scheduled request overlap for one tenant, they share the running backup. A failure produces one notification, named for the request that started the backup.
• A scheduled backup that fails because Microsoft or the backup storage could not be reached is notified and recorded in the audit log once per slot, not after every retry. Other failures, and backups started from the tray, are notified every time.
• The notification uses the tenant’s friendly name, then its domain, then “this tenant” if neither is available. It does not use the tenant ID as the label. An error message can still contain an ID supplied by the service that reported it.
• The Schedule tab, the Dashboard and the All tenants page show Last automatic backup attempt failed, with the failed attempt’s time. The Schedule tab also shows its result message. A cancelled automatic backup is not a failure: these places show Last automatic backup cancelled in a neutral tone, without Action required.
• On All tenants, the full failure timestamp wraps and Action required appears. Click the failure row to open that tenant’s schedule.
• The Dashboard counts a failed attempt as Failed and in Success Rate, also when it saved no backup. Each run counts once. Retries of one slot that failed because Microsoft or the storage could not be reached, and saved nothing, count once together, also after a restart. Every other retry counts on its own. If the last automatic attempt failed and no backup is stored, the status says “Automatic backup failed before a backup was saved.”
• The result is recorded in the tenant’s audit log as “Scheduled backup”.
• Next backup shows the retry time. Retries wait 15 minutes after a failed run, with a maximum of three attempts per slot, including the first run. After three failures, the next attempt is at the next scheduled time. Failures that saved nothing, got no answer from Microsoft Graph or Azure Storage and only hit connection failures or timeouts are not counted, but their retry still waits 15 minutes. Retry state is saved before each attempt, so a restart during a backup does not reset the budget. Only a successful backup advances the last successful run time.

If Microsoft Graph or the backup storage returns the same 401 or 403 response five times in a row, the backup stops early with the message that names the role to check, instead of working through every remaining policy. A successful request starts the count over.

Requests that stop responding time out after 90 seconds, including token acquisition, response reads and Azure uploads. Each request has at most three attempts. Connection failures and temporary service responses such as 429, 503 and Azure ServerBusy wait one second before the second attempt and two seconds before the third, unless the server requests a longer pause. Graph throttling pauses all readers for the server’s requested interval. Storage requests also honour Retry-After and Azure retry delays, up to five minutes. A longer interval fails the request. If an upload loses its response and a retry is refused, it counts as saved only when the stored content matches the intended backup.

Every backup has a 30 minute deadline, including retention cleanup. An item read or upload that still times out after three attempts is listed as a policy warning; other policies are saved and the summary records CompletedWithWarnings when at least one was saved. Token acquisition, policy listing and manifest commit timeouts still fail the job. Reaching the deadline before the manifest PUT starts fails with a clear reason and releases the tenant for later backups. Once the PUT starts, its retries can finish despite cancellation, but requests and retry waits stop no later than two minutes after the job deadline. An unfinished commit then fails with the job deadline message. A successful commit remains completed, so the schedule does not spend an attempt creating a duplicate. Retention stops at the deadline and reports “Retention was interrupted; older backups are cleaned up on the next run” only when retention is enabled (more than zero days), every selected item was saved and cancellation or expiry interrupted retention. Runs that never attempt retention do not report that warning. The next scheduled tenant can then run.

To stop a backup you started or joined, select Cancel backup beside its running progress. The first-backup screen and the progress dialog offer the same action. Cancellation before the manifest PUT starts records Cancelled with “Backup cancelled by you. This run is never offered as a complete backup.” A timed-out run that stops before committing, after it claimed its backup folder, records the folder as a failed backup: Backup History lists it as Failed with the policies it saved, and retention removes it once it is older than the retention period. A cancelled run records it as cancelled instead: Backup History lists it as Cancelled in a neutral tone and, like a failed backup, never uses it as a complete backup. The Dashboard counts it in the backups in storage but not as successful or failed or in Success Rate. Folders without a manifest, for example from a run that stopped when TenuVault was closed, are left in place regardless of age, including those with an ownership marker. A cancelled automatic job sends no failure notification, does not consume the retry budget and waits until the next scheduled slot. Cancellation during or after a successful commit keeps the job completed and reports the retention interruption warning only under the conditions above. You can start another backup without restarting TenuVault.

When Microsoft Graph or backup storage stops responding during a backup, the backup stops within a few minutes and is retried under the schedule rules above. Successful requests to one service do not reset repeated failures from the other. If removing old backups fails, cleanup stops and the saved backup remains completed with a warning. Old backups that were not removed are reconsidered on the next run.

If your sign-in has expired or Conditional Access requires you to sign in again, the backup fails and a banner at the top of the TenuVault window asks you to Sign in. Scheduled backups never open a sign-in window by themselves. When a sign-in frequency policy ends your session every night, see Conditional Access and TenuVault, add the optional Backup Reader on Pro and MSP, or move the schedule to cloud backups in Azure. The Sign-in at night section of the computer runner says which of these this tenant uses.

Keep TenuVault running

Scheduled backups only run while TenuVault runs. Three settings help with that. They apply to all tenants and are saved right away.

In Settings > Background runner, these labels say menu bar on macOS and tray on Windows. The Schedule tab uses tray on both platforms.

Keep running in the menu bar or tray

Keep running in the menu bar/tray when I close the window is on by default. Closing the window then hides it, and TenuVault keeps running in the system tray (Windows) or the menu bar (macOS). The first time, a notification says “TenuVault is still running”.

When this setting is off, closing the window quits TenuVault on Windows.

The menu bar or tray icon

Click the menu bar icon on macOS or the tray icon on Windows to open TenuVault. Its menu has:

Item	What it does
Open TenuVault	Shows the window
Back up all tenants now	Backs up every connected tenant one after another with its saved backup choice. The license and plan checks above apply.
Next backup:	The next scheduled backup across all tenants, or No scheduled backups
Quit TenuVault	Quits the current app process and stops scheduled backups. When background launch is installed, the operating system may reopen TenuVault within five minutes. To stop restarts completely, select Settings > Background runner > Remove background launch and turn off Start TenuVault in the menu bar/tray when I sign in to this computer before quitting.

Backups started from the menu bar or tray icon are shown as From tray in the backup history.

Start at login

Start TenuVault in the menu bar/tray when I sign in to this computer opens TenuVault in the menu bar on macOS or the tray on Windows, without a window, when you sign in to your computer. It is off by default.

You find both check boxes on the Schedule tab under Background runner, and in Settings under Background runner.

Background launch

Background launch registers a task with your operating system that starts TenuVault in the menu bar on macOS or the tray on Windows when you sign in to the computer, and again every five minutes. If TenuVault is not running, it is reopened there within five minutes. Background launch is available in installed Windows and macOS builds.

1. Open Settings and go to Background runner.
2. Under Restart TenuVault for scheduled backups, click Install background launch.

Windows

TenuVault creates a Task Scheduler task for your user account, named TenuVault Background followed by your account’s security identifier. It runs at logon and every five minutes, with your normal (limited) rights. No password is stored.

macOS

TenuVault installs a LaunchAgent for your user account that runs at login and every five minutes and opens TenuVault in the background. No password is stored.

If TenuVault is already running, the task does nothing: TenuVault runs only once.

Background launch has limits:

• It runs only while you are signed in to the computer. It does not run while you are signed out, or while the computer is asleep or off, and it does not wake the computer.
• Backups still need a valid Microsoft sign-in, a license that covers the tenant and available storage. It does not bypass MFA, Conditional Access, licensing or storage access control.
• It does not guarantee a backup at the exact scheduled minute. The missed backup runs when TenuVault starts.
• If you move the TenuVault application, install background launch again.

To stop automatic restarts, open Settings > Background runner, click Remove background launch and turn off Start TenuVault in the menu bar/tray when I sign in to this computer before you quit. Removing background launch leaves your schedules unchanged and does not stop a backup that is running.

Plan requirements

Feature	Community	Pro	MSP
Weekly automatic backups	Yes	Yes	Yes
Daily automatic backups	No	Yes	Yes
Automatic backups to your Azure storage account	No	Yes	Yes
Cloud backups in your own Azure Automation account	No	Yes	Yes
Menu bar or tray, start at login, background launch	Yes	Yes	Yes

Related pages

• Set up and schedule Microsoft Intune backups: the setup guide, on the product site