BackupZit Files

Recovery point objective (RPO)

Jobs can set how old their newest good backup may get, in hours (job form: Recovery point objective (RPO), hours — e.g. 26 for a daily backup).

• The dashboard shows how many jobs are within RPO and lists every job that missed it; the job page shows the state.
• A notification (email and chat, like a failure) goes out once when a job misses its RPO.
• Unlike the status of the last run, the RPO also catches a schedule removed by mistake, an agent offline for days and a backup that keeps failing.
• REST API: rpo_hours, rpo_met and last_good_backup for jobs; metric backupzit_job_rpo_met.

Check of all stored data

Restore tests read a sample. Now an agent also reads every piece of data in each repository and verifies it, which finds damage on the storage itself (a failing NAS disk, bit rot) before you need the backup.

• Monthly by default, once per repository, the first time a month after its first backup (Settings → Restore tests: monthly, every three months or never).
• Cloud storage (S3, Azure) only when allowed, because the check downloads all data.
• Check data on a job's page starts a check at once. Problems make the Data check run fail and send a failure notification.

Several jobs at once per agent

• New column Jobs at once on the Agents page: an agent may run up to 8 backups and restores at the same time (default 1, as before) — useful for proxy agents of ESXi, Proxmox, Microsoft 365 and NAS shares.
• Two runs of the same job never run at once; agent updates wait until the agent is idle; on Windows VSS snapshots are created one after the other.
• REST API: max_runs for agents.

Fixes

• The restore test settings form kept working only when it sent every field; settings saved from older forms or scripts are kept now.

Data checks and jobs at once need agents 0.39.0 or newer — update them from the Agents page.

Releases are signed with the BackupZit release key; consoles verify them before installing.