TL;DR
VCF Protection and Recovery 9.1 changes disaster recovery from a service that infrastructure administrators configure manually into a capability that organization administrators, project administrators, and authorized users can consume through VCF Automation.
That does not mean every tenant should be allowed to create arbitrary replication relationships, reserve unlimited recovery capacity, or initiate a production failover without oversight.
A sustainable self-service disaster recovery service needs separate controls for:
- requesting protection
- selecting an approved replication class
- consuming recovery-site capacity
- defining network and IP mappings
- creating and testing recovery plans
- authorizing planned migrations and emergency failovers
- recording costs and audit evidence
- retiring protection when the workload is decommissioned
The right mental model is not unrestricted self-service. It is delegated disaster recovery inside a provider-defined service boundary.
Introduction
Traditional disaster recovery often begins with an infrastructure ticket.
An application owner identifies a workload that needs protection, submits a request, waits for a virtualization or storage administrator, answers questions about recovery objectives, and eventually receives confirmation that replication has been configured.
The technical work may be straightforward. The operating model is not.
Every request creates coordination across application owners, infrastructure teams, network administrators, security teams, capacity planners, and business continuity stakeholders. As the number of protected applications grows, the ticket queue becomes part of the recovery architecture.
VCF Protection and Recovery 9.1 begins to change that model. Through VCF Automation, authorized organization users can configure VM-level replication, while provider and organization administrators establish the underlying regions, namespace relationships, infrastructure, replication classes, and governance boundaries. VCF 9.1 also introduces foundational multi-tenant disaster recovery for Supervisor VM Service VMs in VCF-to-VCF protection scenarios.
That is a meaningful shift.
It moves disaster recovery closer to the application team. It also introduces a risk that many self-service platforms eventually encounter: a faster request path can create resources more quickly than the organization can govern them.
The design objective is therefore not simply to make replication available in a portal. It is to create a disaster recovery service that gives application teams useful autonomy without giving away control of recovery capacity, network topology, incident authority, or organizational risk.
Self-Service DR Changes Decision Rights
Self-service disaster recovery is often described as an automation improvement. It is more accurately an operating-model change.
The technical workflow may start with a user selecting a VM and a replication class, but the real change is that several decisions move away from a centralized infrastructure team.
Those decisions include:
- which workloads should be protected
- which recovery tier they should consume
- which recovery region should receive the replica
- how much capacity should be reserved
- which network the recovered workload should use
- who can test the recovery plan
- who can declare a disaster
- who pays for the service
- when the protection relationship should be removed
These are not all the same kind of decision.
A platform can safely delegate a repeatable protection request while retaining tighter control over recovery execution. It can allow an organization administrator to pair namespaces while preventing an ordinary project user from changing provider-level mappings. It can let an application team test its workload without granting that team authority to redirect production traffic during an enterprise incident.
The first governance principle is therefore simple:
Permission to request protection is not permission to declare a disaster.
Without that separation, self-service reduces ticket volume by transferring operational risk to users who may not understand the full application, network, capacity, and business-continuity consequences of their actions.
The Multi-Tenant Recovery Scenario
Consider a VCF environment serving three internal organizations:
- a payments organization operating revenue-critical applications
- an engineering organization running development and internal platforms
- a corporate services organization operating shared business systems
All three organizations consume infrastructure through VCF Automation. Each has its own namespaces, users, network boundaries, quotas, and service entitlements.
The platform team operates a shared recovery region.
The payments organization expects short RPOs, pre-reserved compute, quarterly recovery tests, and a tightly controlled failover process. Engineering needs protection for selected platform services but can tolerate longer recovery times. Corporate services requires protection for several critical systems, but not every VM in the organization.
A shared recovery platform can support all three. It should not treat all three the same.
The service must allow each organization to consume an appropriate protection tier while preserving provider control over the scarce resources and high-risk actions that affect the whole recovery region.
Architecture at a Glance
The architecture separates the consumption request from the controls that make the request safe.
The important boundary is the policy layer in the center.
VCF Automation provides the consumption interface, but the platform team still defines which services exist, who can use them, what infrastructure they consume, and which controls apply. VCF Protection and Recovery performs replication and recovery orchestration, but it should not become the only place where ownership, approval, cost, and business priority are recorded.
Scope and Terminology Guardrails
Several terms must remain separate for the service model to stay understandable.
Self-Service Protection
Self-service protection means an authorized user can request or configure protection for an eligible workload without waiting for an infrastructure administrator to perform every UI action.
It does not automatically mean the user can:
- create provider-level site relationships
- modify shared recovery infrastructure
- consume unlimited target capacity
- change organization-wide mappings
- run an unapproved production failover
- declare an enterprise disaster
Disaster Recovery
Disaster recovery restores an application after a site, region, infrastructure, or workload-level disruption. It normally assumes that the replicated workload is operationally trustworthy.
Cyber Recovery
Cyber recovery determines whether a recovery point is clean before returning it to production. It introduces isolated recovery environments, malware analysis, identity separation, controlled connectivity, and clean-point validation.
Tenant-aware replication is not a replacement for cyber recovery.
A workload can be replicated successfully and still carry corrupted data, malicious persistence, compromised credentials, or application-level damage into the recovery region.
Recovery Point Objective
RPO defines the acceptable potential data-loss window. In VCF Automation protection workflows, users consume approved replication classes rather than inventing an arbitrary replication policy for every VM.
Recovery Time Objective
RTO is the target time for restoring the business service.
Replication does not establish the RTO by itself. Application dependencies, boot order, network readiness, DNS, identity, database recovery, external integrations, validation, and business approval all contribute to the actual recovery time.
Recovery Capacity
Recovery capacity includes more than datastore space for replicas.
It includes:
- compute needed to power on recovered workloads
- memory reservations
- storage performance
- network throughput
- IP address availability
- load-balancing capacity
- security enforcement
- test recovery capacity
- platform overhead
- operational headroom
Design Assumptions
This operating model assumes:
- VMware Cloud Foundation 9.1 is deployed across multiple regions managed through VCF Automation.
- Protection and Recovery appliances are deployed and paired between the participating sites.
- Required Layer 3 connectivity exists between the protection and recovery components.
- A Supervisor is deployed where VM Service VM protection is required.
- Namespace relationships and recovery network mappings are configured before organization users consume the service.
- The recovery region is shared but still enforces organization and network isolation.
- Application teams retain responsibility for application dependency documentation and functional validation.
- The article covers disaster recovery service design, not ransomware clean-room design.
- Product behavior and known issues are validated against the current 9.1 release notes before production deployment.
- Research and product validation are current as of August 2, 2026.
The Provider and Consumer Responsibility Model
VCF Automation introduces a layered administration model. The most useful design assigns each layer only the decisions it can safely own.
| Role | Primary responsibilities | Decisions that should remain restricted |
|---|---|---|
| Provider administrator | Deploys and operates the protection infrastructure, establishes site connectivity, creates regions, assigns organization capacity, exposes replication classes, and maintains provider-wide controls | Tenant application priority, business validation, and unilateral application failover decisions |
| Organization administrator | Pairs eligible namespaces, assigns organization users, selects available policies, maintains application ownership, and coordinates organization-level recovery requirements | Provider infrastructure, cross-organization mappings, and recovery-region capacity policy |
| Project administrator | Manages protection within an approved project or namespace boundary and helps maintain workload metadata | Changes affecting other projects, organizations, or provider mappings |
| Organization user | Creates protected VMs or configures replication for eligible existing VMs using approved service choices | Site pairing, unrestricted capacity changes, shared network configuration, and unapproved production failover |
| Application owner | Defines dependencies, startup order, validation steps, business priority, and acceptable data loss | Provider capacity allocation and recovery platform administration |
| Incident commander or continuity authority | Authorizes emergency production recovery based on business impact and incident scope | Routine protection configuration |
| Security incident authority | Determines whether disaster recovery is appropriate or whether cyber-recovery procedures are required | Normal platform service administration |
This separation prevents the common mistake of reducing the entire service to two roles: administrator and user.
The organization administrator is an important middle layer. Provider administrators should not need to understand every application dependency, but ordinary organization users should not control the organization’s recovery topology.
Protection Should Be Offered as a Platform Service
A platform service is more than a UI action.
It is a defined product with eligibility rules, service objectives, ownership, capacity, support expectations, lifecycle controls, and cost.
A self-service DR offering should contain at least the following fields:
| Service field | Purpose |
|---|---|
| Service name | Gives users a recognizable recovery product |
| Eligible workload types | Defines traditional VM and VM Service VM support boundaries |
| Replication class | Controls the RPO choices exposed to the organization |
| Target recovery region | Identifies the approved destination |
| Capacity class | Defines reserved, pooled, or best-effort recovery resources |
| Network mapping profile | Maps production, test, and recovery connectivity |
| Recovery-plan requirement | Determines whether protection can exist without an approved plan |
| Test frequency | Establishes recurring validation |
| Failover authority | Identifies who can approve production recovery |
| Cost center | Connects consumption to financial accountability |
| Service owner | Identifies the accountable business or application owner |
| Expiration or review date | Prevents permanent orphaned protection |
| Support model | Defines response and escalation expectations |
A user should not be asked to understand the underlying appliance topology each time protection is requested. The platform team should translate that complexity into a small number of service classes.
RPO and RTO Service Tiers
Broadcom’s VCF Automation documentation uses replication classes to control the frequency available to users. Its example Gold class replicates every five minutes. Enhanced vSphere Replication can support RPOs as low as one minute in appropriately licensed and designed environments.
That does not mean every organization should receive the lowest available RPO.
Lower RPOs increase replication activity, network demand, storage writes, monitoring volume, and operational expectations. A service tier should therefore connect the replication class to the complete recovery commitment.
The following catalog is illustrative and is not a set of VMware defaults.
| Service tier | Example RPO | Target RTO | Recovery capacity | Testing | Typical use |
|---|---|---|---|---|---|
| Critical | 5 minutes | 60 minutes | Pre-reserved | Quarterly | Revenue, customer-facing, or regulated services |
| Important | 30 minutes | 4 hours | Pooled with committed priority | Twice yearly | Major internal platforms and business systems |
| Standard | 4 hours | 24 hours | Best effort after higher tiers | Annually | Noncritical internal workloads |
| Protection only | Defined by approved class | No application RTO | Replica capacity only | Replication validation | Workloads not yet accepted into an orchestrated recovery service |
The final row is intentionally uncomfortable.
Many environments have replicated VMs that do not have a tested application recovery plan. Calling those workloads “DR protected” creates false confidence. A more honest catalog labels them as data replicated or protection only until the application has a validated recovery process.
RPO and RTO Must Be Sold Together
A five-minute replica does not create a one-hour application recovery.
An application may require:
- directory services
- DNS updates
- database recovery
- certificate services
- message queues
- API dependencies
- firewall changes
- external SaaS connectivity
- load-balancer configuration
- application-owner testing
The service tier should state both the data objective and the service restoration objective. It should also record which dependencies are included in the commitment.
Recovery-Site Quotas and Reservations
VCF Automation region quotas provide a useful organizational boundary for compute and storage consumption. However, normal cloud capacity and disaster-recovery capacity answer different questions.
A production quota answers:
How much infrastructure can this organization deploy?
A recovery reservation answers:
How much infrastructure will be available when the source environment is unavailable?
The second question is harder because the organization may need capacity precisely when many other tenants also need it.
Choose an Explicit Recovery Capacity Model
A shared recovery region normally uses one of three models.
| Capacity model | Description | Main tradeoff |
|---|---|---|
| Fully reserved | Capacity exists for all protected workloads to run simultaneously | Strongest recovery confidence, highest cost |
| Priority reserved | Capacity is guaranteed for selected services, with the remainder pooled | Balances cost and recovery priority |
| Oversubscribed | Replica storage is committed, but recovery compute is allocated during an event | Lowest cost, highest contention risk |
Oversubscription is not automatically wrong.
It becomes dangerous when the organization sells a guaranteed RTO while operating a best-effort capacity model. The service description must match the actual reservation posture.
Include Test Capacity
Recovery testing consumes real infrastructure.
A platform that reserves enough compute for an emergency failover but no capacity for regular testing will gradually become untested. Include a test-concurrency allowance in the capacity model.
A practical reservation calculation includes:
- committed production failover capacity
- concurrent recovery-test capacity
- Protection and Recovery platform overhead
- network and security service capacity
- operational safety margin
- expected growth before the next capacity review
Protect the Recovery Region from Noisy Tenants
Quotas should control more than the number of protected VMs.
Consider limits for:
- protected vCPU and memory
- replica storage
- daily changed-block volume
- concurrent initial synchronizations
- concurrent test recoveries
- concurrent reprotect operations
- recovery-plan execution
- retained test environments
- recovery network and IP consumption
This turns the recovery region into a governed shared platform rather than a datastore where every organization sends replicas.
Network and IP Mapping Are Part of the Service
Replication can complete successfully while recovery still fails because the network was never designed.
VCF Protection and Recovery includes workflows for namespace pairing, network mappings, test network mappings, and IP customization. Those capabilities need a provider-defined model.
Production Recovery Networks
For each organization, define:
- source network
- recovery network
- routing behavior
- firewall policy
- gateway ownership
- IP preservation or reassignment
- DNS update process
- load-balancer behavior
- external connectivity
- return-path routing
Do not make network mapping a free-form choice for every user. Publish approved mapping profiles and allow users to select only the profiles assigned to their organization.
Test Recovery Networks
A test recovery should not accidentally connect a duplicate application to the production network.
Test networks should be:
- isolated from production
- isolated between tenants where required
- able to provide controlled supporting services
- observable by the platform team
- cleaned up after testing
- protected from uncontrolled outbound communication
The application team should know whether the test environment uses simulated dependencies, test copies, or controlled access to production-adjacent services.
IP Address Strategy
There are three common approaches:
- preserve the production IP and move the network identity
- assign a recovery-specific IP
- use an abstraction such as DNS, load balancing, or application routing
The correct approach depends on distance, routing architecture, NSX design, application behavior, and external dependencies. It should be decided during onboarding, not during the outage.
Recovery Plans Need Named Owners
A recovery plan is both an orchestration artifact and an operational contract.
The platform team may create the execution framework, but it cannot independently determine whether an application is healthy. The application team understands the business service, but it may not understand infrastructure sequencing or shared recovery constraints.
Ownership should therefore be split.
| Recovery-plan concern | Accountable owner |
|---|---|
| Protection infrastructure | Provider or recovery platform owner |
| VM membership | Application and project owner |
| Startup and shutdown order | Application owner |
| Network mappings | Network and recovery platform owners |
| Infrastructure dependencies | Platform owner |
| Application dependencies | Application owner |
| Test execution | Joint platform and application ownership |
| Functional validation | Application owner |
| Emergency failover authorization | Incident or continuity authority |
| Cyber incident decision | Security incident authority |
| Reprotect and failback | Joint platform, application, and change ownership |
No recovery plan should enter production without:
- a business owner
- a technical owner
- a recovery tier
- dependency documentation
- network mappings
- an approval path
- validation criteria
- a test schedule
- a failback procedure
Failover Approval Is a Separate Control Plane
VCF Automation provides approval policies for deployment and day-two requests. That makes it a useful governance layer, but architects should not assume that every Protection and Recovery action automatically enters the same approval path.
Validate the exact behavior in the deployed VCF 9.1 build.
When a sensitive recovery action is not natively covered by the required approval policy, place it behind an orchestrated workflow, IT service-management process, or restricted recovery role.
A practical authorization model looks like this:
| Action | Recommended authority |
|---|---|
| Request protection | Authorized organization or project user |
| Change replication class | Organization administrator, within entitlement |
| Pair namespaces | Organization administrator |
| Modify provider mappings | Provider administrator |
| Run isolated recovery test | Application owner and delegated recovery operator |
| Run planned migration | Change authority, application owner, and recovery operator |
| Run emergency disaster failover | Incident commander or continuity authority |
| Initiate cyber-recovery process | Security incident authority |
| Reprotect workload | Recovery operator with application confirmation |
| Fail back to production | Change authority, application owner, and recovery operator |
Use a Two-Key Model for Production Recovery
For critical workloads, separate:
- the authority to approve recovery
- the technical permission to execute recovery
The incident commander should not need broad administrative credentials. The recovery administrator should not be able to declare a business disaster independently.
The two-key model reduces accidental failovers, malicious misuse, and confusion during high-pressure incidents.
Tenant Isolation Must Survive Recovery
A shared recovery site does not remove tenant boundaries.
The recovery design must preserve isolation across several layers.
Identity Isolation
Use organization and project roles that align to actual support responsibilities. Avoid shared recovery administrator credentials across unrelated application teams.
Emergency access should be controlled, logged, time-limited where possible, and reviewed after use.
Network Isolation
Each organization’s recovery and test networks should remain separate unless an approved shared service requires connectivity.
Shared DNS, identity, monitoring, or security services should be exposed through controlled paths rather than broad network adjacency.
Resource Isolation
A tenant should not be able to exhaust recovery compute, storage, replication bandwidth, test capacity, or IP space needed by another tenant.
Quotas and concurrency limits should enforce this boundary.
Operational Isolation
Users should see only their authorized workloads, mappings, plans, reports, and recovery operations.
A multi-tenant platform can share infrastructure without sharing operational visibility.
Failure-Domain Isolation
Do not place all tenants behind one unexamined dependency.
Shared recovery services such as DNS, identity, routing, load balancing, and automation appliances need their own resilience and recovery design. Otherwise, the shared recovery region becomes dependent on a small set of unprotected control-plane services.
Cost Allocation and Showback
Self-service without cost visibility encourages overconsumption.
VCF Automation and VCF Operations provide organization and project cost visibility, pricing mechanisms, chargeback capabilities, and showback dashboards. The DR service should use those capabilities to make recovery consumption visible.
Charge for the Service Actually Consumed
A useful DR cost model includes:
- protected storage capacity
- replica storage capacity
- replication change rate
- network transfer
- reserved recovery compute
- shared platform overhead
- test recovery runtime
- premium operational support
- security or compliance requirements
- retention and reporting requirements
The showback record should identify:
- organization
- project or namespace
- application
- business owner
- cost center
- protection tier
- protected capacity
- reserved failover capacity
- test consumption
- current recovery status
Separate Replica Cost from Recovery Commitment
Two applications with the same storage footprint may have very different recovery costs.
One may use pooled capacity and a 24-hour RTO. Another may require dedicated compute, a five-minute RPO, quarterly testing, 24-hour operator coverage, and a one-hour RTO.
Charging only by protected terabyte hides the cost of the operational commitment.
Use Showback Before Chargeback
Many enterprises should begin with showback.
Show teams what their protection consumes, identify stale and duplicated protection, and validate the cost model before turning the numbers into formal chargeback. The objective is accountable consumption, not creating arguments over an immature pricing model.
Audit Evidence and Recovery Testing
A disaster recovery service is credible only when it can produce evidence.
VCF Protection and Recovery supports recovery-plan testing and recovery-plan history reporting. VCF Automation and the wider VCF operations layer also provide audit and operational records.
The platform team should assemble those records into a standard evidence package.
Minimum Evidence Package
For every protected business service, retain:
- original protection request
- workload owner and approver
- selected replication class
- recovery target
- namespace pairing
- network and IP mappings
- capacity assignment
- recovery-plan version
- test execution history
- recovery-plan history report
- application validation result
- failed steps and exceptions
- remediation owner
- next test date
- last entitlement review
- last cost review
Test the Business Service, Not Just the VM
A powered-on VM is not proof of application recovery.
A test should validate:
- operating-system startup
- database consistency
- service dependencies
- authentication
- DNS and routing
- firewall policy
- application transactions
- monitoring
- backup or protection after recovery
- user acceptance criteria
The application owner should sign off on the result. Infrastructure teams should not certify application functionality on the owner’s behalf.
Vary the Test Scenario
Do not repeat the easiest recovery test every quarter.
Rotate scenarios such as:
- single-VM failure
- complete application recovery
- namespace recovery
- source-cluster loss
- site loss
- dependency unavailable
- constrained recovery capacity
- failed network mapping
- application startup failure
- reprotect and failback
The purpose of testing is not to create a green dashboard. It is to discover which assumptions are wrong before an incident.
Preventing Uncontrolled Recovery Sprawl
Recovery sprawl appears when protection is easy to create but difficult to review or remove.
Typical symptoms include:
- replicas for retired VMs
- protection without an owner
- critical tiers assigned to noncritical workloads
- recovery plans that have never been tested
- orphaned network mappings
- stale IP customization rules
- reservations that exceed realistic demand
- duplicate protection services
- workloads with no failback plan
- unresolved RPO violations
- organization users who retain access after changing roles
The service needs a lifecycle, not just a create action.
Require Protection Metadata
Do not allow long-lived protection without:
- owner
- application identifier
- business criticality
- cost center
- service tier
- recovery-plan reference
- test frequency
- review date
- retirement trigger
Add Expiration and Renewal
Protection should have a review date.
Renewal can be automatic for critical approved services, but it should still verify ownership, cost, application status, test results, and tier suitability.
Temporary environments should use explicit expiration dates.
Reconcile Protection Against Inventory
Regularly compare:
- active VMs
- protected VMs
- replicas
- recovery-plan membership
- application inventory
- organization membership
- cost-center status
The reconciliation process should identify both unprotected critical workloads and protected workloads that no longer need the service.
A Phased Implementation Path
A successful rollout should begin with service design, not with granting users access.
Define the Service
Document:
- supported workload types
- service tiers
- replication classes
- RTO commitments
- capacity models
- network profiles
- approval requirements
- testing expectations
- cost model
- support responsibilities
- retirement rules
Do not expose a generic “enable replication” action before these decisions are complete.
Build the Provider Foundation
The provider team should:
- deploy and validate Protection and Recovery components
- establish site connectivity
- configure recovery infrastructure
- define regions and quotas
- create replication classes
- confirm organization and project roles
- define namespace-pairing standards
- build recovery and test networks
- establish observability
- test provider-level failure scenarios
Pilot with Two Different Tenants
Choose tenants with different recovery requirements.
For example:
- one critical production application
- one lower-priority internal application
This tests whether the catalog can express meaningful differences rather than treating every workload as the same service.
Validate the Complete Lifecycle
The pilot should include:
- protection request
- initial synchronization
- RPO monitoring
- isolated test
- application validation
- production-style recovery exercise
- reprotect
- failback
- service renewal
- service removal
A pilot that ends after successful replication has not tested the operating model.
Scale Through Entitlements
After the pilot, publish approved service tiers to additional organizations.
Use organization assignments, quotas, roles, and policy controls rather than recreating the service manually for every team.
Add Cost and Compliance Reporting
Introduce showback, recurring evidence packages, exception reporting, and capacity forecasting after the technical workflow is stable.
These functions should become normal platform operations, not annual audit projects.
Risks, Caveats, and Operational Gotchas
Foundational Does Not Mean Complete
VCF 9.1 introduces foundational multi-tenant disaster recovery for Supervisor VM Service VMs. Treat that wording seriously.
Confirm workload, storage, networking, application-consistency, and orchestration requirements before assuming that every modern application pattern has the same protection behavior as a traditional VM.
The Self-Service Workflow Is Not a Retention Strategy
The VCF Automation replication workflow documentation states that only one replica copy is retained at the secondary site for the described workflow.
Organizations requiring deep recovery-point history, long-term retention, or ransomware clean-point selection need additional protection design. Do not treat a current replica as a substitute for backup or cyber recovery.
Reprotect Preserves the Replication Class
The documented reprotect workflow retains the replication class used by the recovered VM.
If the application needs a different service tier after recovery, plan the policy transition rather than assuming it can be changed during reprotect.
Application Consistency Remains an Application Concern
VM replication does not automatically guarantee transactional consistency across a distributed application.
Database-native protection, quiescing, application agents, coordinated shutdown, or application-level replication may still be required.
Shared Infrastructure Creates Shared Failure Modes
A shared recovery region concentrates:
- capacity risk
- network dependencies
- administrative access
- appliance dependencies
- operational workload during an incident
Design the recovery platform itself as a critical service.
Concurrent Recovery Operations Need Testing
Large numbers of tenants, namespaces, replications, tests, and reprotect actions create concurrency that a small pilot will not reveal.
Review current release notes, establish operational concurrency limits, and test the expected recovery scale before committing to tenant RTOs.
Removal Is a Controlled Operation
Decommissioning a service requires more than deleting a catalog entitlement.
Remove or reconcile:
- replication
- replicas
- recovery-plan membership
- mappings
- reservations
- test resources
- cost records
- user entitlements
- application inventory records
Platform lifecycle operations can fail or leave orphaned objects when dependencies remain. Build deprotection into the service workflow.
Decision Checklist
Before enabling self-service DR for an organization, confirm:
| Decision | Required answer |
|---|---|
| Who owns the application? | Named business and technical owners |
| What protection tier applies? | Approved RPO, RTO, test frequency, and capacity class |
| Is the workload eligible? | Supported VM type, storage, site, and namespace |
| Where does it recover? | Named region, cluster, datastore, and network profile |
| Is capacity committed? | Reservation or documented oversubscription policy |
| Are dependencies mapped? | Infrastructure and application dependencies documented |
| Is recovery authorized separately? | Named test, planned migration, disaster, and cyber authorities |
| Is the recovery plan tested? | Current evidence and application-owner sign-off |
| Is cost visible? | Organization, project, application, and cost-center mapping |
| Is there an expiration or review date? | Renewal and retirement workflow defined |
| Is failback documented? | Reprotect, validation, cutback, and cleanup steps defined |
| Are current release limitations accepted? | Product and concurrency caveats reviewed |
Conclusion
Self-service disaster recovery can remove a major infrastructure bottleneck, but only when protection is delivered as a governed platform service.
VCF Protection and Recovery 9.1 and VCF Automation provide the technical foundation for organization-aware replication, namespace pairing, recovery workflows, replication classes, shared recovery infrastructure, and foundational protection for VM Service VMs. Those capabilities allow platform teams to move routine protection closer to the application teams that understand the workloads.
The platform team should still retain control over the boundaries that affect everyone: site architecture, capacity, provider mappings, service entitlements, network profiles, security controls, and operational concurrency. Application teams should own dependency information and functional validation. Incident and continuity authorities should control the decision to run a production failover.
The most important separation is between requesting protection and authorizing recovery.
When that separation is combined with RPO and RTO tiers, capacity reservations, tenant isolation, network mapping, showback, audit evidence, regular testing, and lifecycle controls, self-service becomes a scalable recovery operating model.
Without those controls, it becomes a faster way to create recovery sprawl.
This mental model also provides the operating-model bridge to two related design questions: how VCF Protection and Recovery capabilities fit together as a platform, and how a shared recovery site should be sized for multiple clusters, storage platforms, and tenants.
