1. Support Latam
  2. Acronis
  3. Acronis Disaster Recovery Cloud

Menu

    This article applies to:

    • Acronis Disaster Recovery Service (formerly nScaled DRaaS)

    Overview

    Migrating server workloads to the cloud and back

    The Acronis Disaster Recovery Service helps a client meet challenging RTOs and RPOs by maintaining recovery servers both on site and in a remote location. 

    Frequently taken incremental snapshots of a production server are saved locally and replicated to one of the Acronis Disaster Recovery Service datacenters. In both locations a snapshot is converted to a virtual server. If a disaster strikes, either virtual server can be activated in minutes and promoted to the client’s production network. The DR/BC service continues taking snapshots of this server. Once the on-site problem is eliminated, these snapshots can be replicated to the local storage so the client recovers the production server from the latest snapshot taken in the remote location.

    NetApp devices

    The DR/BC service effectively leverages client’s NetApp devices. If the production servers utilize NetApp storage, the DR/BC service replicates entire NetApp volumes to NetApp storage located in an Acronis Disaster Recovery Service datacenter.

    File recovery

    A client can access files stored in any snapshot without having to activate the corresponding recovery server.

    File backup

    The DR/BC service can back up files residing on client’s CIFS shares to Acronis Disaster Recovery Service datacenters. Version history for each file is readily available to the client. All data transfers are encrypted. Flexible retention policies can be applied to optimize the storage usage.

    Recovery Console

    The Recovery Console is a convenient web interface for monitoring the system health and storage usage, downloading backed-up files, and performing operations related to disaster recovery. Physically, the Recovery Console is a software component that runs in the main Acronis Disaster Recovery Service datacenter (Ashburn) and communicates with all datacenters and all clients.

    Clouds

    Local cloud

    This is the environment at the client side where the server snapshots are stored and where virtual servers (Local Recovery Servers) can be run for disaster recovery. Typically, it is an ESXi host with high-capacity disk drives and pre-installed virtual appliances.

    These virtual appliances are:

    • Cloud Hub that receives commands from the Recovery Console and sends appropriate instructions to the other components. The hub collects metadata and statistics, and submits the collected data to the Recovery Console. The hub can also back up files residing on client’s CIFS shares.
    • Agent for VMware that converts snapshots to virtual machines (Local Recovery Servers).
    • One or more storage nodes that replicate the snapshots to the remote cloud and delete outdated snapshots according to the retention rules set by the client.

    The following diagram illustrates the structure of the local cloud and interaction among its components. 

    • The client sets up a backup plan for each production server (i.e. defines how often to take server snapshots and for how long to store them) by using the management console.
    • The agents installed on the production servers take snapshots according to the backup plans. The snapshots are saved on the storage node.
    • The storage node incrementally replicates the snapshots to the remote cloud via the VPN tunnel. Replication takes place as soon as a snapshot is created.
    • The cloud hub instructs Agent for VMware to incrementally convert the snapshots to virtual servers.
    • On client request, the cloud hub activates and promotes the corresponding local recovery server.
    • The cloud hub backs up files from CIFS shares according to the schedule set up by the client in the Recovery Console. These files are saved in the remote cloud.

    Remote cloud

    This is the environment in a datacenter where the replicated snapshots are stored and where virtual servers (Remote Recovery Servers) can be run for disaster recovery. Each client has a separate remote cloud network.

    The remote cloud includes:

    • Continuity Storage where the snapshots are stored after their replication to the remote cloud.
    • One or more storage nodes that manage the snapshots in the continuity storage.
    • A Disaster Recovery (DR) Storage that stores virtual disks of Remote Recovery Servers and Primary Servers.
    • Management Server that stores agent licenses and backup plans, instructs the agents and storage nodes on how to execute the backup plans, and reports their statuses to the client via the management console.
    • File Level Backup Storage where the files backed up from CIFS shares are stored.
    • A production VLAN that includes the management server, the storage nodes, and the primary servers. Recovery servers are activated on the production VLAN if a disaster recovery event is declared. This VLAN is fully open to the client’s production network. All replication traffic goes through this VLAN.
    • A test VLAN for testing disaster recovery scenarios. The test VLAN is mostly isolated from the client’s production network. However, the level of isolation can be changed according to the client’s needs.

    The following diagram illustrates the structure of a remote cloud and interaction among its components.

    One of the recovery servers (marked yellow) is activated and promoted to the production network. Its snapshots are being saved to the continuity storage. Otherwise, the remote cloud works similarly to the local cloud.

    The central component that manages all remote clouds in a datacenter is the Pod Manager. It receives commands from the Recovery Console and sends appropriate instructions to the other components. The Pod Manager collects metadata and statistics, and submits the collected data to the Recovery Console. A pool of Agents for VMware that convert snapshots to virtual machines (Remote Recovery Servers) is controlled by the Pod Manager. A pool of ESXi servers that run Remote Recovery Servers and Primary Servers is part of Pod Manager.

    Servers

    Primary Server

    A virtual server constantly running in the remote cloud. Typically, it runs the Active Directory (AD) and Exchange services. Acronis Disaster Recovery Service creates the virtual machine and provides the operating system. Further maintenance of the server is the client’s responsibility. The server must be attached to the production network.

    Acronis Disaster Recovery Service takes snapshots of the primary server in order to provide AD and Exchange services in the remote cloud test environment. If a client runs a production server as a primary server, snapshots of this primary server are taken and stored in the remote cloud.

    Local Recovery Server (Bootable)

    A virtual server that can be run for disaster recovery purposes in the local cloud.

    Remote Recovery Server (Bootable)

    A virtual server that can be run for disaster recovery purposes in the remote cloud.

    Backup server (aka Non-Bootable Recovery Server)

    A set of server snapshots that is stored in either the local or remote cloud for file recovery purposes only.

    Recovery Server 

    Any recovery server (both local and remote, bootable and non-bootable).

    Storages

    Continuity Storage

    Acronis: Storage occupied by the snapshots replicated to the remote cloud, or created in the remote cloud. 

    FalconStor: Storage occupied by Recovery Servers.

    DR Storage 

    Acronis: Storage occupied by Remote Recovery Servers and Primary Servers.

    FalconStor: Storage occupied by Primary Servers.

    File Level Backup Storage

    Storage holding backed-up files of client’s CIFS shares.

    NetApp Storage

    Mirrored volumes on DR NetApp Storage.

    Powered by Zendesk