Schedule Policy Editor

This tab defines reusable schedule policies. A schedule policy is a named time-window configuration that controls when vault copy jobs are allowed to run.

You create a policy once here, then assign it to a protection group on the Source Data Protection Group Config tab. In Vault Mode the vault agent uses the policy assigned to each group to decide when to start its syncs.

Overview

Copy jobs do not run continuously. Each protection group has one assigned schedule policy that defines a single daily (or N-day repeating) time window.

Inside the window, the vault agent opens the vault and starts the group's sync. The sync copies every change window that is ready.

When the window closes, no new scheduled sync starts until the next window. A sync that is still running keeps running, and the vault stays open, until its jobs finish or the Sync Time Limit (default 24 hours) is reached. After the limit, the vault agent closes the vault and re-adopts the jobs.

A policy describes one time window per recurrence: start hour, start minute, duration, and how often (in days) the window repeats.

Planned Sync Time

Where in the window the jobs start depends on the Planned Sync Time setting (Vault Operations > Vault Data Sync Dashboard > Settings).

• Random within window (default): a random moment inside the window, different every window. This also spreads load across the fleet.
• Window start: the jobs start at the window start. If that start is missed, for example because the vault agent is down or the console is not reachable, it is retried every 5 minutes until the window ends. After that, the window is skipped until the next one.

Policy fields

Field	Description
Policy Name	A unique identifier used to reference the policy when you assign it to a group. Choose a descriptive name such as Nightly 2h or Weekend Wide.
First Sync Date	The first day the policy syncs. Later run days follow every Repeat Every days from it.
Window Start Time (UTC)	When the window opens on every run day, in UTC.
Window Duration (hours, 1–12)	How long the window stays open after it starts.
Repeat Every (days, 1–30)	The rhythm of the run calendar.

First Sync Date

This field only sets when syncs run, for every group that uses the policy. It does not limit which change windows a sync copies. Each run sends whatever is pending, failed, or abandoned.

For example, with First Sync 30 Sep at 01:15 and Repeat Every 2 days, the first sync starts on 30 Sep at 01:15 and copies the pending change windows. Each later run copies what is new since the previous one.

Window Start Time

The time is in UTC. Every VM syncs to NTP and runs in UTC. For example, 22:30 opens the window at 22:30 UTC.

Both the hour and minute are used exactly as typed. Your browser's time zone does not change them. Use the minutes to spread fleet-wide load across the hour, rather than having every group fire on the exact hour mark.

Window Duration

The duration must be between 1 and 12 hours. Pick it from the list. The console rejects any other value.

A duration of 4 starting at 22:00 keeps the window open from 10:00 PM to 2:00 AM the next day.

The window does not limit how long a sync runs, so a longer window adds nothing. The limit also keeps each run day's window clearly apart from the next one, even for daily runs.

Repeat Every

The policy syncs on the First Sync date and then every N days from it. Run days equal the First Sync date plus k × N, always at the window start.

• 1 means every day.
• 3 means every 3 days.
• 7 means weekly.

The run days depend only on the policy, so you always know them in advance. The calendar behaves as follows:

• A sync that fails is retried twice more in the same run, 1 minute apart. It is not retried the next day. The next run is on the next calendar day.
• A run day that does not sync at all is not caught up the next day. This happens when the vault agent, the vault, or the console is down for the whole window.
• A day with nothing to copy, or one blocked by Eyeglass, does not change the calendar.
• Change windows that were abandoned after 3 failed attempts (CV-114) are sent again at every run day, with 3 new attempts.
• Changing the First Sync date or Repeat Every restarts the calendar from the new date.

When a run day does not sync, alarm CV-117 — CyberVault scheduled sync did not run tells you. The alarm clears itself at the next scheduled start.

Policies are shared. Every protection group that uses a policy syncs on the same days. To spread load, give groups different policies or different First Sync dates.

Editor preview

Before you save, the editor shows a helper box that confirms the window. The text depends on the Planned Sync Time setting:

• With Random within window: "Jobs will start randomly between HH:MM and HH:MM"
• With Window start: "Jobs will start at HH:MM (a missed start is retried until HH:MM)"

The box then lists the next run days, for example "Runs on Thu 1 Oct, Sun 4 Oct, Wed 7 Oct …".

Each policy row in the list shows its first sync date and the next run day. A run day whose window has already ended is not shown as next. After today's window, the row moves to the following run day. While an overnight window is still open, the run day it started on is still the next one.

Workflows

Create a schedule policy

1. Click New Policy in the Sync Schedules tab toolbar.
2. Enter a unique Policy Name.
3. Set First Sync Date and Window Start Time.
4. Set Window Duration (hours).
5. Set Repeat Every (days).
6. Click Create Policy.
7. Go to the Source Data Protection Group Config tab, open the protection group's edit form, and set Schedule Policy to this policy's name.

Adjust the copy window for a busy period

1. Identify the policy assigned to the affected protection group. It is visible on the Source Data Protection Group Config tab, in the group edit form.
2. Edit the policy and update the First Sync Date, Window Start Time, duration, or Repeat Every. The preview shows the new run days.
3. Click Update Policy.

The change takes effect on the next dispatch evaluation. Jobs that are already dispatched are not interrupted.

Switch a group from daily to weekly

1. Either create a new policy with Repeat Every set to 7, or edit the existing policy and change the value.
2. If you created a new policy, assign it to the protection group on the Source Data Protection Group Config tab.

Jobs that are already in flight are unaffected. The next dispatch evaluation uses the new cadence.

Deleting a schedule policy

Each policy card shows Used by N groups · M configs:

• groups: protection groups assigned to this policy (Edit Group > Schedule Policy). A group's policy is the schedule its syncs follow. A group with no policy selected uses the Default policy and is counted there.
• configs: copy policies whose own schedule setting points at this policy. That setting does not drive any sync, because the group's policy does, so it only matters for display.

warning

A policy that any protection group uses cannot be deleted.

When you click Delete, the console shows how many groups use the policy and refuses the delete. The message names the groups.

To delete the policy:

1. Assign each of those groups to another schedule policy (Edit Group > Schedule Policy).
2. Delete the policy.

This is deliberate. Moving the groups to another policy automatically would silently change when their vaults open and sync.

Once no group uses the policy, deleting it moves any copy policies (configs) that still point at it to the Default policy. The confirmation says how many. A green banner above the list confirms the delete and the number of configs moved. The same rule applies to the AI assistant's delete_sync_schedule_policy tool.

The Default policy

The Default policy is named Default (11pm, 2h). It runs every day at 23:00 with a 2-hour window. It cannot be edited or deleted.

A group whose policy no longer exists is also scheduled on the Default policy, on the dashboard and by the vault agent. The group is counted on the Default policy's card. The console log shows this warning for it:

references missing schedule policy

Assign such a group to the policy you want.

How policies drive dispatch

Vault Mode

The vault agent receives the policy through the encrypted heartbeat (QTP) and runs its own scheduler locally. Scheduling is local to the vault agent. The sync itself needs the console. If the console is unreachable, the vault stays closed and the window is retried.

The scheduler checks every 30 seconds whether a group's planned sync time has come. It also:

• Syncs once per window. Failed windows are still retried.
• Keeps a window that crosses midnight open until it ends.
• Follows the policy's run calendar (First Sync date + k × Repeat Every), computed by the vault agent in UTC.

Preparation Mode

Nothing is started on a schedule in Preparation Mode. Start syncs with Sync Group Now, or a bucket's Sync All, on the Vault Data Sync Dashboard.

The console still uses the policy to show a group's next window on the dashboard.

Tips

• Policies are shared resources. Editing a policy affects every protection group that references it. If a subset of groups needs different timing, create a separate policy for them.
• Hours and minutes are interpreted in UTC. All VMs sync to NTP and run in UTC. Clock drift places changes in the wrong window, so confirm NTP sync on the vault agent host before you set critical window start times.
• Use the minute field at scale. Staggering multiple groups across a single hour avoids a thundering herd where every group fires at :00.
• The window length does not limit how long a sync may run. A sync that started in the window runs past the end of the window, until its jobs finish or the Sync Time Limit (default 24 hours) is reached.
• With Window start, the length only sets how long a missed start is retried. With Random within window, it is also the range the start time is picked from.
• The Source Data Protection Group Config > Distribution Planner dialog can create staggered policies and groups in one operation when you bootstrap a large source inventory.
• A policy used by a protection group cannot be deleted. Move the group to another policy first. See Deleting a schedule policy.