Frequently asked questions (FAQ)

What should be installed on customer side to start infrastructure replication?
On customer side just install and run replication agents on each ESXi host in VMware vSphere installation or agents of guest Windows and Linux operating systems. Each VMware agent will be responsible for replicating machines on its host, which will allow to optimize and make replication process more reliable. The agent is downloaded through replication wizard of new host, where the agent is passed as a parameter to group, machine replicated by the agent will enter, and the settings to access VMware vSphere. For detailed information see the section ACP - Machine Replication.
How often to update Migration plans?
The more often update Migration plans the better be ready for an accident and the less time it will take to update it when the accident has already occurred. Recommended frequency: every 2-3 weeks. For detailed information, see the section ACP - Migration plans.
How to group machines correctly and why should I create groups?
Groups are necessary for logical combination of machines. Association principles can be different: general purpose of machines, geographical location, general rules for storing snapshots and replication schedule. Particularly important and convenient groups feature is the ability to manage common parameters of replication schedule and snapshot storage rules at a time, that significantly simplifies flexible configuration of business application replication.
How much data will be lost in case of migration?
Recovery point objective (RPO) that can be lost in case of disaster directly depends on machine replication schedule (frequency). If some accident happens, data accumulated since the last successful replica will be lost, so for critical applications set minimum interval between replications or select Continuous replication, where snapshots are taken immediately after the end of the previous one. But remember that such frequency can lead to network load and affect performance of machines by constantly taking consistent snapshots.
How to check replicated business application in case of disaster?
To check correctness of replication and recovery of business application in case of disaster, it is necessary to periodically test Migration plans and restore infrastructure. With a certain periodicity, run cloud sites from the last recovery points on the basis of updated Migration plans and run a set of tests on restored application (similar to checking correctness of work of production), make sure tests successfully pass and application works as expected in cloud site. In case of problems, see the section ACP - Troubleshooting or contact support team for an early solution.
What should be done if machines have the Active status, but they are unavailable and do not work?
Follow the steps in Troubleshooting and contact support team if this does not help. Probably there is a problem with driver start on a new hypervisor and specialist’s help is required.
Part of machines changed their statuses to Error, what is the reason and how to fix it?
Make sure replication agents are running, there are no errors in their consoles and problems with the Internet connection between production and AWS or KVM platform. For details, see the section ACP - Troubleshooting and contact support team if this does not help.
How to set replication schedule for critical parts of business application and snapshot retention rules?
Settings for schedules and snapshot storage policies can be carried out for all machines as well as for individual groups and individual machines. Detailed overview of the functionality can be found in the section ACP - Machine groups - Managing replication schedule and snapshot storage policies.
How to properly plan failback to production and what downtime is expected during the procedure?
Failback to production can be started at the moment when some accident on production is eliminated and the main site is ready to failback business application. Download the agent to failback the application, carry out the process of downloading data from the DR site, test production, stop the machines in the cloud site and download all the changes from it, run production and again carry out the final testing, and then redirect traffic to production. Expected downtime depends on the size of the business application and the number of changes in the cloud site since the last synchronization between sites. On average, it lasts from 1 hour to 1-2 days. For detailed description of the process, see the section ACP – Failback to production.
Some user has removed some of the resources (cloud site, Migration plan, etc.), how to get an audit-log of recent user actions?
Client audit log is available for cloud provider administrators or customer administrators in case of on-premise installation. Contact them for data downloading.
It is necessary to create a system user with limited rights to view and edit resources, how to do this?
The system supports flexible roles management and accessible actions within them, contact solution administrator to create a role with necessary access parameters and add users to it. Detailed overview of the functionality can be found in the section ACP - Settings - Role Management