A backup policy defines the rules that govern how a device should be backed up: the schedule, how long backups are kept, what type of backup to run, and when to consider a backup missed. Policies are defined centrally in Backups. The policy a job ran under is recorded on the job as it is ingested — the endpoint agent's own runs are keyed by their schedule, not by a policy — and no worker assigns a policy to a device.
⚠️ The third-party vendor path is built but not yet collecting — no tenant has a vendor configured and end-to-end collection has not been proven — so no vendor-fed jobs (and no per-job policy data from a vendor) arrive today.
Policies are the foundation of missed-backup detection. The expected interval you set on a policy is the value the detector compares against each device's last successful job time.
Creating a Backup Policy
- Go to Policies and click New Policy.
- Enter a descriptive name (for example, "Workstations - Daily Incremental" or "Servers - 4-Hour Differential").
- Enter the schedule as a cron expression. The UI validates the expression before saving. Examples:
-
0 22 * * *— daily at 10 PM -
0 */4 * * *— every four hours
-
- Set Retention Days — the number of days backup data is kept. The default is 30.
- Pick the Backup Type:
full,incremental, ordifferential. - Set the Expected Interval in Hours. This is how the missed-backup detector knows when to flag a device. If you run daily backups, set this to 24. If you run every four hours, set it to 4.
- Tick Encryption Required if your compliance posture requires it.
- Save. The policy is now available for assignment.
Schedule Reference
Cron expressions follow standard five-field syntax: minute hour day-of-month month day-of-week. The UI will reject an invalid expression. Use a cron validator if you are not familiar with the format.
| Example | Schedule |
|---|---|
0 1 * * * |
Daily at 1 AM |
0 2 * * 0 |
Weekly on Sunday at 2 AM |
0 */6 * * * |
Every 6 hours |
Retention Settings
Retention controls how many days of backup history is kept. For the workloads the platform captures itself — endpoint files and folders, SQL Server, Active Directory and block-level image — retention is enforced by the platform, not the vendor: each captured object is written to the platform's own object storage and locked there by a per-object retention call made after the upload, and the declarative SLA policy layer derives the retention window and GFS schedule from the Gold/Silver/Bronze SLA you assign. For a connected third-party vendor, enforcement depends on the vendor's own retention configuration — set the retention value to match what you have configured in the vendor so that reports and SLA calculations reflect the correct window.
Expected Interval and Missed Detection
The expected interval is the most operationally important setting. Every fifteen minutes, the missed-backup detector checks every device against its policy's expected interval. If the device's last successful job is older than the interval, Backups:
- Creates a synthetic
missedjob record. - Opens a PSA ticket automatically.
- If the missed window exceeds three times the expected interval, triggers an OnCall page.
Set expected interval conservatively. If a backup normally runs at 10 PM but occasionally runs late, use 26 or 28 hours instead of 24 to avoid false alerts.
Editing and Deleting Policies
- To edit: open the policy and make changes. Existing jobs are not retroactively affected.
- To delete: open the policy and click Delete. The policy is soft-deleted and no longer applied to new devices, but historical job records referencing it are retained.
FAQ
Who assigns policies to devices? Two different things are both called "a policy" here, and only one of them is assigned to a device.
A backup policy (Policies → New Policy) is not assigned to a device by any worker. You define it in Backups, and the policy recorded on a job is the one carried with the job when it is ingested — for the third-party vendor path, that is whatever policy the vendor reports the job ran under. ⚠️ That vendor path is built but not yet collecting, so it feeds no jobs today. The endpoint agent's own runs are keyed by their schedule, not by a policy.
An SLA policy — the Gold/Silver/Bronze SLA you assign on the SLA Policies page — is assigned to devices, either explicitly to one device or by a tag / device-type / org-default rule. That assignment is what derives a device's cadence, retention, GFS counts and backup window.
Can I have more than one policy active at a time? Yes. Different device types typically use different policies. Create one policy per backup tier; the policy a job ran under is recorded as jobs are ingested (the endpoint agent's runs are keyed by schedule). ⚠️ There is no vendor-driven policy-to-device mapping today — the third-party vendor path is built but not yet collecting.
Does changing the expected interval affect current alerts? The change takes effect on the next detector run (within fifteen minutes). Existing alert events already in the log are not changed.