Site Recovery
Site Recovery is available exclusively with an Enterprise license.
Site Recovery provides disaster recovery (DR) capabilities for your Proxmox environments. It manages data replication between nodes or clusters, orchestrates recovery plans, and supports failover, failback, and emergency DR operations -- giving you confidence that critical workloads can be restored quickly when disaster strikes.
Overview
Site Recovery is built around two core concepts:
- Replication Jobs -- Continuous or scheduled data replication from a source node/cluster to a target, ensuring an up-to-date copy of your VMs is always available.
- Recovery Plans -- Predefined sequences of actions that describe how to restore a set of VMs on a target cluster in case of failure.
Together, these allow you to protect workloads, test your DR strategy regularly, and execute real failovers with minimal downtime.
Site Recovery mirrors Ceph RBD images between clusters, so it needs at least two Proxmox connections with Ceph enabled. With fewer, the page reports "No Ceph cluster detected" or "Only one Ceph cluster detected" and the replication, recovery plan and emergency features stay unavailable until a second Ceph-enabled connection is configured in Settings > Connections. Replication also needs passwordless SSH between the source and the target cluster, which the job creation dialog verifies before it lets you save. Only QEMU virtual machines are replicated; LXC containers are not part of Site Recovery.
Use Site Recovery for planned DR workflows with defined source and target clusters. For one-off VM movement between clusters, use Migration instead.
Interface Tabs
The Site Recovery page is organized into six tabs: Dashboard, Replication, Snapshots, Recovery Plans, Emergency DR and Simulation. The sections below cover the ones that make up a replication and recovery workflow.
Dashboard
The Dashboard tab provides a high-level view of your replication health:
- Overall replication status -- healthy, degraded, or critical
- Active replication job count and their current states
- Error count -- jobs in an error state are flagged immediately
- Job Status Distribution -- a stacked bar splitting every job by status: synced, syncing, pending, error, paused, and No matching VMs for a tag-based job whose tags currently match nothing
- Recovery plan status overview
Use this tab as a daily check-in to verify that your DR posture is healthy.
Replication
The Replication tab manages replication jobs. Each job defines what data is replicated, from where, and to where.
Creating a Replication Job
Click Create Replication Job to open the creation dialog. You can configure:
- Source connection -- the Proxmox cluster containing the VMs to protect
- What to replicate -- a VMs / Tags toggle. In VMs mode you tick individual guests from the source cluster; in Tags mode you tick tags, and the job protects whatever carries them, re-resolved at every sync
- Target connection -- the destination cluster for replicated data. ProxCenter checks passwordless SSH to it before letting you save
- Target pool -- the Ceph pool on the target cluster that receives the replicated RBD images, listed with its usage so you can see what room is left
- Schedule -- either an RPO target picked from
30s,1m,5m,15m(the default),1hand24h, or a calendar schedule (hourly, daily, weekly or monthly) with its own timezone. In calendar mode the RPO target is derived from the interval between two runs, and it is that target the RPO alerts measure against - Snapshot retention -- how many mirror snapshots are kept on each side, described below
- VMID prefix -- the numbering the replicas get on the DR cluster
A guest does not have to be running to be replicated. Replication works on the Ceph RBD images, and the one step that does need a running guest, the filesystem freeze that makes a snapshot application consistent, is already skipped per VM when the guest is stopped. Stopped and paused guests are therefore listed in the picker alongside running ones, with their state shown as a coloured dot.
Templates are the exception and stay out of both modes, in the picker and in tag resolution: a replica of a template could not be started at failover, so protecting one would buy nothing.
Tag-Based Jobs and the Protected Set
A tag-based job resolves its tags against the source cluster before every sync, so the protected set follows the tags rather than a list frozen at creation. Both directions are recorded in the job's execution log:
- A guest that has just gained one of the tags is added, and the log reads "Tag re-resolution added N VM(s) to protection".
- A guest that lost the tag, or that was deleted, is removed with a warning line: "Tag re-resolution removed N VM(s) from protection ... Existing replicas on the target are kept but will no longer be updated." Its per-VM row is dropped from the job so it stops being displayed as protected.
A removal is a protection gap, not housekeeping. The replica already on the DR cluster is left in place, so the plan still finds something to boot, but it is frozen at the last sync that included the guest. Check the tag before assuming the guest is still covered.
A Tag-Based Job That Matches Nothing
If a job's tags stop matching any guest, the job does not fail. It lands in a status of its own, No matching VMs, and:
- No failure notification is sent, and the retry cascade reserved for real errors is not entered.
- The next sync stays scheduled and the tags are resolved again at that point, so the job recovers on its own the moment a guest is tagged again.
- The status is shown wherever a job status appears: the status chip and the All statuses filter of this tab, the chip on the Emergency DR tab, and the Job Status Distribution bar of the Dashboard tab.
- RPO alerts keep firing. This is deliberate: a DR job that protects nothing has to keep nagging until somebody looks at it. See Replication and Ceph Alerts below.
This status only appears on a job that has already been created. At creation time a tag selection that matches no guest is refused outright, with "no VMs found matching tags".
Managing Replication Jobs
For each job, the following actions are available:
| Action | Description |
|---|---|
| Sync | Trigger an immediate replication sync |
| Pause | Temporarily suspend replication |
| Resume | Resume a paused replication job |
| Delete | Remove the replication job entirely |
Selecting a job displays its execution logs in a detail panel, showing the history of sync operations with timestamps and results.
Run a manual sync after making significant changes to a protected VM to ensure the latest state is replicated before relying on it for recovery.
Snapshot Retention
Each job keeps a rolling set of mirror snapshots on both sides, and how many it keeps is configurable in Create Replication Job and in Edit replication job, under Snapshot retention:
| Field | Meaning |
|---|---|
| Keep on source | Mirror snapshots kept per disk on the source cluster after each sync |
| Keep on target (DR) | Mirror snapshots kept per disk on the DR cluster after each sync |
The unit is a count of snapshots per disk, not a duration. Both sides default to 3, the minimum is 2 and the maximum is 500. Each field pairs a number box with a slider; the slider stops at 50, so type the value in the box if you want more than that.
Retention is one of the few job settings you can change after creation. The VMs, the tags, the clusters, the target pool and the VMID prefix are immutable: to change those, delete the job and recreate it. On a tag-based job that is about the list of tags, not about the guests: the protected set follows whatever carries those tags and is re-resolved at every sync, which is what makes tagging a guest enough to protect it.
The restore points offered when you fail over are the mirror snapshots that still exist on the DR side, so Keep on target (DR) is what decides how far back in time you can recover. Raise it when you want more than the last few sync points, keeping in mind that every snapshot holds Ceph capacity.
Pruning runs at the end of each sync, per disk, and a floor of two snapshots is always re-applied so a common incremental base survives on both sides. It also removes at most ten snapshots per image per run, so lowering retention from a large value does not free the space at once: the backlog drains over the following syncs and the job log reports how many are still pending. During a failback the two roles are swapped, since the DR side is the one being replicated from.
Recovery Plans
Recovery Plans define the procedure for restoring services on a target cluster. The tab lists all existing plans and lets you create new ones.
Creating a Recovery Plan
Click Create Plan to define:
- Plan name and description
- Source and target clusters
- Associated replication jobs -- which replication jobs feed into this plan
- VM startup order and dependencies
Recovery Plan Operations
Each recovery plan supports three operations:
| Operation | Description |
|---|---|
| Test Failover | Executes the recovery plan on the DR cluster, by default with every network interface shut down. Production workloads are not affected, and the source VMs are left alone. Each recovered VM's console is captured while the test runs. Two options are offered before the run starts, see Test Failover Options. Use this to validate your DR strategy regularly. |
| Failover | Activates the recovery plan for real. The source VMs are fenced, then the replicas are started on the DR cluster from the chosen restore point. Use this during an actual disaster. |
| Failback | Available once a plan is failed over. It brings the workloads home in two phases: a reverse incremental sync from the DR site to the source, then an operator-driven cutover. See Failback. |
When any operation is executed, ProxCenter tracks its progress in real time, polling the execution status every 3 seconds and displaying step-by-step updates. During a real failover and during a failback cutover, each VM also shows the step it is on: Stopping the source VM, Rolling back to the selected restore point, Starting on the DR site, and for the failback cutover Stopping the DR VM, Applying the final delta, Starting on the source site and Re-protecting. The step is shown while the VM is running that step; a VM that has finished shows its result, and a VM that failed shows its error instead.
Failover is a disruptive operation. Ensure the source site is truly unavailable before initiating a production failover, as running the same VMs on both sites simultaneously can cause data corruption.
A test failover does not report per-VM steps. It reports progress per VM and, in its final phase, a three-step checklist for the console captures: Starting VMs, Letting guests settle and Capturing boot screenshots.
Restore Points
By default a failover boots each VM from the latest replicated state. Both Test Failover and Failover let you pick an older point instead, per VM, from a Choose the restore point selector on each VM row of the dialog. The default entry is Latest (default); the other entries are the replicated snapshots that still exist on the DR side, newest first, shown with their timestamp.
The list is read from the live state of the DR cluster each time the dialog opens, and only snapshots present on every disk of a VM are offered, so a partially failed sync cannot boot a torn VM. A VM with nothing to offer shows No restore points. When the list cannot be read at all, the dialog says "Restore points could not be loaded, the latest replicated state will be used." and runs on the latest state.
Choosing an older point on a real failover re-bases the DR image: "Failing over to an older restore point permanently deletes the newer DR snapshots of that VM." The dialog shows that warning as soon as you select a point. A test failover does not re-base, and its cleanup rolls the image forward again, so testing an older point costs you nothing.
Test Failover Options
The Test Failover dialog carries two settings, in a panel above the VM list. They are editable until you press the button that starts the run, and they apply to that run only: nothing is stored on the plan.
| Option | Default | What it does |
|---|---|---|
| Network isolation | On | Every network interface of every recovered VM gets link_down=1 before the VM is started, so the replica boots with its cards administratively down. The interfaces themselves are kept, so nothing about the guest's networking is lost, and the flag disappears on its own at the next sync, which rewrites the replica configuration from the source. |
| Boot screenshot delay | 45 s | How long ProxCenter waits after the last VM has started before capturing the consoles. Accepts a whole number of seconds between 5 and 600. |
Turning network isolation off. The switch is labelled "DR VMs boot with every network interface shut down. Turn it off to test with the interfaces connected to the mapped target bridges." Turning it off raises a warning in the dialog, on the spot:
"The DR VMs will boot with their production addresses on the mapped target bridges. Only run this where the DR site is not bridged to production, otherwise addresses will collide."
A replica carries the source guest's network configuration verbatim, MAC address and bridge name included, so it comes up on the DR cluster's bridge of that name with the production addresses of the guest it copies. If that bridge reaches the production network, two machines with the same address land on the same wire. Run a connected test only on a DR site that is genuinely separated from production, and use it for what isolation cannot answer: whether the application actually serves, not merely whether the guest reaches a login prompt.
Once the run has started, the option it used is no longer editable but stays visible: a chip on the dialog reads Network Isolated or Network connected, so an execution you come back to never leaves you guessing which mode it ran in.
Choosing a delay. 45 seconds is enough for a guest that reaches a login prompt quickly, and too short for a large Windows guest or anything that runs filesystem checks at boot: those get photographed mid-boot. Raise the delay to whatever your slowest guest in the plan needs. The value applies to the whole pass, not per VM, since the wait happens once after all the VMs have started. An empty field, a decimal, or a value outside the 5 to 600 range is refused and the run is blocked until you fix it.
A real failover is never network isolated and takes no such options: it starts the replicas with their interfaces connected, which is the point.
Boot Screenshots on a Test Failover
During a test failover, ProxCenter captures the console of each recovered VM and keeps the image with the execution, so you can see what a guest actually booted into instead of trusting a power state. The capture itself is automatic: there is no switch to turn it on, only the delay described above.
The capture pass runs once, after every VM of the plan has been started. ProxCenter waits for the boot screenshot delay of that execution, 45 seconds unless you changed it, then takes exactly one capture per VM. The dialog shows the wait as a countdown next to Letting guests settle, and the countdown follows the delay you chose.
The delay is stored on the execution. Test executions recorded before the option existed carry no value and are read back as the 45 second default, so their history stays consistent.
The captures appear as small thumbnails in two places, both on the Recovery Plans tab: under the corresponding test execution in the plan's Execution History, and as a camera button on each VM row of the test failover dialog, labelled View boot screenshot. Clicking a thumbnail opens the full-size image with the VM name and the time it was captured.
Captures need the orchestrator and SSH access to the DR cluster, they only work for QEMU virtual machines, and they need a guest with an emulated display: a serial-console-only guest produces nothing. A capture that does not succeed is skipped silently. It does not fail the test and it produces no error message, so the only sign is a missing thumbnail. A capture is also only attempted when at least one VM of the plan actually reached a completed state.
Running Cleanup test does not delete the captures: they are kept as the archived evidence of the test. They are removed only when you clear the plan's execution history or delete the plan itself.
Source Fencing on a Real Failover
A real failover fences each source VM before starting its replica, so the same guest cannot end up running on both sides. Fencing means, in order: a graceful shutdown request with a 60 second deadline, a hard stop if the guest has not stopped by then, and finally clearing onboot in the source VM's configuration so a recovering source site cannot boot the guest back into a split brain. This is unconditional on a real failover and never happens on a test failover. There is no option to turn it off.
A real failover is a disaster procedure, so it does not stop when fencing cannot be carried out. If the source cluster is unreachable, fencing is skipped for the whole failover and the DR replicas are started anyway; the orchestrator log records that it skipped it. Treat fencing as a safety net that usually works, not as a guarantee: if the source site is only partly down, confirm the source guests really are stopped before you let the site come back.
Locked After a Failover
Once a plan is failed over, ProxCenter locks it and its replication jobs so nothing can overwrite the copy that is now production. The plan carries a Failed Over status and the tooltip "Plan is failed over -- only failback is possible.", with Test Failover and Failover disabled. Each replication job of that plan carries a Failed over chip, and its tooltip explains that the job's DR copy is now production and that resuming replication would overwrite it, so a failback has to come first. Sync Now, Resume and Edit are disabled on that job. Deleting is still allowed.
The lock is released per job by the failback, once every VM of that job has completed its cutover.
Test Cleanup
After running a test failover, use the Cleanup test action to tear down the test environment and release resources on the target cluster. This ensures that test artifacts do not consume storage or interfere with future tests. While a test is awaiting cleanup, the plan row shows a Cleanup pending chip, a second test failover is refused with "A test failover is already active for this plan. Clean it up first.", and reopening the dialog shows a banner naming the date the pending test was started.
Execution History
Select a recovery plan to view its execution history -- a chronological list of all test, failover, and failback operations with their outcomes, timestamps, and any errors encountered. Test executions also show their boot screenshot thumbnails.
A Clear history action removes the past executions of the plan. It asks for confirmation first, because "Boot screenshots are deleted with them."; the active test execution is kept.
Emergency DR
The Emergency DR tab is designed for critical situations where you need to act fast without going through the full recovery plan workflow.
Emergency DR Mode allows you to:
- Start individual VMs on a target cluster directly from their most recent replication snapshot
- Execute immediate failover of an entire recovery plan, with Emergency Failover
- Open the failback of the plan a VM belongs to, with Failback to primary site on the VM row
This tab aggregates all replication jobs and recovery plans with quick-action buttons, giving operators a single view to manage a crisis.
The failback button here is a shortcut to the plan's failback, not a per-VM operation: it opens the same failback dialog described in Failback. A VM that belongs to no recovery plan shows it disabled, with "Failback unavailable -- VM is not part of a recovery plan". Emergency Failover is disabled for a plan that is already executing or already failed over.
Emergency operations bypass the normal validation steps. Use them only when time is critical and you understand the implications of starting replicated VMs without a full plan execution.
Replication and Ceph Alerts
Until v1.4.8 an alert threshold could only describe how full something was, so a replication job that fell behind, or failed outright, was visible on the Site Recovery page and nowhere else. The orchestrator now raises three alert types that concern this page, evaluated once a minute and surfaced on Alerts like any other. They are configured in Settings > Alert thresholds, under Performance & replication.
| Alert | Ships | Raised when |
|---|---|---|
| Replication RPO | Enabled, 25% grace | A job's last successful sync is older than its own RPO target plus the grace margin |
| Replication failures | Enabled | A job is in the error state |
| Ceph OSD latency | Disabled | An OSD answers slower than the threshold you set |
How the RPO Alert Judges a Job
The comparison is made against the RPO target of that job, not against a figure shared by the fleet, because a job set to 15 minutes and a job set to 24 hours have nothing in common. The grace margin is therefore a percentage of each job's own target, not a fixed delay: ten minutes late is meaningless against a 24 hour target and unacceptable against a 15 minute one.
With the default 25% grace, a job whose target is 15 minutes warns once its last successful sync is 18 minutes and 45 seconds old, and turns critical at twice that. A margin is needed at all because a job that is perfectly on time mechanically reaches its RPO just before each run: with no grace, every healthy job would alert.
A few cases are treated on purpose:
- A job that has never completed a sync is measured from the date it was created, so the most broken job in the fleet is not the only one that never alerts.
- A paused job and a failed-over job are exempt, and any RPO alert already raised on them is cleared. One was stopped by an operator, the other replicates in the opposite direction, so the original target no longer means anything.
- A job in the No matching VMs state keeps alerting. Its clock keeps running because a DR job protecting nothing is exactly what somebody needs to be told about.
- A calendar job is measured against the target derived from its schedule. A schedule from which no interval can be derived leaves the check with nothing to compare and it is skipped.
The Failure Alert
Raised as soon as a job enters the error state, and independent from the RPO alert: a job can fail without having missed its RPO yet, and can miss its RPO without ever being marked failed, for instance an unreachable source that leaves the job sitting in pending. It escalates with the retries: warning while attempts remain, critical once the three automatic retries are spent, since at that point nothing will restart on its own. The job's own error message is appended to the alert.
Deleting a job clears the alerts it had raised, and so does turning the corresponding family off in Settings > Alert thresholds, so a setting you switch off does not leave stale alerts active for ever. Recovery notifications are covered in Alerts.
These three alerts are produced by the orchestrator and read on the Alerts page, both of which are Enterprise. (Enterprise)
Failback
Failback brings a failed-over plan home. It is started from the Failback action in the plan's detail panel on the Recovery Plans tab, or from the shortcut on a VM row of the Emergency DR tab. Like a real failover, it asks you to type the plan name to confirm, under the title Execute Failback.
Failback runs in two phases, and the moment you switch from one to the other is yours to choose. Nothing cuts over on its own.
Phase 1: Reverse Replication
Starting the failback puts the plan in the Failing back state and opens a monitor headed "Reverse replication in progress". From then on ProxCenter replicates incrementally from the DR site back to the source, at the cadence of the job, while the DR VMs stay online and keep serving.
Before its first reverse pass, each VM's source disks are rolled back onto the most recent snapshot that both sides still have in common, so the reverse delta has a valid base. That rollback is automatic and per VM.
The monitor is a per-VM table:
| Column | Meaning |
|---|---|
| VM | The protected virtual machine |
| Last reverse sync | When the last reverse pass completed, or No reverse sync yet |
| Transferred | How much data the last pass moved |
The panel states the rule to follow: "Reverse replication is running while the DR VMs stay online. Trigger the cutover when the last sync is fresh enough."
You can close the dialog; the reverse replication keeps running on the orchestrator. While a plan is failing back, its detail panel offers only Open failback to come back to the monitor, and the other plan actions are gone. An orchestrator restart resumes the reverse replication by itself.
The byte counter reads the throughput of the transfer, which requires the pv package on the DR node. Without it the column stays empty. It does not affect the sync itself.
Phase 2: Cutover
When the last sync is fresh enough for the downtime you can afford, press Cutover. ProxCenter asks to confirm with "Stop the DR VMs, apply the final delta and start the source VMs?", then works through the VMs in the plan's boot order. Each one reports its step: Stopping the DR VM, Applying the final delta, Starting on the source site, Re-protecting.
When every VM is through, the dialog reports "Failback complete" and states that the source VMs are running and that replication protects them again in the original direction. The plan returns to Ready, and each replication job goes back to pending and resumes forward replication incrementally from the final delta. There is no full re-seed, and the lock on a job is released only once every VM of that job has completed its cutover.
Cutover readiness. The Cutover button stays disabled until every VM has completed at least one reverse sync, with the tooltip "Waiting for the first reverse sync of every VM". Beyond that first pass there is no automatic freshness threshold: judging when the remaining delta is small enough is the operator's call.
Cancelling. During phase 1, Cancel failback stops the reverse replication and returns the plan to failed over. It confirms first, and it is explicit that nothing is changed on the VMs. Once the cutover has started it can no longer be cancelled, only re-run.
Re-running an interrupted cutover. The cutover is safe to re-run: VMs that already completed it are skipped. If a VM's cutover fails after its DR VM was confirmed stopped, ProxCenter restarts that DR VM so it is not left down, marks the VM as failed with the step it died on, keeps the plan in Failing back, and resumes reverse replication so you can fix the cause and cut over again. The one case where the DR VM is deliberately left stopped is when the source VM was found unexpectedly running, because restarting the DR VM would create a split brain.
- The plan must be failed over. The Failback action is not disabled on a plan in any other state, so on a plan that has not failed over the dialog simply returns the error plan must be failed over to start failback.
- Each VM needs a mirror snapshot that still exists on both the DR and the source images of every one of its disks. When none survives, that VM reports that a full re-seed would be needed, which this version does not support.
- The source and DR images must live in the same Ceph pool. Cross-pool failback is not supported.
- A disk that carries a newer common snapshot than the plan-wide base has to have that stale snapshot removed first; the VM's error names it.
While a plan is failing back you cannot edit it, delete it ("Cancel the failback before deleting this plan."), run a test failover or a failover on it, clean up a pending test, or start a second failback. Each of those is refused with an explicit message rather than silently ignored.
Test failovers and real failovers send a notification; a failback does not. It does appear in the activity feed and in the plan's execution history.
HA Failback
The Failback switch described here belongs to Proxmox HA resources and has nothing to do with the disaster recovery failback above. One returns an HA resource to its preferred node inside a single cluster; the other brings a failed-over recovery plan back from the DR site.
The HA tab lets operators toggle Failback on individual HA resources. Use this when you want a resource to automatically return to its preferred node after the node becomes healthy again.
Failback is configured per resource rather than globally, so you can keep conservative behavior for stateful workloads while enabling automatic return for services that are safe to move back.
Orchestrator Resilience
Site Recovery, like every orchestrated feature, reaches Proxmox through the address configured on the connection. Since v1.4.7 the orchestrator no longer goes down with the node that address points at. After two consecutive network failures on a connection it probes the other nodes of the same cluster and continues against the first one that answers, then returns to the configured address as soon as that address answers again. The connection you configured is never rewritten. An HTTP error from a node that did answer is not a reason to move; only a genuinely unreachable node is.
It also addresses guest commands to the node that actually owns the guest, looked up from the cluster instead of assumed. Before v1.4.7, a replication job whose guest did not live on the configured node could not freeze that guest's filesystem, and the snapshot came out crash consistent instead of application consistent, with nothing in the log to say so.
Node addresses are discovered from the cluster and stored per node. A node that stops answering now keeps its recorded address: a failed discovery used to erase it, which removed that node from the failover candidates at the exact moment they mattered.
The failover applies to the Proxmox API calls. The SSH sessions Site Recovery uses, including the target of the RBD transfer itself, still resolve from the configured connection address, so a configured node that is down still stops a replication or a recovery run. Point the connection at an address that survives the loss of a single node, or expect to change it during an outage.
A connection marked Behind reverse proxy in Settings > Connections is deliberately excluded, because the point of that option is to reach the cluster through a DNS name and a certificate rather than through node IPs. Its helper text says so: "Disables failover to node IPs (use when accessing via DNS + reverse proxy with SSL)".
There is nothing to configure for any of this and no indicator in the interface: the orchestrator log is where a node failover is recorded.
Workflow Example
A typical Site Recovery workflow looks like this:
- Set up replication: Create replication jobs for your critical VMs, pointing to a secondary Proxmox cluster
- Create a recovery plan: Group the replication jobs into a recovery plan with the correct startup order
- Test regularly: Run test failovers monthly to validate that recovery works as expected, then clean up
- Respond to incidents: If the primary site fails, execute a failover from the Emergency DR tab or the Recovery Plans tab, picking a restore point per VM if the latest state is not the one you want
- Restore normal operations: Once the primary site is back, start a failback on the plan, let the reverse replication bring the source up to date, then trigger the cutover in a window you choose
Permissions
| Permission | Description |
|---|---|
automation.view | Required to open Site Recovery and read its jobs, plans, snapshots, executions, restore points and boot screenshots |
automation.manage | Required to act: create, edit, pause, resume, sync or delete a job, create or delete a plan, run a test failover, a failover, a cleanup or a failback |
Users without automation.view will not see the Site Recovery entry in the navigation sidebar. The entry is also shown only in the provider view, not in a tenant context, and it requires the Ceph replication feature of the Enterprise license.