Backups and schedules
Jobs and progress
Section titled “Jobs and progress”Every backup run is a job with live progress (items done/total, bytes, an ETA), delivered to the web interface over server-sent events. If the connection drops, Restow reconnects on its own and the list is at most a few seconds stale. A job can be queued, running, completed, completed with issues (some items failed but the run finished), failed or cancelled. Cancelling stops at the next checkpoint; whatever was already stored stays in storage, and the next backup continues from the last completed snapshot rather than starting over.
Failed items are retried automatically on the next run and stay visible with their reason; after three consecutive failures on the same item, Restow raises an alert rather than retrying silently forever.
Three ways to trigger a backup by hand:
- Back up now (per object): continues from the last snapshot; only new and changed items are read (an incremental run).
- Full backup: reads everything again. Deduplication keeps the extra storage small, but it takes longer; use it if you suspect drift, not as routine practice.
- Back up all: queues one job per protected object of the tenant; objects already queued or whose source isn’t connected are skipped, not double-queued.
None of these is actually how most first backups start, though: the moment an object becomes protected (an include, single or bulk, a directory sync finding it newly active, or an IMAP import), Restow queues its first backup automatically, without waiting for a schedule. See First steps.
Schedules
Section titled “Schedules”Nothing runs on its own until a schedule exists. Under Schedules, each one has a kind, a cadence and a scope:
| Kind | What it does |
|---|---|
| Backup | Backs up every active protected object, or one you choose. |
| Verification | Reads back a sample of the latest backup through the restore path and compares it with the manifest; while a verification schedule is on, every new backup is verified too. See How Restow checks that a backup can be restored. |
| Integrity check | Checks stored packs for damage and repairs them from copies; a monthly (or rarer) run checks everything, a more frequent run a sample. |
| Directory sync | Reads users, mailboxes and OneDrives from Entra ID, so newly protected people are picked up by the rules. |
| Retention | Applies retention policies; until one exists, nothing is removed by it. |
Cadence is either a preset (every N minutes/hours, daily, on chosen weekdays, monthly on a day of the month, all at a given local time and time zone) or a raw five-field cron expression, with a live preview of the next runs and a minimum spacing of 15 minutes between them. Apply recommended schedules fills in the ones missing for a tenant in one step.
Restow tells you plainly when protection is incomplete: no backup schedule for all protected objects means backups only happen when someone starts them by hand; no verification schedule means recovery readiness stays permanently unproven, even if backups themselves keep succeeding.
Storage targets and copies
Section titled “Storage targets and copies”A tenant’s backups are written to one primary storage target and, optionally, one or more copy targets that receive the same data at another location: the classic 3-2-1 pattern. Supported target types:
- A server path: the default local volume inside the containers, or a mounted NFS/SMB share. Managed by provider admins only.
- S3-compatible object storage: Hetzner Object Storage, Amazon S3, Wasabi, Backblaze B2, Garage, or another S3-compatible service, with presets that fill in the endpoint/region/addressing for the well-known ones.
Testing a target writes, reads back and deletes a small object (and, for a local path, checks the directory first); an S3 target’s test also detects whether the bucket enforces Object Lock (WORM), relevant mainly once archiving ships, not required for ordinary backup storage. A target can only be promoted to primary after a successful test. Removing a target never deletes data already written there; that’s a separate step at the storage provider if you actually want it gone.
Checking a copy compares its packs, manifests and encrypted keys against the primary and reports what, if anything, is still missing; new backups reach the copy immediately going forward, and the copy job mirrors whatever existed before the copy was added.
Statistics and reports
Section titled “Statistics and reports”Under Statistics, backup outcomes, restores, storage volume and growth, recovery readiness and (for Microsoft 365) throttling waits are shown as trends over a chosen period (7/30/90 days, 12 months, or a custom range), scoped to one tenant or, in the Service Provider edition, across all of them. Export PDF produces a formatted report for the period, the same figures, laid out for filing or handing to a customer; Download as CSV exports the underlying dataset behind a chart. Both are generated server-side; nothing about the installation is sent anywhere else to produce them.
Adding, testing, editing or promoting a storage target, and every scheduled or manual backup, is recorded in the audit log.