Disaster Recovery
Nightly organization backups to your own storage, on-demand backup and download, and restoring from a backup file.
What it is
Disaster recovery takes a complete copy of your organization — projects, conditions, action sets, rule sets, and tests — and writes it somewhere you control. You can put that copy on a nightly schedule, take one on demand, download one to your own machine, and restore an earlier copy back into the organization.
Tenant backup and restore are included with the Enterprise plan. Below Enterprise, the screen shows a short notice instead of the form, and no scheduled backup runs for the organization. Individual rule sets can still be rolled back from their own version history, which is a per-rule-set feature and available on every plan.
This is an operational backup: something you restore from when you need the organization’s content back. It is a different thing from the compliance archive, which is a tamper-evident record of what happened and is never restored from.
Scheduled backup
With the schedule enabled, the entire organization is written to your storage container every night at 03:00 UTC. The destination is a container you own, so the backup lives in your storage account under your own retention and access rules, not ours.
Setting it up takes three fields:
| Field | What it does |
|---|---|
| Nightly backup | Turns the 03:00 UTC schedule on or off. It cannot be turned on until a destination is saved. |
| Container SAS URL | The destination container, entered as a secret. It needs create-and-write permission on that container. |
| Path prefix | Optional. A folder inside the container, so one container can hold backups for more than one organization. |
Fill in the destination, choose Save destination, then turn the nightly backup on.
Once saved, the URL is never returned by the server, so the field shows a masked placeholder rather than the real value. Leaving it as is keeps the stored URL untouched; pasting a new one replaces it. That is what you do when the SAS token is about to expire or you are moving to a different container.
Disabling the nightly backup keeps the saved destination in place, so you can pause and resume the schedule without re-entering credentials.
Status
The status area reports on the backup destination and the most recent attempt:
- Destination - a safe preview of the configured container with no token visible, or Not configured.
- Last succeeded - when a backup last completed.
- Last attempted - when a backup last ran, whether or not it worked.
- Last file - the name of the most recent backup file, when one is available.
When the two timestamps disagree, the last attempt failed, and a warning banner shows the error reported by the storage account — usually an expired SAS token, a token without write permission, or a container that no longer exists.
Run backup now triggers a backup immediately. Use it right after you save a destination: it confirms the credentials and permissions actually work instead of leaving you to find out at 03:00.
This screen shows the latest attempt only — last succeeded, last attempted, last error, last file name. There is no list of past backups to browse and no retention setting to configure. Older backup files live in your own container, so how long they are kept and how they are pruned is governed by your storage account’s own lifecycle rules.
Downloading a backup
Download backup now pulls the whole organization — projects, conditions, action sets, rule sets, and tests — as a single JSON file, immediately. This works whether or not a scheduled destination is configured, so you can take a copy before a risky change without setting up storage first.
The downloaded file is in exactly the format the restore step expects, so anything you download here can be restored later.
Restoring from a backup
Restoring starts with the file picker, which accepts JSON files. The chosen file is read in your browser and its name is shown back to you before anything is committed, so you can confirm you picked the right one.
The one setting that matters here is the Overwrite existing projects checkbox:
| Overwrite | What happens |
|---|---|
| Off (default) | If the backup would conflict with an existing project of the same name, the whole restore is refused and the conflicting project is named in the message. Nothing is changed. |
| On | Any live project matching the backup’s contents is replaced by what is in the file. |
With overwrite on, current work in a matching project is replaced by the state captured in the backup file, and anything authored since that backup was taken goes with it. Leave the checkbox off first: a refused restore tells you exactly which project collides, and you can rename or remove it deliberately rather than discovering the loss afterwards.
A successful restore reports what came back, counted by type: Projects, Conditions, Action sets, Rule sets, and Tests. If the restore fails, the specific reason is shown instead — for a name conflict, that includes the name of the project involved.