Backup & Disaster Recovery

How Nexus operational state is backed up and recovered — Azure Database for PostgreSQL point-in-time restore, the per-tenant git version store for authored assets, and Azure Files — all inside your subscription, following your existing Azure DR practices rather than a Stingray-set RPO/RTO.

This page is for the platform and DR owners who need to fold Nexus into an existing backup and recovery program. The central fact makes that straightforward: because Nexus runs entirely inside your Azure subscription, its backup and disaster-recovery story is an extension of your Azure backup and DR story. There is no separate Stingray-hosted datastore to coordinate with, and there is no Stingray-set service level you inherit — you configure protection using the same Azure-native mechanisms and the same targets you already apply to your other tenant workloads.

Where recoverable state lives

Nexus keeps its durable state in three Azure-native stores, all in your subscription. Knowing which is which tells you how to protect each.

Everything the platform needs to be restored to a working state is in this list, and every item is a first-class Azure resource with its own native protection story.

PostgreSQL: point-in-time restore

The operational database is an Azure Database for PostgreSQL Flexible Server. It carries Azure's automated backups, which support point-in-time restore — recovering the database to a chosen moment within your configured retention window. This is the primary recovery path for the platform's operational state (your reports, pipeline definitions, run history, and audit records). The retention window, backup redundancy (locally vs. geo-redundant), and whether you maintain a replica are your Flexible Server configuration choices — set them to match your organization's data-protection policy for a system of this criticality. Nexus does not override or constrain them.

Authored assets: the versioned git store

Pipelines, reports, sites, and skills are versioned in a per-tenant git repository held on Azure Files. This is a second, independent line of recovery for the assets people author: every save is a commit, so you can diff and restore any asset to a prior known-good state through the product itself (REST + MCP), entirely separate from a database restore. Writes are multi-replica-safe via an advisory lock and reads are lock-free. See Version Control for the history/diff/restore surface. Practically, this means a bad edit to a pipeline is recoverable with a restore-to-revision, and does not require a database-level DR event.

Azure Files and Key Vault

• Azure Files holds pipeline state artifacts, file outputs, and the git version store. Protect it with Azure Files backup/snapshots on the schedule your policy dictates.
• Key Vault holds your connection secrets and the signing keys. Enable soft-delete and purge protection (recovery of deleted secrets/keys) per your standard Key Vault posture. Because credentials live only in your Key Vault and are never held by Stingray, Key Vault recovery is entirely within your control.

Recovering the application tier

The Nexus server itself is stateless relative to the stores above — it is a container image pulled from Stingray's registry and run as an Azure Container App in your tenant. Recovering or relocating the application tier is a redeploy of that image against your existing data stores; it does not carry unique state that must be separately backed up. Database migrations are applied on startup, so a recovered server reconciles the schema against the restored database automatically. See Updates and Marketplace Deployment for the deployment mechanics, and Architecture for why the data plane, not the app tier, is where durable state lives.

Following your Azure DR practices

Nexus deliberately does not impose its own DR regime on top of Azure's. The recommended approach is to treat each Nexus store as an instance of a workload class you already protect:

1. Set PostgreSQL backup retention and redundancy to your policy for a business-critical database; decide on geo-redundancy and read replicas per your regional-failure requirements.
2. Include Azure Files (and thus the git version store) in your Azure Backup scope.
3. Enable Key Vault soft-delete + purge protection.
4. Document the redeploy runbook for the Container App so application-tier recovery is a rehearsed step, not an improvisation.
5. Rehearse a restore. A PITR you have never tested is a hope, not a plan — exercise it the way you would for any other tenant-critical database.

Government-cloud deployments follow the same model on Azure Government; the platform is proven on Azure Government (GCC-High), so the DR primitives above apply there with your Gov-cloud region and policy choices.

On numbers we do not publish

We deliberately do not publish an RPO, RTO, uptime percentage, or SLA for Nexus, because those would be fiction: the recovery point and recovery time you achieve are determined by your Azure configuration — your Flexible Server backup retention and redundancy, your Azure Files backup cadence, your region and replica choices — not by a number Stingray could honestly commit to for infrastructure that runs in your subscription and under your control. What we can state precisely is that Nexus stores durable state exclusively in Azure services that carry Azure's own backup and recovery capabilities, and that Nexus inherits the posture of those services as you configure them. Set your own targets against your Azure configuration and measure against them.

Limits & guarantees

• Guaranteed: all durable Nexus state lives in Azure-native, individually recoverable stores in your subscription (PostgreSQL PITR, versioned git store on Azure Files, Azure Files backup, Key Vault recovery); authored assets have an independent version-history recovery path; the application tier is a stateless redeploy.
• Your responsibility: configuring backup retention/redundancy, Azure Files backup, and Key Vault protection to your policy, and rehearsing restores. Nexus does not set these for you.
• Not published: RPO, RTO, uptime %, or an SLA — these follow your Azure configuration, not a Stingray commitment.

See also

• Architecture
• Version Control
• Updates
• Auditing & Cost Telemetry
• Reliability & Operations Overview