Backup, Restore & Disaster Recovery

A resilient AI Insights 365 deployment depends on two things working together: the platform's own backup artifacts and the SQL Server database that holds your application data. This reference explains exactly what each backup type captures, how to create and restore them, how to coordinate them with standard database backups, and how to assemble all of it into a disaster recovery runbook you can rehearse. Everything described here runs inside your own infrastructure — backups never leave the host you choose to store them on.

Backup Types at a Glance

AI Insights 365 produces two native backup artifacts, both delivered as standard ZIP archives so they are easy to inspect, transfer, and store in any vault or file share you already operate.

• Organization backup (.orgbak) — captures the full organizational scope: every workspace within the org, along with org-level configuration.
• Workspace backup (.wbak) — captures a single workspace in isolation, useful for granular recovery, sharing a workspace between deployments, or promoting one project at a time.

Both archives can be restored into the same deployment they came from (true disaster recovery) or into a different deployment (migration and portability). That second capability is what makes the format suitable for environment promotion, host moves, and cloning known-good configurations.

Backup Scope Table

A practical rule of thumb: use .orgbak for whole-environment protection and migration, and .wbak when you need to move or recover a single unit of work without disturbing everything around it.

Choosing Between Org and Workspace Scope

The two artifacts are not redundant — they serve different recovery and operational goals, and a mature deployment produces both on different cadences.

• Reach for .orgbak when the unit of failure or change is the whole environment: a host rebuild, a full migration to new hardware, a DR failover, or a pre-upgrade snapshot. Because it carries org-level configuration and every workspace, a single archive reconstitutes the logical state of the entire deployment.
• Reach for .wbak when the unit of work is one workspace: promoting a single validated dashboard from development to production, sharing a reference workspace with another team or deployment, or recovering one workspace that a user accidentally damaged without rolling back everything else.

A useful mental model is that .orgbak answers "rebuild the whole thing" and .wbak answers "move or restore just this." Most teams schedule daily .orgbak archives for whole-environment protection and take ad-hoc .wbak archives around significant changes to individual workspaces.

What Backups Do and Do Not Replace

Native backups protect the platform's logical objects — workspaces, connectors, charts, transforms, scheduled reports, and configuration. They are not a substitute for backing up the SQL Server database itself. Because the underlying application data lives in your own SQL Server instance, your existing database backup discipline still applies and remains the system of record for point-in-time recovery.

Think of it as two complementary layers:

1. Platform backups (.orgbak / .wbak) — portable, object-level, ideal for moving and restoring logical content across deployments.
2. SQL Server backups — full, differential, and transaction-log backups that give you point-in-time recovery at the database level.

A complete DR posture uses both. The platform backup lets you stand up a clean deployment and reload content quickly; the database backup lets you recover to a precise moment if data is corrupted or deleted in place.

Creating Backups

Backups are produced from the administrative areas of the platform. The general flow is the same for both scopes.

1. Sign in with an account that holds the appropriate administrative role (org administration for .orgbak, workspace administration for .wbak).
2. Navigate to the backup area for the scope you want.
3. Choose Create backup. The platform packages the scope into a ZIP archive with the corresponding extension.
4. Download the artifact and move it to your designated backup storage (file share, vault, or object store).

Store backups off the application host wherever possible. A backup that lives only on the machine it is meant to protect offers no protection against host loss.

Applying the 3-2-1 Rule

Off-host storage is the first step toward a defensible backup posture, but the widely used 3-2-1 rule sets a clearer target:

• 3 copies of the data (the live system plus at least two backups).
• 2 different storage media or systems (for example a local file share and an object store).
• 1 copy kept off-site or otherwise isolated from the primary site.

Apply the rule to both layers — the platform archives and the SQL Server backups — so that no single failure (a deleted folder, a ransomware event, a site outage) can take out every recovery option at once. Where your storage supports it, keep at least one copy immutable or write-once for a fixed retention window; this is your strongest defense against malware or an operator error that deletes or overwrites recent backups.

Naming and Storage Convention

Adopt a consistent, sortable naming convention so restores are unambiguous under pressure:

# Suggested convention: scope_environment_YYYYMMDD-HHMM
org_prod_20260615-0200.orgbak
ws_sales_prod_20260615-0200.wbak

# Mirror to off-host storage immediately after creation
robocopy "D:\AI365\Backups" "\\backup-srv\ai365\daily" /E /Z /R:3 /W:10

Pair every platform backup with the timestamp of the corresponding SQL Server backup so the two layers can be reconciled later.

Restoring Backups

Restore Into the Same Deployment (Disaster Recovery)

Use this path when content was lost, corrupted, or misconfigured and you want to return the existing deployment to a known-good state.

1. Confirm the target deployment is healthy and reachable (see Verifying Restores below).
2. Open the restore area for the matching scope.
3. Upload the .orgbak or .wbak archive.
4. Review the restore summary and confirm.
5. Validate that connectors, charts, transforms, and scheduled reports are present and functioning.

Restore Into a Different Deployment (Migration / Portability)

Use this path for environment promotion, host moves, or cloning. Because the archive is self-contained, the target does not need to be related to the source.

1. Complete a fresh install on the target host using the setup wizard.
2. Confirm the target is healthy via /health.
3. Upload the backup archive into the matching restore area.
4. Reconcile connection credentials and the encryption key (see below).
5. Re-point any environment-specific settings — these can be edited live without a restart.

Encryption-Key Considerations During Restore

Secrets in AI Insights 365 are encrypted at rest with AES-256, and the encryption key is rotatable from System Settings. This matters most when restoring into a different deployment, because encrypted secrets in the backup can only be decrypted with the key that originally protected them.

Keep these rules in mind:

• Same-deployment restore: the key is already present, so encrypted secrets restore transparently.
• Different-deployment restore: the target must have the matching key material, or you must be prepared to re-enter the affected secrets (connector credentials, API keys) after the restore.
• After key rotation: treat the rotation event as a backup boundary. Take a fresh backup immediately after rotating so your archive aligns with the active key, and record the rotation date in your runbook.

Never store the encryption key inside the same archive or vault path as the backups it protects. Keep key custody separate so that compromise of one does not compromise the other.

Key-Rotation Caveats

Key rotation is a healthy security practice, but because the AES-256 key is what makes restored secrets readable, rotation interacts with your backup history in ways worth planning for:

• Older backups are bound to older key material. An archive created before a rotation still contains secrets encrypted under the key that was active at the time. If you must restore that older archive after rotating, you either need the prior key material available or you must re-enter the affected secrets by hand.
• Snapshot before and after. Treat a rotation like any other significant change: take a fresh .orgbak and database backup immediately before rotating (so you can roll back) and another immediately after (so your most recent archive aligns with the new key).
• Record the rotation in your runbook. Log the date and time of each rotation alongside the backup catalog. During a recovery under pressure, knowing which archives predate the current key is the difference between a transparent restore and a scramble to re-enter credentials.
• Coordinate rotation with custodians. If key custody is split across people or systems, ensure whoever performs a future restore can actually obtain the matching key.

Re-Entering Secrets After a Cross-Deployment Restore

When you knowingly restore into a deployment that does not hold the original key, plan a short post-restore pass to re-enter secrets rather than hoping they resolve:

1. List every connector and integration that depends on a stored credential or API key.
2. After the restore completes, open each one and confirm whether its secret resolved.
3. Re-enter any secret that did not, then test the connection before declaring the restore complete.
4. Capture the list as a reusable checklist so the next cross-deployment restore is faster.

Coordinating With SQL Server Database Backups

Because the platform sits on your own SQL Server database, fold it into your existing maintenance plans:

• Full backup on a regular cadence (for example nightly).
• Differential backups between fulls to shorten restore time.
• Transaction-log backups at a short interval (for example every 15 minutes) when running in the full recovery model, enabling point-in-time recovery.

-- Nightly full
BACKUP DATABASE [AIInsights365]
TO DISK = N'\\backup-srv\ai365\db\AIInsights365_full.bak'
WITH INIT, CHECKSUM, COMPRESSION;

-- Frequent log backup (full recovery model)
BACKUP LOG [AIInsights365]
TO DISK = N'\\backup-srv\ai365\db\AIInsights365_log.trn'
WITH CHECKSUM;

Align the timing of your .orgbak creation with the database full backup so the two layers describe the same moment. When you restore, restore the database first, then apply the platform backup if logical objects also need to be reloaded.

Choosing a Recovery Model

The SQL Server recovery model governs what point-in-time recovery is even possible, so choose it deliberately:

• Full recovery model keeps the transaction log until it is backed up, enabling restore to any point in time covered by your log chain. This is the right default for production: combined with frequent log backups, it gives you the tightest possible RPO.
• Simple recovery model automatically truncates the log and supports recovery only to the last full or differential backup. It is simpler to operate but cannot deliver point-in-time recovery, so reserve it for non-critical or easily reproducible environments.

Whichever model you choose, validate that backups are restorable rather than merely present. Use RESTORE VERIFYONLY to confirm a backup is readable and complete, and run DBCC CHECKDB on a recovered copy periodically to catch corruption before it propagates into your backup history.

-- Confirm the most recent full backup is internally consistent and restorable
RESTORE VERIFYONLY
FROM DISK = N'\\backup-srv\ai365\db\AIInsights365_full.bak'
WITH CHECKSUM;

Ordering the Two Layers During Recovery

When both layers are involved, order matters. Restore the SQL Server database first to re-establish the system of record at the chosen point in time. Only then apply a platform .orgbak or .wbak if logical objects were also lost or you are reloading content into a freshly provisioned host. Applying a platform backup before the database is in place can leave the two layers describing different moments, which is exactly the inconsistency the timing alignment above is meant to prevent.

Recommended Backup Schedule & Retention

The following baseline suits most production deployments. Adjust to your change rate and compliance obligations.

Always take an ad-hoc .orgbak and a database backup immediately before an upgrade, configuration change, or key rotation. These on-demand snapshots are your fastest path back if a change goes wrong.

Environment Promotion (Dev → Prod)

Backups double as a clean promotion mechanism. To promote validated work from development to production:

1. In dev, finalize and test the workspace or org content.
2. Create a .wbak (single workspace) or .orgbak (whole org) from dev.
3. In prod, take a pre-change .orgbak and database backup for rollback safety.
4. Restore the dev archive into prod using the different-deployment path.
5. Reconcile environment-specific settings — connection strings, the in-network database targets, and any credentials — live, without a restart.
6. Verify, then retire the temporary dev artifact according to policy.

This keeps promotion auditable: each release corresponds to a dated, retained archive.

Defining RPO and RTO

Two numbers anchor any recovery plan, and they should be agreed with the business before an incident, not discovered during one.

• Recovery Point Objective (RPO) is the maximum acceptable data loss, measured in time. It answers "how much recent work can we afford to lose?" Your RPO is effectively set by how often you capture recoverable state. With the full recovery model and 15-minute transaction-log backups, your worst-case RPO is roughly the log interval — about 15 minutes of data.
• Recovery Time Objective (RTO) is the maximum acceptable downtime. It answers "how long can we be down?" Your RTO is set by how quickly the DR runbook can provision a target, restore the database, reload platform content, and pass verification.

The two are levers you tune against cost. Shrinking RPO means more frequent backups and more storage; shrinking RTO means more automation, warmer standby infrastructure, and more rehearsal. Document a target for each tier of importance, then prove the targets in rehearsal — an RPO/RTO you have never measured is an aspiration, not a commitment.

Verifying Restores

A backup you have never restored is a hypothesis, not a recovery plan. Verify on a schedule.

• Health check: confirm the deployment responds on /health before and after restore. Wire this endpoint into your monitoring so degraded states surface automatically.

curl -fsS https://ai365.internal.example.com/health && echo "OK"

• Object spot-check: confirm a representative connector, chart, transform, and scheduled report exist and execute.
• Credential check: confirm encrypted secrets resolved (or were re-entered) and that data connections succeed.
• Audit-log review: confirm audit logging is active and recording the restore event.
• Scheduled-report dry run: trigger one report to confirm the end-to-end pipeline works.

Perform a full restore rehearsal into an isolated environment at least quarterly, and record the result.

Restore-Verification Checklist

Use this checklist as a sign-off gate before declaring any restore complete. Treat an unchecked box as a blocking issue, not a footnote.

Live-Editable System Settings During Restore

Many of the values you must reconcile after a cross-deployment restore — connection targets, the in-network database endpoints, environment-specific options — are exposed through System Settings and are editable live, without a restart. This is what makes environment promotion and host moves practical: you restore the self-contained archive, then adjust the handful of settings that legitimately differ between environments in place, and the deployment picks them up immediately. Plan these edits as an explicit step in every cross-deployment restore so the recovered system points at the right database and AI backend for its environment rather than the source's. Because the platform connects directly to databases inside the customer network — reaching remote subnets over private networking or a VPN where needed — these targets are simply hostnames or listener addresses on your own network, and updating them is the only environment-specific work a restore requires.

Disaster Recovery Runbook Outline

Keep a printed and offline copy of this runbook; a DR plan stored only inside the system it protects is unavailable exactly when needed.

1. Declare and assess. Identify scope of loss: host, database, content, or all three. Note last-known-good backup timestamps for both layers.
2. Provision the target. Stand up a Windows host and run the setup wizard for a clean install if the original host is gone.
3. Restore the database. Recover SQL Server from full + differential + logs to the desired point in time.
4. Restore platform content. Apply the most recent .orgbak (or relevant .wbak archives) into the deployment.
5. Reconcile keys and credentials. Confirm the AES-256 key material is in place; re-enter secrets if restoring to new key material.
6. Re-point environment settings. Update connection targets and in-network database endpoints live, without restart.
7. Verify. Run the verification checklist above, including /health and a scheduled-report dry run.
8. Communicate and close. Notify stakeholders, record recovery time, and capture lessons learned. Take a fresh backup of the recovered environment immediately.

Define target RPO and RTO up front, then prove them in rehearsal: your transaction-log interval sets the effective RPO, and the runbook above sets the achievable RTO. Document both, test both, and your recovery becomes a procedure rather than an improvisation.

Monitoring and Early Warning

Recovery is cheapest when you never need the full runbook because you caught the problem early. Wire the platform into the same monitoring you use for the rest of your infrastructure:

• Liveness: poll /health on a short interval and alert on any non-success response or timeout. A degraded health state is often the first visible sign of a database, credential, or network-connectivity problem.
• Backup success: alert when a scheduled .orgbak or SQL backup job fails or is skipped. A silent backup failure is the classic way teams discover, far too late, that they have no recent recovery point.
• Storage capacity: watch free space on backup targets so retention does not silently stop because a volume filled.
• Audit-log flow: confirm audit events continue to be recorded; a sudden gap can indicate a configuration or storage issue.

# Minimal liveness probe suitable for a cron job or monitoring agent
if curl -fsS --max-time 10 https://ai365.internal.example.com/health > /dev/null; then
  echo "ai365 healthy"
else
  echo "ai365 health check FAILED" >&2
  exit 1
fi

Common Pitfalls to Avoid

A few recurring mistakes account for most failed recoveries. Guard against them explicitly:

• Backups stored only on the protected host. Always mirror off-host; a host loss should never take the backups with it.
• Never testing a restore. Untested backups fail at the worst possible time. Rehearse on a schedule.
• Forgetting the key during cross-deployment restores. Plan for re-entry of secrets or have the matching key available.
• Letting the platform and database backups drift apart in time. Align their schedules so the two layers describe the same moment.
• No offline copy of the runbook. A DR plan stored only inside the failed system is unavailable when you need it most.
• Unbounded retention or none at all. Define retention deliberately so you keep enough history without exhausting storage.

Summary

A dependable recovery posture for AI Insights 365 rests on layering the platform's own portable artifacts — org-level .orgbak and workspace-level .wbak archives that restore into the same or a different deployment — on top of disciplined SQL Server backups that provide point-in-time recovery. Keep copies off-host and follow the 3-2-1 rule, align the timing of both layers, account for AES-256 key custody and rotation, verify every restore against a concrete checklist, and rehearse the full runbook against agreed RPO and RTO targets. Done consistently, recovery stops being a hopeful improvisation and becomes a measured, repeatable procedure — and every backup doubles as a clean mechanism for migration and environment promotion.