Quest Rapid Recovery/AppAssure recover back after running live on a CC Node

Title: How to recover back after running live on a CC Node

Description: This method is used for backing up live CC node data and getting it restored to the original location (production side at clients office).

Cause: We have ordered a PAID CC Node and restored our agents over to it. We have configured pFSense to allow our users access to the now running VM within Hyper-V and need to get these VM's back to the clients actual environment.

Resolution: The first step is to check how much space has been used by your restored VM's running on the CC node that was given to you. To do this, navigate to My Computer and check out the free space on the X drive. In this example, this is a large CC Node with a usable amount of 14.4 TB.

Check to make sure that at least 1/2 the space of the X drive is free. If so, we can continue to next step. If not, please contact the Engineer who is assigned to your ticket for more info. A different physical node can be provided to complete this task.

Next, you will need to go to this site: https://support.quest.com/. Please log in with your Quest username and password. Once logged in, click on the Software downloads section on the left. Once there, type in the software you need. If on AppAssure, type AppAssure. If on Rapid Recovery, type Rapid Recovery and then press enter. 

Once on the page in the example below, you will need to download the core installer and the agent installer. The agent installer will need to be run on each of your recovered VM's so that they match the installed core version you are about to install. No matter what setup you had locally before they were restored to the CC Node, you will need to take the steps below. 

NOTE: You must have an active Maintenance contract with Quest in order to download any version of the AppAssure/Rapid Recovery Software. Without it, we will not be able to provide any installers or keys to complete this request. (Only exception to this rule is where eFolder has sold licenses in the past. Only these clients will be provided the installers, but will still need to provide their own key.)

1) Run the core installer on the CC Node. Install any prerequisites that are required. Once the install has completed, you will need to input your license key. This can be found here: https://rapidrecovery.licenseportal.com/. Simply log in with the same username and password you used for the support portal. Click on the licensing tab and on the far right you will see the license key drop down. Simply download this key and apply it when prompted in the newly install core GUI. Now you will need to create a local repository on the CC Node. Navigate to the three dots (see example below) and click +Add New DVM repository.

A) Once the new prompt comes up, type in the name you want for the repository. For storage locations, click +Add Storage Location. Leave the defaults as "Add file on local disk" and put in the data path x:\repo1-1. Do the same for Metadata path, x:\repo1-1. For the size, please set it to match what you have in data. For instance, if you have 2 TB of restored VM data, please set the size to 2000 GB and then click save. Then on the next box, click create.

2) After activating your newly installed core software on your CC Node, you will need to have a look at your restored VM's to see what Subnet and IP range they are on. You will need one available IP in that range in order to tie it to the local CC Node adapter. This is used so that communication can be made between the restored VM's running in Hyper-V and the CC Node running the Quest Software. (I.E. My restored VM's have an IP range of 192.168.0.1-192.168.0.254 with a Subnet mask of 255.255.255.0. So this network is 192.168.0.0/24. You will need to figure out a single IP address you can use. In this example, I will use 192.168.0.254/24.

3) On the CC node, open Network and Sharing center. Then on the left side of page, click on "Change adapter settings"

4) On the next page, right-click on the adapter called "Internal-LAN" and choose properties. 

5) Scroll down to the section called "Internet Protocol Version 4 (TCP/IPv4)" and put a check mark in the box. Then click OK. Now, right click on the adapter "Internal-LAN" and scroll down to "Internet Protocol Version 4 (TCP/IPv4)" and choose properties. Now select to "Use the following IP address" and input the IP address you found available in your subnet. In the example above, we will be using 192.168.0.254/24.

6) It is very important that you do NOT input a gateway or DNS here. These are already configured on another adapter on the CC Node. Once done, click OK. You can close out of the Network connections page. Now, open a command prompt and try pinging the VM's running in Hyper-V. Note, the VM must be on the same network as the adapter you just assigned. If you have multiple subnets, simply add in secondary IP's for those subnets to the "Internal-LAN" adapter.

7) At this point, depending which core version you chose to install, you will need to update the agents to match. If the agents are already on the same version of the core software, no additional steps are needed.

NOTE: You do have the option of doing an agentless backup by protecting the Hyper-V host. If you choose this method, you will only be able to recover back on the production side to Hyper-V Server 2012 R2. If you have a different version of Hyper-V or use something like VMWare, you must protect your agents locally by installing the updated agent on each VM.

8) From the core GUI on the CC node, choose protect then protect machine at the top of the banner. Once there, click on Advanced and then click next.

9) For the host name, please use the IP address of the VM you wish to protect. You will need to specify a username and password for each agent you are protecting. Generally, it's best to use a dedicated account for all VM's. If using an Active Directory environment, simply create a service account and give it the access it needs (Backup Operators group) so that you can use one account for all of your newly protected VM's. You can also use the local Administrator account on each VM. Please protect the VM's as you normally would using the agent mode. 

https://support.quest.com/rapid-recovery/kb/185870

After the agents have been backed up to their new core running on the CC Node, you can now setup replication to point back to the local production environment. You will need to have ports 8006-8010 opened on your local firewall in order for communication to work. Navigate to the home page and click the replication tab. 

10) Under the section "Outgoing Replication" choose add target core. 

11) Click, "I have my own target core" and for the Host name you will need to input a static address that you have NAT'd to your internal source core. This is done on your local firewall. You can use a DNS name if you have registered this address to the correct name by creating an host "A" record in your public DNS manager. Then specify the username and password on your local core that you have setup. Then click next. For the incoming replication name, you can leave the default or type CC Node, then click next.

12) Now choose the agents you wish to replicate back. In this case, it would be all. Keep in mind that new base images have been taken on this newly created source core running on the CC Node side. You will need the space on your local core to fit this data. Please make sure to calculate how much space is needed and make sure enough space is available on the destination side. If you need help calculating this, please contact an Engineer at eFolder. Once the the source (CC Node) replicates the initial base to the production site (Client core), then you can setup Virtual standby's locally. That way, as new incremental data is sent over to the production end, these VM's on the client side will update. When the switch is ready to be made, simply force a local snapshot of the agents running on the CC node, then force replication to the client side. At this point, these agents running on the CC node can be shut down. Once the new data is replicated over to the clients side, the Virtual Standby image will be updated with the latest data. Then the Virtual Standby's can be paused and the VM's turned on. Alternatively, if running a physical server on the clients side you can do a BMR restore instead of a virtual standby.

13) After getting running again on your local core, the agents will then need to be replicated back to the original eFolder target core. This core will need to be cleaned up since the data is out of date. We can archive and ship you this data if needed. We can also build a new migration core so that both cores can be kept in case any older data is needed. Migration cores are free for 30 days. We will also provide the seed drives needed to reseed a core. 

If any assistance is needed throughout this recovery process, just let us know.