--- title: "DRaaS: A Beginner’s Guide to Replication and Failover " description: NADcloud Disaster Recovery as a Service (DRaaS) uses Veeam Cloud Connect Replication to maintain recoverable replicas of your virtual machines in the NADcloud environment. If your production environment experiences an outage, selected replica VMs can be started in the NADcloud… url: "https://wiki.nad.cloud/docs/draas-a-beginners-guide-to-replication-and-failover/" updated: "2026-10-21" category: DRaaS --- # DRaaS: A Beginner’s Guide to Replication and Failover  NADcloud Disaster Recovery as a Service (DRaaS) uses Veeam Cloud Connect Replication to maintain recoverable replicas of your virtual machines in the NADcloud environment. If your production environment experiences an outage, selected replica VMs can be started in the NADcloud so that critical services can continue operating.  Replication alone does not constitute a complete disaster recovery plan. Before configuring replication, your organization should determine:  - Which VMs and services must be recovered.   - The order in which dependent systems must start.   - How much data loss is acceptable.   - How quickly services must be restored.   - Whether partial and full site failover will be supported.   - How users and external systems will reach services after failover.   - How workloads and data will eventually return to production.   This guide explains the planning decisions, networking components, replication configuration, failover options, testing requirements, and recovery processes associated with NADcloud DRaaS.  # ​​How Veeam Cloud Connect Replication Works  Veeam Cloud Connect Replication creates and maintains replicas of protected VMs on NADcloud infrastructure. During a disaster, a replica can be started from its latest restore point or, when appropriate, an earlier restore point.  When a replication job runs:  1. Your Veeam Backup & Replication server connects to the NADcloud gateway server.  2. The gateway server securely brokers the connection to the NADcloud’s Veeam infrastructure.   3. VM data is transferred through the cloud gateway to the cloud host.   4. Veeam updates the replica and creates a new restore point according to the job’s configuration.   The cloud gateway provides the external connection point; clients do not connect directly to NADcloud hypervisors or management systems. Veeam uses TLS to establish the connection between the tenant and service-provider Veeam servers. [Veeam documents the replication data flow here](https://helpcenter.veeam.com/docs/vbr/cloud/cloud_replication_hiw.html).  ![](/nraW3J/uploads/2026/10/Screenshot-2026-10-20-at-10.22.45-PM.png) # Recovery Objectives and Workload Selection  Before creating replication jobs, document an expected recovery point objective and recovery time objective for each protected service.  **Recovery point objective**  The recovery point objective, or RPO, represents the maximum acceptable amount of data loss measured in time.  For example, if a replication job runs every four hours, a disaster immediately before the next successful replication could result in approximately four hours of data loss. Actual exposure may be greater if the most recent job failed or did not complete before the outage.  When choosing a replication schedule, consider:  - The rate at which data changes  - Available internet bandwidth  - How long each replication cycle takes  - Whether replication overlaps business-critical traffic  - The acceptable amount of lost data  - The time required for the initial replication  **Recovery time objective**  The recovery time objective, or RTO, represents how quickly a service should be restored after an outage.  The RTO must account for more than VM boot time. It may include:  - Detecting and evaluating the incident.   - Authorizing failover.   - Selecting an appropriate restore point.   - Starting replica VMs.   - Waiting for dependent services to initialize.   - Updating DNS or external routing.   - Validating applications.   - Communicating access instructions to users.   **Workload dependencies**  Protect all infrastructure required for the recovered application to function. A web server replica may be unusable if its database, DNS, identity provider, file share, licensing server, or other dependencies remain unavailable.  For each application, identify:  - Required VMs.   - Startup sequence and delays.   - Internal and external dependencies.   - DNS requirements.   - Authentication dependencies.   - Required public services and ports.   - Application validation procedures.   - The responsible application owner.  # Planning Your Failover Strategies  Veeam Cloud Connect supports partial site failover and full site failover. These are different recovery scenarios and have different networking requirements.  | **Consideration**  | **Partial site failover**  | **Full site failover**  | | --- | --- | --- | | Typical scenario  | One or several workloads are unavailable while part of the production site remains operational  | The production site is substantially or completely unavailable  | | Recovery scope  | Selected replicas  | A predefined group of replicas  | | Process to initiate  | Fail over individual VMs; must be initiated by client  | Activate a cloud failover plan; can be initiated by client or NADcloud  | | Connectivity to surviving production VMs  | Provided through network extension appliances  | Generally not expected, because the production site is unavailable  | | Client-side network extension appliance  | Required for each production IP network that is involved  | May be omitted if partial failover will never be used  | | Public access  | All traffic, incoming and outgoing, is routed through your production network by network extension appliances  | Public IP and port rules can be included in the cloud failover plan, which will be implemented by the server-side network extension appliance  | | Considerations for workload dependencies  | Dependencies split between production and the NADcloud; communication made possible through network extension appliances  | Every required dependency must be made available in/from the NADcloud  | ## Partial Site Failover  Partial site failover is appropriate when one or more production VMs are unavailable but the remainder of the production environment is still operating.  For example, an application server may be failed over to the NADcloud while its database or domain controllers remain on-premises. The failed-over replica and surviving production systems communicate through a secure tunnel established by Veeam network extension appliances. You must configure a set of network extension appliances on the client side to perform a partial site failover, and failed over VMs must be assigned a static IP for successful communication post-failover. [See Veeam’s partial failover requirements](https://helpcenter.veeam.com/docs/vbr/cloud/performing_partial_failover.html).  Partial failover is useful for:  - Failure or corruption of an individual VM.   - Failure of a limited group of application servers.   - Planned maintenance affecting selected workloads.   - Testing or recovery scenarios in which other production dependencies remain available.  ![](/nraW3J/uploads/2026/10/Screenshot-2026-10-20-at-10.18.55-PM.png) ## Full site failover  Full site failover is intended for situations in which the production site is unavailable or cannot continue operating. VMs are recovered as a predefined group through a cloud failover plan, which defines VM startup and network settings.  All server or application dependencies must be available in the NADcloud replica environment or through another reachable external service. For example, if your application relies on internal DNS, you must replicate your internal DNS server to the NADcloud.  Veeam recommends creating the cloud failover plan in advance rather than attempting to assemble one during an outage. [See Veeam’s full site failover overview](https://helpcenter.veeam.com/docs/vbr/cloud/performing_full_site_failover.html).  ![](/nraW3J/uploads/2026/10/Screenshot-2026-10-20-at-10.21.13-PM.png) ## Network Extension Appliances  A network extension appliance (NEA) is a small Linux-based virtual appliance automatically deployed and managed by Veeam. It provides routing and network translation functions during cloud failover.  ### Client-side network extension appliance  The client-side NEA is used during partial site failover. It routes traffic between surviving production systems and replicas running in the NADcloud.  A separate client-side NEA must be configured for each production IP network that may contain a partially failed-over VM. Each appliance is connected to its corresponding production network and must receive a valid IP configuration. The appliance may obtain an address through DHCP, but a reserved or static address is generally preferable so that its configuration remains predictable.  If you plan to never perform partial failover, you may omit client-side appliances entirely.  [Veeam provides additional technical details about NEAs here](https://helpcenter.veeam.com/docs/vbr/cloud/cloud_network_extension_appliance.html?ver=13&utm_source=chatgpt.com).  ### NADcloud provider-side network extension appliance  NADcloud maintains a dedicated provider-side NEA for each DRaaS tenant. It has the following functionality:  - Connects replica networks to the NADcloud network.   - Establishes secure tunnels with client-side NEAs during partial failover.   - Separates tenant networks through assigned VLANs.   - Provides gateway services during full site failover.   - Applies public IP and port-forwarding rules.   Veeam automatically starts the provider-side NEA and applies the required networking configuration when you perform a partial or full site failover. For full site failovers specifically, the networking configuration is determined by your cloud failover plan.  # Configuring Replication  After [adding NADcloud as a service provider](https://nadadventist-my.sharepoint.com/:w:/g/personal/danielingold_nadadventist_org/IQCZaJcTi_SyQqyEnwAqjL-eAWKh9lUnKX_7N7x4qurMWZo), create replication jobs for the VMs that require DRaaS protection. To do this, from the Veeam Backup & Replication console, open the **Home** pane and choose **Replication Job > Virtual Machine** from the Home tab of the ribbon.  When configuring your jobs, review the following settings carefully:  ## Network remapping  Veeam can automatically detect networking for many Windows VMs. If you are only replicating Windows VMs and have a simple network, you may not need to configure network remapping.  However, if any of the following situations apply to you, explicit mapping will be required:  - Non-Windows VMs are included in the replication job, and you have more than one network.  - You have fewer networks allocated to you in the NADcloud than in your on-premises production infrastructure.  - The automatically selected mapping is not appropriate, or you find that more complex network arrangements are needed.   For partial failover, the replica generally retains the production VM’s internal IP identity while the NEAs route traffic between the extended networks. [See Veeam’s network-mapping behavior](https://helpcenter.veeam.com/docs/vbr/cloud/cloud_network_mapping.html).  NOTE: If explicit network remapping is required for your situation, and you have multiple Hyper-V hosts (clustered or not), you MUST configure network maps individually for each host.    For example, if you configure Host1/vSwitch1/VLANs 10 and 20 to map to Cloud Networks 1 and 2, you must also configure Host2/vSwitch1/VLANs 10 and 20 to map to Cloud Networks 1 and 2.  ## VM selection  Group VMs according to recovery priority, application dependency, replication schedule, and operational ownership. Avoid placing every VM in a single job if different services require different RPOs or maintenance schedules.  ## Cloud host and resource allocation  Select the NADcloud hardware plan assigned to your organization. Confirm that the allocated hardware plan provides sufficient resources to support your workload’s needs during a failover scenario.  ## Application-aware processing  Enable application-aware processing where appropriate, especially for workloads such as:  - Active Directory domain controllers.   - Microsoft SQL Server.   - Microsoft Exchange Server.   - Transactional or VSS-aware applications.   Application-aware processing improves application consistency and also provides Veeam with a more reliable way to collect Windows network settings.  ## Restore points  Configure an appropriate number of replica restore points. Multiple restore points provide alternatives if the latest replica contains corruption, an unwanted change, malware, or another problem copied from production.  ## Schedule and bandwidth  Choose a replication schedule that supports the required RPO without overwhelming your organization’s hardware or network resources.  The initial replication transfers substantially more data than subsequent incremental runs. Clients should consider:  - Available upload bandwidth.   - Dataset size.   - Change rate.   - Business-hour network utilization.   - Whether replication seeding is appropriate.   - How long the initial replica will take to complete.  ## Managing Default Gateways  When you perform your first replication job, Veeam will attempt to detect network settings from your replicated VMs and save information about the default gateways currently in use on your production networks. Gateway information is saved to the NADcloud for use when configuring the provider-side NEA after a full site failover.  After your first replication job, you should manually review the applied settings by opening the **Backup Infrastructure** pane, navigating to **Service Providers**, selecting **backup.nad.cloud**, and clicking **Manage Gateways** from the Cloud Connect tab of the ribbon. Edit these settings if needed.  This is also where you can select whether traffic should be routed between networks during a full site failover scenario.  ## Special Considerations for Non-Windows VMs  As mentioned above, if you have non-Windows VMs and more than one network, you will need to manually configure network remapping. However, after running a replication job, you might notice a warning: “No static IP addresses detected for VM, please specify default gateway settings manually.”  If you receive that warning, ensure that network remapping settings have been configured if you have more than one network. Also ensure that all affected VMs have a static IP address. If both conditions are met, the warning can safely be ignored.  You can instruct Veeam to suppress the warning by creating the following registry value on the Veeam backup server, then restarting the Veeam Backup Service:  **Key:** HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication  **Name:** CloudReplicaNoStaticIpSDetectedWarning  **Type:** REG_DWORD  **Data:** 0  # Cloud Failover Plans  A cloud failover plan defines a group of replica VMs that can be started together during full site failover as well as their networking settings. To create a cloud failover plan, from the Veeam Backup & Replication console, open the **Home** pane and choose **Failover Plan > Cloud Connect (Hyper-V)** from the Home tab of the ribbon.  Create plans around recoverable business services rather than simply grouping VMs by replication job. A plan might contain:  - Domain controllers and supporting infrastructure.   - Database servers.   - Application servers.   - Web or remote-access servers.   Veeam allows startup delays to be assigned to VMs. Without configured delays, the VMs start simultaneously. Delays should be used when one service must become operational before another starts – for example, starting a database server before its application servers. [See Veeam’s cloud failover plan configuration](https://helpcenter.veeam.com/docs/vbr/cloud/cloud_failover_plan.html).  For each plan, you should consider documenting:  - Business service protected.   - Included VMs.   - VM startup order and delays.   - Expected restore point selection.   - Required public IP mappings.   - Required DNS changes.   - Application validation steps.   - Who may authorize failover.   - Who must be notified.   - Criteria for undoing or committing failover.  Cloud failover plans can be initiated from the client-side through the Veeam Backup & Replication Console, or by the NADcloud when you submit a ticket.  ## Public IP Addresses  Replica VMs use the same private IP addresses within their NADcloud replica networks as configured for the VM in your on-premises production infrastructure. Services that must be reachable from the internet require public IP and port-mapping rules, which are configured as part of your cloud failover plan.  During full site failover, Veeam assigns an NADcloud-provided public IP to the provider-side NEA. The NEA then redirects traffic from the specified public IP and port to the replica’s internal IP address and service port.  For example:  | **Public endpoint**  | **Replica destination**  | **Purpose**  | | --- | --- | --- | | Public-IP:443  | 10.10.20.15:443  | HTTPS   | | Public-IP:53  | 10.10.20.20:53  | DNS  | | Public-IP:8022  | 10.10.20.25:22  | SSH *(see paragraph below)*  | Public IP rules should expose only the services required during failover. Clients are fully responsible for ensuring the security of any ports or applications that are exposed to the internet. Note that Veeam reserves port 22 to manage the provider-side NEA, so it cannot be used as a public IP mapping port. [See Veeam’s public IP rule documentation](https://helpcenter.veeam.com/docs/vbr/cloud/cloud_failover_plan_public_ip.html).  The NADcloud public IP will differ from the address used by your production service. Clients should therefore plan around:  - DNS record changes.   - DNS time-to-live values.   - External firewall or SaaS allowlists.   - Partner systems restricted by source or destination IP.   - Email security and SPF records, when applicable.   - Communicating alternate addresses to users.   As with any disaster recovery plan, we highly recommend testing and documenting your recovery procedures well before a disaster takes place, so you can identify any additional dependencies and avoid being caught off guard.  # Testing  Test every cloud failover plan after initial configuration and periodically thereafter by opening the **Home** pane, going to **Replicas > Failover Plans**, selecting the plan, and clicking **Test**.   Veeam’s built-in cloud failover plan test starts replicas from the latest restore point without switching production operations to those replicas. It verifies that the guest operating systems start, reach a stabilization point, and respond to ping. This is useful infrastructure validation, but it does not prove that the application itself works. [See Veeam’s test behavior and limitations](https://helpcenter.veeam.com/docs/vbr/cloud/testing_cloud_failover_plan.html).  A complete DR test should also validate items such as:  - Application services.   - Database consistency.   - DNS resolution.   - Authentication.   - Communication between application tiers.   - Public access.   - Administrative access.   - Required third-party integrations.   - Expected application data.   - Monitoring and alerting.   - Documented recovery time.   # Failover and Recovery Decisions  To start a failover if you have access to your Veeam Backup & Replication console, open the **Home** pane and go to **Replicas**. From there, you can perform a partial site failover by selecting the VM replica(s) you wish to failover to or perform a full site failover by selecting a failover plan.  When performing a full site failover through a failover plan, you’ll have the option to **Start** from the most recent replica or **Start to** a replica created before a certain point.  When selecting a partial site failover through individual VM replicas, you can **Failover now** to choose a restore point in the cloud, or **Planned failover** to perform an incremental replication run first (e.g. before regular maintenance).  If you do not have access to your Veeam Backup & Replication console, but you have previously configured a cloud failover plan, you may contact NADcloud support to request that the plan be activated.  For more information about [full site failover](https://helpcenter.veeam.com/docs/vbr/cloud/performing_full_site_failover.html) or [partial site failover](https://helpcenter.veeam.com/docs/vbr/cloud/performing_partial_site_failover.html), see Veeam’s documentation.  ## Recovery  After a replica starts, it operates in a failover state. The client must eventually choose one of the following outcomes:  ### Failback to production  Use failback when service has been restored at the production site and the workload should return there. Veeam transfers changes from the running replica back to the production environment before the production VM resumes operation.  After validating the production VM, commit the failback to finalize the operation. [See Veeam’s failback process](https://helpcenter.veeam.com/docs/vbr/cloud/performing_failback_to_production.html).  Failback may transfer a substantial amount of data. Available bandwidth, accumulated changes, production capacity, and the acceptable cutover window should be considered before beginning.  ### Undo failover  Use undo failover when the replica should be discarded and the original production VM should resume operation. Changes made to the replica while it was running are not preserved.  ### Permanent failover  Use permanent failover when the replica should become the accepted production VM. This commits the workload to the NADcloud environment, excludes the original VM from its old replication job, and ends the temporary failover state. Permanent failover should only be selected after receiving approval from the NADcloud team.  # See Also  [Configuring the NADcloud as a Service Provider for BaaS or DRaaS in Veeam](https://nadadventist-my.sharepoint.com/:w:/g/personal/danielingold_nadadventist_org/IQCZaJcTi_SyQqyEnwAqjL-eAWKh9lUnKX_7N7x4qurMWZo)  # Additional Resources  [Veeam Cloud Connect Guide for Tenants – Using Cloud Hosts](https://helpcenter.veeam.com/docs/vbr/cloud/using_cloud_connect_replica.html)