Performing a local disaster recovery test
The purpose of this article is to outline performing disaster recovery (DR) tests with Datto BCDR appliances that are not part of a scheduled offsite virtualization DR test.
Environment 
- Datto SIRIS
Description
IMPORTANT Datto support is best effort for DR Tests outside of the offsite virtualization DR test procedure. Datto support is only responsible for troubleshooting the functionality of the device and its features. Datto support is not responsible for the success of the test if your Datto device is proven to be fully functional.
Requirements 
- You are testing virtualizations only. Tests of system recovery options (Bare Metal Restore, Rapid Rollback, Image Export, ESX Upload) both locally or offsite are not supported.
- The device is appropriately sized for the test you are performing.
- You should never exceed five protected systems for any local DR test, due to IO concerns. If you wish to perform a test greater than five, you must request an offsite DR test.
- SIRIS Business tier - 2 protected system max
- SIRIS Professional tier - 3 protected system max
- SIRIS Enterprise tier - 5 protected system max
- Your device has the resources available to perform a test. Datto recommends leaving 50% of cores and RAM available on the device.
- Your production network and systems are suggested to remaining online. Bringing down the actual production network or systems is considered a fire drill test. Refer to the Fire Drill section for more information.
- You are not bridging the virtualization to the live network. This configuration introduces the possibility of production data being written to a test server and may cause data loss.
- When you test with networking enabled, your production network should not be utilizing any IP address in the 172.16.175.160/27, 172.16.182.192/27, or 172.16.183.192/27 subnets, to avoid any potential conflicts with the IP address schemes used by local virtualizations on the Datto device.
- You can run successful screenshots for all the machines you are testing.
- See Best practices for Local Virtualizations for more information.
Tests
- Bootability tests - a test to ensure a machine will boot. This should not typically be needed, as screenshot verification already provides this confirmation.
- Functionality test - a test to ensure that a booted machine can perform non-networking related tasks. Ensure that you only utilize resources required to run the application
- Network test w/ no internet - test to ensure a device can access networking services needed.
Network test w/ internet - test to ensure networking access and internet access are available. Ensure none of the systems being brought online carry the risk of conflict with production systems due to their internet access.
Fire Drills Datto strongly advises against "Fire Drill" DR tests, which are DR tests performed on an organization's production systems and networks. (Standard DR testing recommended by Datto is not done in a production setting, and therefore isolates risk from an organization's business.)
The risks and damage that can stem from Fire Drill DR testing is significant and include, by way of example and not limitation:
- lost data, which is not recaptured in the production environment
- IP confusion among servers, which can result in lost access, functionality, or even the shutdown of entire networks
- Third parties responding to the Fire Drill as if it were a true DR event
- Broken integrations with third party applications and/or inadvertent DR responses from such third parties.
By proceeding with a requested Fire Drill, you acknowledge these risks and accept the responsibility of any damage stemming from the Fire Drill. You understand that Datto advises against the Fire Drill, and Datto shall not be liable for any damage or claim based on your decision to DR Test in a Fire Drill setting.
Network test with no internet connection Building the Virtualization
Repeat this procedure for each VM you wish to create.
Sign in to the Remote Web and click the Restore tab.
Select a protected machine, then Local Virtualization, then a recovery point.
Select resources to allocate to the VM.
- Make sure the RAM is a multiple of 1024 (e.g., 1 GB is entered as 1024, 4GB is 4096, etc.).
- Leave at least one core and 1 GB of free RAM unallocated for the Datto to operate.
- Leave as many free resources as possible.
- Uncheck the Create Rescue Agent option unless you wish to take backups of your local virtualization. You should not usually create a rescue agent for a test.
Change Network Options to Firewalled on a private subnet with no internet access.
Click APPLY.
Click Start VM to start the virtualization. A Screenshot of the VM will appear. Click Open in browser to go to the login screen.
Running the test
Sign into each VM as it reaches the login screen. Allow several minutes or more for the VM to fully boot once logged in. The VM will install new virtual hardware drivers; you may need to reboot it as part of the install process.
On the protected machine's command line, Find the DHCP address of each VM on the private network by running the following command:
- Windows:
ipconfig /all - Linux:
ifconfig -all
- Windows:
Make a note of each DHCP address.
- 172.16.182.x is the IP scheme used for Private Subnet with no Internet. To avoid any potential for interruption, ensure your live network is not on the same scheme.
- The VM should automatically assign an IP address using DHCP; if not, configure network settings for DHCP.
From the command line of the protected machine, ping the IP address assigned to each VM's LAN interface to verify connectivity. If the machine does not get ping replies, make sure the firewall on the VM failing to reply is set to allow ICMP responses on all kinds of networks (public, private, domain): http://www.howtogeek.com/77132/how-to-enable-ping-echo-replies-in-windows-8/(external link).
Test any proprietary software you are using.
Network test with an internet connection Follow these steps to perform a sandboxed local virtualization with internet connectivity:
From the Datto Remote Web, click the Restore tab.
Select the protected system you would like to restore.
Choose the Local Virtualization recovery type. For virtual appliances, click Virtualize via Hypervisor.
Select the Recovery Point to restore.
Select Start Restore.
You will be redirected to the Local Virtualization page (titled Virtualize via Hypervisor for virtual appliances).
Set the Local Options for the virtualization. In the Network Options, select Firewalled on Private Subnet.
Click APPLY.
Uncheck the Create Rescue Agent option unless you wish to take backups of your local virtualization (not recommended for a test).
Click Start VM.
Click Open in browser to connect to your virtualization via a browser-based VNC session (recommended). Then, proceed to Step 11 of this article. If you prefer to use RDP to connect to the virtualization, see Step 10 of this article for instructions.
Verify the VM's network settings.
172.16.175.x is the IP scheme used by default for Private Subnet with Internet. To avoid any possibility of interruption, ensure your live network is not on the same IP scheme.
Repeat steps 1 through 11 for each VM that you'd like to add to the VLAN.
Verify the connectivity between the VMs, and then check their connectivity to the Internet.
