Disaster Readiness

Disaster Readiness is account-wide protection for databases and persistent-volume environments. It keeps recoverable data in a destination region so you can restore that data if the source region or environment is unavailable.

Set up and operate protection from each environment's Snapshots tab, in the Disaster Readiness section. Workspace → Disaster Readiness is a read-only overview of every environment, with links to each source and its target.

A saved configuration, a running destination, or a completed snapshot is not Disaster Ready by itself. The dashboard only shows Disaster Ready after destination data recovery has been verified within your targets.

What it is

Term	What it means for you
Source	The live environment you already run (the database or volume you want to protect).
Destination	The region that holds recovery data. Warm (active) mode also keeps a standby environment allocated there.
Maximum data-loss target	How old recovered data may be (RPO). If the recoverable cutoff is older than this, status leaves Disaster Ready.
Data-restore time target	How long a destination restore test may take (RTO). This is an objective, not a guarantee. Measured restore time appears on each environment card.
Disaster Ready	Destination recovery has been verified, evidence is still current, and the destination is in a different region from the source.

Active / warm keeps a destination environment allocated so restore tests and activation reuse that standby. Passive / cold does not keep destination compute running; Quave ONE creates it when needed for a restore test or activation. Both modes copy data and can incur storage, transfer, and (for warm) destination compute usage.

Inactive recovery VMs inherit the regional pool's small CPU/memory defaults and 12.5% CPU baseline. Isolated database validation uses a bounded budget within that standby capacity; it proves engine startup and sampled data recovery, not live workload capacity. If the engine cannot safely validate within that budget, validation fails rather than silently enlarging the standby. Activation separately resizes only the owned VM to the live workload requirements and verifies its resources and 50% baseline before handoff; pool defaults and other VMs do not change.

Warm is the usual choice when you want a standing standby. Cold is cheaper between tests but slower to restore because compute is created on demand.

This is not:

• Automatic DNS or traffic failover
• Protection for stateless apps with no persistent disk
• A guarantee that the source region, clients, or your application stay healthy

Snapshots Validate and Disaster Readiness Validate now answer different questions. On the live source, both exist; neither replaces the other.

• Snapshots → Validate tests a backup: can this point-in-time snapshot restore? A Running source does not prove the snapshot is good, and a good snapshot does not prove the destination is ready.
• Disaster Readiness Validate now tests the destination pipeline: a copy in another place is receiving protection and can be promoted. Snapshots Validate does not cover that.
• On the destination (Passive / cold, or the Active / warm standby), Validate now is the useful analogue. That copy is not another snapshot on the source Snapshots tab.

See snapshot validation.

Prerequisites

• An account administrator. Other members can see environments they are allowed to access; only an admin can configure protection, validate, or activate.
• A Professional account. You can protect in the same region as the source — useful for a disk failure, an application mistake, or an incorrect update or delete. Same-region protection is a limited guarantee: it does not cover losing the whole region. For region-loss, enable at least two compatible regions. Hobby accounts stay in the Hobby region.
• Persistent volumes (or a managed database with disk) on the source. Stateless apps do not appear in this inventory.
• A destination that can receive recovery: the region must be enabled for your account, support persistent volumes, and be enabled as a disaster readiness destination. If none is listed, contact support.
• Snapshot storage already selected on the source. Setup reuses that selection; existing snapshots are not moved.

What you can protect

Disaster Readiness copies a local disk volume that Quave ONE owns for that environment. It only applies when your data lives on that volume.

Included today

• Managed databases and services whose data is on a platform disk: MongoDB, PostgreSQL, MySQL, and Redis with persistence on. The same types work on Quave ONE Direct and Quave ONE Connect (Redis on Connect is still Redis, not a different product).
• Application environments with a local persistent volume.

Not included

• Every other managed database, including manual database presets. They are not listed for Disaster Readiness. If you need one of them protected, contact support.
• PostgreSQL editions with their own image, such as TimescaleDB and ParadeDB. They appear in the Disaster Readiness list as not eligible yet. If you need one of them protected, contact support.
• MongoDB 4.4 and older. They appear in the Disaster Readiness list as not eligible. Upgrade the database to MongoDB 5.0 or later, or contact support.
• Databases whose data is not on a Quave ONE disk — for example MongoDB Atlas, Amazon RDS, or any database you only point at with a URL. The platform has no disk of yours to replicate.
• Redis without persistence (cache-only, no disk). There is nothing durable to copy.
• Compute-only apps, Functions, and Jobs with no persistent volume.
• Shared/NFS volumes and temporary disks.

Live recovery destinations are not listed again as sources. After you activate, configure new protection on the recovered environment instead of treating the old standby as a second source.

Regions (Direct and Connect)

The destination picker lists regions enabled on your account, using the same names as the rest of the dashboard (for example US-5). Choose Quave ONE Direct (Quave-managed) or Quave ONE Connect (your cloud) when those regions appear.

Pick a destination different from the source region whenever you can. Direct and Connect can be mixed when both regions appear in the list (for example a Direct source with a Connect destination).

Same-region destinations require an explicit acknowledgment: they cannot protect you if that region is lost. The dashboard then shows Same-region recovery only, not Disaster Ready.

If a region you need is missing, it is not enabled for your account, does not support persistent volumes, or is not enabled to receive disaster readiness. Ask support to enable a compatible destination.

Turn protection on

New databases

When you create a managed database that uses a platform disk, Enable disaster readiness is on by default if a destination is available. Review the estimated monthly usage and the target names (suggested as <app>-dr and <environment>-dr; databases always get a new app), and uncheck only if you intentionally want the database unprotected. Same-region destinations still require the acknowledgment checkbox. Apps with a persistent volume get the same opt-in, and can keep the target in the source app.

Cloned and preview environments are not enrolled by this default.

Existing environments

Open the environment's Snapshots tab and expand Disaster Readiness (the overview's Set up link opens it directly):

1. Choose the Destination region.
2. Name the target: the app env that will hold the recovery copy. Databases always get a new app; apps with a volume can keep the source app or create a new one. Names are suggested as <app>-dr and <environment>-dr; change them before saving. This applies to warm and cold protection: cold protection saves the names and pre-fills them when you activate.
3. Set Protection mode, snapshot and validation intervals, and the data-loss / restore-time targets (minutes). Defaults: 15-minute snapshots, daily validation, 30-minute data-loss target, 15-minute restore-time target, passive/cold.
4. Read the usage estimate. There is no separate recurring DR fee; snapshot storage, warm destination disk/compute, and cross-region copy are usage-based. Estimates are not a readiness guarantee.
5. Click Enable Disaster Readiness. Acceptance means preparation started — not that data is restored or Disaster Ready.

To change settings later, use Edit settings in the same section. A warm target already exists, so its names cannot change.

One snapshot interval. While Disaster Readiness is on, it owns the environment's snapshot interval: the interval is edited in the Disaster Readiness section, and Snapshots → Other options shows it read-only. When you enable protection, the interval starts from the current Snapshots interval when that is shorter than the suggested one. If you reset Disaster Readiness, the regular Snapshots interval applies again. Snapshot intervals must divide an hour, or be whole hours that divide a day. Targets are objectives; actual restore measurements appear in the section.

The target app env

The target is marked DR target in the app list and on its page. Its Snapshots tab shows Disaster Readiness target: the source it protects (linked), status, Activate as live, Activities and Logs. It has no snapshots of its own and cannot be destroyed or reconfigured; to remove it, reset Disaster Readiness on the source. The source's Disaster Readiness section links to its target as soon as the target exists.

Setup does not stop the source or switch traffic.

Read the status

Workspace → Disaster Readiness summarizes Ready, Needs attention, Setting up and Not protected environments. Protected environments lists each source and its target (both linked) with the main settings; settings that differ from most of your environments are highlighted so you can align them from each environment. Not protected lists eligible environments with a Set up link. The overview has no configuration forms.

Each environment's Disaster Readiness section shows the details below. Click Refresh before you take action; status goes stale after a short interval.

Field	How to read it
Status	Not set up, Protecting, Ready, Live, Error, or Unavailable. Same status style as Running / Updating elsewhere in the dashboard.
Reason	Why it is or is not ready
Protection mode	Active / warm or Passive / cold
Source region / Destination	The live region and the recovery region
Recoverable data cutoff	Newest data included in the last verified recovery point
Last successful validation	When a destination restore test last succeeded
Data-loss / restore-time targets	Your objectives
Measured data restore	Last measured restore duration, when recorded
Last reported step	Progress of an in-flight operation. This line alone is not Disaster Ready.

Disaster Ready means: destination data recovery verified within your targets. Warnings can still appear (for example source and destination sharing a cloud provider, or live activation depending on available cloud capacity). Warnings do not replace a failed status.

After a completed activation, Open recovered environment points at the new live data. Activities and Logs are in the section's ⋯ menu.

Validate now (destination restore test)

Validate now tests the destination protection pipeline (retained data in another place, ready to promote). That test is what the product uses toward Disaster Ready. It is not Snapshots-tab Validate, which tests a backup on the source.

• It can incur temporary cloud usage.
• Source traffic and the normal snapshot schedule stay unchanged.
• The request being accepted is not success. Follow the card: last reported step, last successful validation, and any cleanup warning.
• Initial setup must finish establishing the validation schedule before another Validate now is offered. If you see that warning, wait for setup progress and refresh.
• Only one recovery operation can run at a time. Wait until the current step finishes.
• Temporary restore disks may stay until a retention deadline. Cleanup continues automatically and may still incur cost. Pending cleanup is not Disaster Ready.

Success looks like a later Last successful validation timestamp, a current recoverable cutoff, and — when targets and destination region allow it — Disaster Ready.

What Check asks depends on the source, and that is a different kind of test — not a ranking of which engine is “more trustworthy”:

• PostgreSQL, Redis, MongoDB, and MySQL: Check starts the recovered engine and asks it a real question (is it up, can it return data).
• App + volume: Check asks whether the replica disk is healthy and ready to promote. It is not a SQL or Redis engine.

Failure looks like Needs attention with a reason such as the latest restore test failed, the test is overdue, recovery data is not confirmed at the destination, or evidence expired. Refresh, fix the cause, then Validate now again. If a request is not confirmed, refresh and Retry same validation request instead of starting a different one.

Activate as live

Activation promotes retained data in the destination so you can use it. It does not move application traffic or DNS. The Activate panel reminds you that this path is still being qualified — treat the first response as “activation requested,” then follow the card until recovery evidence is recorded.

1. Refresh status. Activation stays disabled while protection is consumed, setup is incomplete, or another blocking operation is running.
2. Choose Choose recovery point, then pick an explicit Recovery point (UTC cutoff). Nothing is selected for you. Later writes are not included.
3. Read the sizing preview when shown. It is not a reservation of capacity.
4. Acknowledge cutoff, possible data loss, and double-write risk if source writers are not stopped.
5. Choose the new environment name, using the same fields as Snapshots → Create new environment. Databases require a new app name. Other apps can keep the source app or choose Create a new app. Names saved at setup are pre-filled; a warm target keeps the names it was created with.
6. Confirm Activate as live, including the chosen names and cutoff. Names take effect only after verified Live handoff; recovery region, endpoints and runtime identifiers do not change.

Stop or isolate source writers when you can. An unavailable source is not fenced automatically; if it returns, it can write again and diverge from the recovered copy.

If the request is not confirmed, refresh and Retry same activation request. Do not start a second activation.

After activation

The original protection is consumed. The source card explains that this target is live, not a standby. Configure protection again for whatever is now the live environment. There is no automatic failback control.

PostgreSQL and Redis: live activation also completes database startup and public endpoint checks. Review connection details and current health, then point clients at the recovered endpoint yourself. Traffic and DNS have not been switched.

MongoDB: Activate as live uses the same handoff as PostgreSQL. It asks for a new app name and environment name, then starts MongoDB on the recovered disk after the existing restore reset. Traffic and DNS are not switched for you.

MySQL: Activate as live uses the same handoff as MongoDB. It asks for a new app name and environment name, then starts MySQL from the recovered disk snapshot. Traffic and DNS are not switched for you.

Persistent-volume apps: volumes were recovered; the application image and secrets were not copied automatically. Configure them on the recovered environment, isolate source writers, deploy explicitly, and verify the app before changing DNS.

Then enable and validate a new Disaster Readiness setup on the live environment.

During Redis activation, Repeat database verification may appear if the destination database check has not finished. It retries that check without restoring data again, changing DNS, or writing to the source. If the retry limit is reached, contact support with the environment name from the card.

Discard unfinished targets

Discard unfinished target appears only for an unfinished activation destination: once the data is being made writable, or earlier when a cold recovery keeps failing while it prepares or restores the destination. It deletes that temporary destination and its target data. It does not delete the source or its protected recovery points. Cleanup is asynchronous; resources may remain until removal is verified.

The button is not offered for a destination that is already live. Do not expect to discard a completed recovery that way.

What not to do

• Do not treat Configure, Validate now, or Activate as live acceptance as Disaster Ready.
• Do not pick the same region as the source if your goal is to survive that region failing.
• Do not reconnect clients or change DNS until you have verified the recovered environment.
• Do not leave the original source writing after activation if you have already pointed clients at the destination.
• Do not shrink or reconfigure a live recovered environment as if it were still a disposable standby.
• Do not treat Snapshots-tab Validate and Disaster Readiness Validate now as interchangeable. On the source they test different things; on the destination, use Validate now.
• Do not assume Hobby-region or single-region accounts can show Disaster Ready for regional loss.

Limits

• Members with restricted environment access only see those environments.
• Up to 100 environments can be submitted in one API configure request.
• Snapshot intervals outside the supported schedule are rejected, not rounded.
• Live activation depends on available cloud capacity; capacity is not reserved.
• Shared-provider source and destination can still be configured; the dashboard warns that this does not protect against that provider failing.
• After activation, plan a new protection setup. The previous standby relationship is consumed.

FAQ

Why not every database?

Disaster Readiness currently covers MongoDB 5.0 or later, PostgreSQL, MySQL, Redis with persistence on, and apps with a local persistent volume. Other managed databases are not supported and do not appear in the list. Contact support if you need one of them. External hosted databases, URL-only connections, and Redis without a disk are also out, because there is no Quave ONE disk to copy.

The destination I want is not in the list

The region is not enabled for the account, does not support persistent volumes, or is not enabled to receive disaster readiness. Contact support. Ordinary Change region on an environment is a different action and does not enroll Disaster Readiness.

Status stays Preparing / awaiting validation

Setup is still copying or testing data. Watch Last reported step. If preparation exceeds your data-loss target, the reason will say so. Wait for a usable recovery point, then Validate now once the schedule is established.

Validate now is disabled

You are not an admin, protection is consumed, another operation is running, status is stale (refresh first), or the validation schedule is not established yet.

Disaster Ready never appears even after a successful test

Typical causes: same-region destination, expired evidence (refresh and validate again), cutoff older than the data-loss target, measured restore longer than the restore-time target, or incomplete destination evidence. Read the reason on the card.

The recovered environment is Pending

Activation can leave the new environment starting while you still need to verify health, secrets, and clients. For generic volumes, you still need to deploy the application. Pending is not a DNS cutover.

Can I disable protection from this page?

Use Reset environment in the ⋯ menu of the environment's Disaster Readiness section, or Reset Disaster Readiness in the overview's ⋯ menu. Both ask you to type the environment or account name. That deletes the Disaster Readiness configuration and leftover recovery destinations still owned by it so you can start over. It does not delete the live source, and it does not delete a destination that already became live.

API

The same account permissions power the Disaster Readiness API. Use the dashboard for the first setup; use the API when you already understand the same readiness rules.

Choosing a recovery snapshot

Recovery choices, the selected cutoff, and the activation confirmation use your browser's local date and time. Requests retain the exact UTC cutoff internally.

For warm protection, Data until and the activation picker describe the destination's retained, validated point. A newer source snapshot is not proof that this destination can recover it. Use Validate now to check a newer applied point. When destination proof advances, reload the choices and explicitly confirm the new cutoff; the UI does not silently change a selected recovery point.

For cold protection, choose Choose snapshot to recover to list full and incremental snapshots from the same catalog as the environment's Snapshots page. Select one and Validate selected snapshot. This validates exactly that chain prefix using the shared restore-chain checks; missing objects, a changed cutoff, or an invalid chain fail rather than substituting a different point. Once validation finishes, reload Activate as live and select that cutoff. Validation itself never activates an environment or switches traffic.

Cold DR recovery retains the DR allocation and ownership checks. It is not a redirect to ordinary Create environment from recovery point: ordinary restore-on-deploy and native DR handoff have different engine support. Existing engine gates still apply, including the MongoDB native activation restriction.

After a verified native PostgreSQL handoff, the normal replica collector registers the existing ready runtime in the ordinary environment history. The environment then shows Running, actual replicas and CPU/memory metrics; Live on the DR card remains the historical activation result. Registration does not rebuild, restart, copy or replace the retained warm disk. Existing completed PostgreSQL handoffs are reconciled the same way. A handoff receipt alone never creates a Running status, and later failed/unready replicas remain visible through normal runtime telemetry. Client reconnection is still a separate action.

The environment does not use a recovery-specific Live runtime status. Its Running/Stopped state and replicas come from the ordinary environment records; the DR card keeps the historical activation outcome. Native PostgreSQL recovery also uses the regular database status/host reconciliation, including internal connection hosts. No restart or second restore is needed to register them.

Cold recovery and Create environment from recovery point share snapshot-chain selection, restore-package materialization and recovery destination creation. DR adds pinned-point, lease, placement and ownership checks around that core. Warm activation keeps its existing disk rather than invoking restore-on-deploy again.