Solution description#
Hystax Acura is a Disaster Recovery and Backup solution for business applications and IT infrastructure in case of emergency or migration between clouds.
Disaster Recovery and Backup process consists of the initial replication of business application components (machines), infrastructure items to a backup data center (DC) and of the subsequent launch of a failover instance from one of the restore points. The failover runs on a backup DC, wherein the original IT infrastructure that includes all of the former items is restored.
Backup scenario differs from DR by storage used on a target site. In Backup mode, data is stored in object storage, which is more cost-effective for long term storage.
Replication is available for instances running on VMware, Hyper-V, OpenStack, as well as for physical machines.
Architecture#
The solution consists of server and client parts. The server one contains components, which are installed on the backup DC and responsible for retrieving changes from customer devices, their deduplication, storing data and failover as well in case of disaster. The server part also includes storage - an object storage located in the backup data center where full and incremental replications of customer machines are saved.
As for the client part, it includes agents installed on VMware vSphere/oVirt/OpenStack for replication of machines on the cloud platform or agents for Windows/Linux installed on guest operating systems for replication of other types of cloud platforms and physical machines.
Client for VMware (VMware agent) - a Linux machine, supplied as an OVA file, that is deployed to each ESXi host or cluster and that replicates machines on these hosts. Standard VMware tools are used to detect changes and retrieve deltas on virtual machines via the Changed Block Tracking (CBT) API. These tools, in turn, trigger the operating system's mechanisms (such as quiesce) to ensure data consistency within the replicas. An agent instance must have at least 2 vCPUs and 4 GB of RAM and must be deployed on each ESXi host or cluster containing machines designated for replication.
Note
An ESXi host or cluster detection depends on cloud configuration settings according to the discovery level.
Client for oVirt (oVirt agent) - a Linux machine, supplied as an RAW file, that is deployed on the main data center and that replicates machines on it.
Client for OpenStack (OpenStack agent) - a Linux machine, supplied as an RAW file, that is deployed on the main data center and that replicates machines on it.
Linux agent - a Linux daemon installed on a guest OS in case of replicating machines on public clouds like AWS, Microsoft Azure, or Google Cloud as well as Hyper-V, KVM, OpenStack, or physical machines with Linux operating systems. Supplied as a .rpm or .deb package to be installed in the guest operating systems.
Note
A Linux agent is available for download as a deb or rpm archive.
Windows agent - a Windows service installed on a guest OS in case of replicating machines on public clouds like Microsoft Azure or Google Cloud as well as Hyper-V, KVM, OpenStack or physical machines with Windows operating systems. Supplied as a ZIP file with MSI and a configuration file for installation on a guest operating system.
Warning
In case of a VMware/oVirt/OpenStack infrastructure replication, there is no need to install Windows/Linux agents on each machine. Just install a VMware agent on each ESXi host of vSphere.
Network schema#
The replication workflow involves three main components:
- Replication Agent – collects replication data from the source environment.
- Hystax Acura Controller – orchestrates replication and communicates with the target cloud.
- Cloud Agent – receives replication data in the target environment and writes it to the target storage.
Replication Agent
The Replication Agent is deployed in the source environment. It is downloaded from the Acura web UI and can be deployed in one of the following ways:
- Internal Replication Agent – installed as a service on each source machine.
- External Replication Agent – available for VMware, oVirt, and OpenStack source environments. It is downloaded as an OVA or RAW image and deployed as a dedicated virtual appliance on the customer's hypervisor.
Once the Replication Agent is installed and running, the source machine is automatically discovered in the Acura Control Panel (ACP) and becomes available for replication.
The Replication Agent:
- connects to the Acura Controller over TCP port 443;
- sends logs over UDP port 12201.
The Replication Agent does not require Internet access as long as it can reach the Acura Controller over the network.
Cloud Agent
The Cloud Agent receives replication data from the Controller and writes it to the target storage.
For most supported target clouds, the Controller automatically creates a dedicated Cloud Agent for each customer.
For VMware and oVirt target environments, the Cloud Agent is downloaded from the Customer page and deployed manually. It communicates directly with the target hypervisor.
The Cloud Agent:
- receives replication data over TCP port 80;
- writes replication data to the target storage;
- for VMware target environments, transfers replication data to the target hypervisor over TCP port 902 and UDP port 902.
Hystax Acura Controller
The Controller coordinates the replication workflow and communicates with the target infrastructure.
The Controller:
- communicates with supported cloud APIs using the ports required by the selected cloud provider;
- communicates with VMware vSphere over TCP port 443;
- communicates with VMware vCloud Director over TCP port 443.
For VMware environments, both the Controller and the Cloud Agent communicate with VMware vSphere over TCP port 443.
Storage connectivity
Storage connectivity depends on the selected storage type.
- When using object storage or file storage, the Controller must have network access to the storage because it resides outside the target cloud.
- When using block storage, no additional Controller connectivity is required because replication data is stored directly within the target cloud.
PostgreSQL backup schema#
PostgreSQL backup in Acura combines native PostgreSQL backup capabilities with centralized orchestration and storage management provided by Acura.
Warning
PostgreSQL backup requires user-supplied backup and recovery logic. Before enabling protection, verify that the backup and recovery scripts are properly configured and tested in your environment. Incorrect configuration may result in incomplete backups, unsuccessful recovery operations or even corrupting source VM.
Important
Before configuring backups, ensure that the database is prepared for backup operations and that the required permissions are available.
-
On the source system, backup and recovery operations are performed using native PostgreSQL tools. Backup and recovery automation scripts run alongside the Acura PostgreSQL backup agent. These user-maintained scripts contain the database-specific logic required to prepare, execute, and validate backup and recovery operations.
-
Acura provides six sample scripts: four for backup operations and two for recovery operations. By default, these scripts do not perform any actions—all backup and recovery logic is initially commented out. The scripts serve as templates and include comments, recommendations, and examples demonstrating common approaches to PostgreSQL backup and recovery, including the use of native PostgreSQL tools such as
pg_dump,pg_basebackup, and WAL archiving. Before enabling protection, review and customize the scripts to meet the requirements of your PostgreSQL environment. -
The Acura PostgreSQL backup agent can collect backup files and archived WAL data and transfer them to the Acura controller. The controller centrally orchestrates backup and recovery workflows, manages policies and schedules, tracks job status, and coordinates storage operations.
-
Backup data is stored and managed by Acura. During recovery, Acura retrieves the required backup files from storage and orchestrates the recovery process.
-
Backup files are available for download as files and directories. Current limitation: File-based backup recovery is supported only to the original source machine.
Data flow description#
The replication workflow transfers data from the source environment to the selected storage in the target cloud. Depending on the selected storage type, replication data is stored either in block storage within the target cloud or in external object or file storage.
Acura supports the following storage types:
- Block storage – recommended for disaster recovery and migration scenarios.
- Object storage – recommended for backup scenarios.
- File storage – recommended for backup scenarios.
Data replication#
Replication begins when a machine with a running Replication Agent is registered in the Acura Control Panel (ACP) and replication is enabled.
The Replication Agent transfers replication data to the Hystax Acura Controller, which orchestrates the replication workflow according to the configured replication schedule.
The subsequent data flow depends on the selected storage type:
-
Block storage – the Controller forwards replication data to the Cloud Agent, which writes it to block storage in the target cloud. During subsequent replication cycles, only changed blocks are transferred, and recovery points are created as configured.
-
Object or file storage – the Controller writes replication data directly to the configured external storage. The target cloud is not involved in storing replication data.
Note
For VMware and oVirt target environments, the Cloud Agent must be deployed manually. For all other supported target clouds, it is created automatically by the Controller.
Data storage#
The selected storage type determines how replication data is stored and recovered.
Block storage
Replication data is stored as volumes and snapshots in the target cloud. Recovery points are immediately available for machine recovery, minimizing recovery time. This storage type is recommended for disaster recovery and migration scenarios where fast recovery is a priority.
Object and file storage
Replication data is stored in external object (for example, S3-compatible or Azure Blob) or file storage (NFS or SMB/CIFS). These storage types are optimized for long-term retention and efficient backup storage through features such as deduplication. They are well suited for backup scenarios but typically require longer recovery times because recovery data must first be restored to the target cloud.
Data recovery#
The recovery workflow also depends on the selected storage type.
Block storage
Recovery is performed entirely within the target cloud. The Controller creates a recovery volume from the selected recovery point, provisions a virtual machine, attaches the recovery volume, and completes the machine recovery process.
Because recovery volumes already reside in the target cloud, virtual machines can typically be recovered within minutes.
Object and file storage
Recovery begins by restoring the selected recovery point from external storage to a recovery volume in the target cloud. After the recovery volume is created, the remaining workflow is identical to block storage recovery: the recovery volume is attached to a newly created virtual machine, which is then started.
Note
Recovery time depends on the selected storage type, the amount of data, and the complexity of the protected machine.
Deployment requirements#
| Hystax Acura Component | System Requirements | Network Requirements (Allow traffic to/from the following ports) |
|---|---|---|
| Hystax Acura (controller): deployed from the image provided by Hystax | 8 vCPUs Memory: 16 GB RAM Disk space: 200 GB SSD drive |
- Ingress - tcp/443 - Ingress - tcp/4443 - Ingress - udp/12201 - Egress - tcp/443 - Egress - tcp/80 (to Hystax Cloud Agent) |
| Cloud Agent (VMware): downloaded from Hystax Control Panel and deployed from an OVA template | 2 CPUs Memory: 4 GB RAM |
- Ingress - tcp/80 - Egress - tcp/udp 902 (to ESXi hosts) - Egress - tcp/443 (to vCenter and ESXi hosts) |
| Cloud Agent (oVirt): downloaded from Hystax Control Panel and deployed from a RAW disk | 2 CPUs Memory: 4 GB RAM 20 GB disk |
- Ingress – tcp/80 - Egress – tcp/443, udp/12201 |
| Cloud Agent (all other supported cloud platforms): deployed automatically in the target project | 2 CPUs Memory: 4 GB RAM |
- Ingress – tcp/80 - Egress – tcp/443, udp/12201 |
| Replication Agent Windows: downloaded from Hystax Control Panel – internal | Memory: 2 GB RAM CPU: x64 processor Disk space: 100 MB required for product installation and not less than 15% free space of disk size for VSS snapshots creation Microsoft .NET Framework 4.0 |
- tcp/443 - send data to the Acura host - udp/12201 - send logs to Acura |
| Replication Agent Linux: downloaded from Hystax Control Panel – internal | Memory: 500 MB RAM Disk space: 100 MB required for product installation and not less than 15% free space of disk size for snapshots creation |
- tcp/443 - send data to the Acura host - udp/12201 - send logs to Acura |
| Replication Agent VMware: downloaded from Hystax Control Panel – external | 2 CPUs Memory: 4 GB RAM There are several host permissions that the VMware Replication Agent requires to operate. |
- Source host – tcp/443 - vSphere host - tcp/443 - ESXi host(s) – tcp/udp/902 - udp/12201 - receive logs from the Hystax cluster |
| Replication Agent oVirt: downloaded from Hystax Control Panel – external | 2 CPUs Memory: 4 GB RAM 20GB disk |
- Source host – tcp/443 - udp/12201 - receive logs from the Acura cluster |
| Replication Agent OpenStack: downloaded from Hystax Control Panel – external | 2 CPUs Memory: 4 GB RAM 20GB disk |
- Source host – tcp/443 - udp/12201 - receive logs from the Acura cluster |
| Failback Agent VMware | Host permissions:Failback to VMware | - tcp/443 - vSphere host - tcp/udp/902 - ESXi host(s) - udp/12201- send logs to Acura |
| Failback Agent Flexible Engine | Host permissions:Failback to Flexible Engine | - tcp/443 - communicate with the Acura host - udp/12201 - send logs to Acura - Ports to communicate with the cloud API, e.g. tcp/5000 for keystone |
| Failback Agent OpenStack | Host permissions:Failback to OpenStack | - tcp/443 - communicate with the Acura host - udp/12201 - send logs to Acura - Ports to communicate with the cloud API, e.g. tcp/5000 for keystone |
| Failback to other clouds | For other clouds, failback is done in a form of a live reverse migration of workloads to the source environment. Internal replication agents are installed directly to failover machines. |
Acura compatibility matrix and supported systems#
Replication Agent Deployment Matrix#
Platforms and corresponding applicable Acura replication agent types:
| Source Platform | Supported Versions / Notes | Agent Type | Distribution Method |
|---|---|---|---|
| VMware ESXi / vRealize / vSphere | ESXi 6.0.0 U3+ (except ESXi 6.7 Build 8169922), 7+, 8+ | HVRAgent (external for Vmware), HWRAgent/HLRAgent (internal for Windows/Linux) |
OVA VM template (external replication) MSI installer / .deb, .rpm |
| OpenStack | Mitaka+ | HOVRAgent (external for OpenStack with Ceph as a Cinder backend), HWRAgent/HLRAgent (internal for Windows/Linux) |
RAW MSI installer / .deb, .rpm |
| oVirt | — | HOVRAgent (external for oVirt), HWRAgent/HLRAgent (internal for Windows/Linux) |
RAW MSI installer / .deb, .rpm |
| Other Virtualization Platforms/Clouds | — | HWRAgent/HLRAgent (internal for Windows/Linux) | MSI installer / .deb, .rpm |
| Bare Metal | — | HWRAgent/HLRAgent (internal for Windows/Linux) | MSI installer / .deb, .rpm |
Internal Agents OS compatibility:
| Agent | OS |
|---|---|
| HWRAgent - Hystax Windows Replication Agent | Windows 2008R2 and later (x64) |
| HLRAgent - Hystax Linux Replication Agent | AlmaLinux 8.4, 8.5, 8.6 CentOS 6.5+, 7.1+, 8.0+, 9.0+ Debian 7, 8, 9, 10, 11, 12, 13 Oracle Linux 6.10, 7.9, 8.10, 9.5 RHEL 6.5+, 7.1+, 8.0+, 9.0+, 9.7, 10.0, 10.1 SLES 15 SP6 Ubuntu 14.04, 16.04, 18.04, 20.04, 22.04, 24.04, 25.10, 26.04 |
Linux kernel support for Linux agent#
Note
The version ranges indicate the earliest and latest supported builds in each kernel family. Not every intermediate build is necessarily supported. To check whether your Linux kernel version is supported, see List of supported versions.
RHEL/CentOS
| Kernel family | Supported versions |
|---|---|
| 2.6.32-x | 2.6.32-220…2.6.32-754 |
| 3.10.0-x | 3.10.0-123…3.10.0-1160 |
| 4.18.0-x | 4.18.0-80…4.18.0-553 |
| 5.14.0-x | 5.14.0-70…5.14.0-611 |
| 6.12.0-x | 6.12.0-55…6.12.0-124 |
Ubuntu/Debian
| Kernel family | Supported versions |
|---|---|
| 3.2.x | 3.2.0-4 |
| 3.13.0-x | 3.13.0-24…3.13.0-170 |
| 3.16.0-x | 3.16.0-4…3.16.0-77 |
| 4.2.0-x | 4.2.0-18…4.2.0-42 |
| 4.4.0-x | 4.4.0-21…4.4.0-210 |
| 4.15.0-x | 4.15.0-20…4.15.0-213 |
| 4.18.0-x | 4.18.0-13…4.18.0-25 |
| 5.0.0-x | 5.0.0-15…5.0.0-37 |
| 5.3.0-x | 5.3.0-19…5.3.0-64 |
| 5.4.0-x | 5.4.0-26…5.4.0-216 |
| 5.8.0-x | 5.8.0-23…5.8.0-63 |
| 5.10.0-x | 5.10.0-1…5.10.0-39 (including -cloud variants) |
| 5.15.0-x | 5.15.0-25…5.15.0-176 |
| 6.1.0-x | 6.1.0-1…6.1.0-44 (including -cloud variants) |
| 6.8.0-x | 6.8.0-31…6.8.0-110 |
| 6.12.x | 6.12.31…6.12.74 |
| 7.0.0-x | 7.0.0-14 |
P2V / V2V Operating System Compatibility#
This section lists the verified operating systems supported by Acura’s P2V/V2V module. Other operating systems would work as well, but they have not been tested.
| OS Family | Versions Supported |
|---|---|
| AlmaLinux | 8.4, 8.5, 8.6 |
| Debian | 7, 8, 9, 10, 11, 12, 13 |
| Oracle Linux | 6.10, 7.9, 8.10, 9.5 |
| RHEL / CentOS | 6.5+, 7.1+, 8.0+, 9.0+, RHEL 9.7, RHEL 10.0, RHEL 10.1 |
| SLES | 11, 12, 15 SP6 |
| Ubuntu | 14.04, 16.04, 18.04, 20.04, 22.04, 24.04, 25.10, 26.04 |
| Windows Desktop | Windows 7, 8, 8.1, 10, 11 |
| Windows Server | 2008 R2, 2012, 2012 R2, 2016, 2019, 2022, 2025 |
Supported platforms and applications#
Platforms:
OpenStack, VMware, oVirt, OpenNebula, Amazon Web Services, Google Cloud Platform, Microsoft Azure, Oracle Cloud, Alibaba Cloud, Hyper-V, Nutanix, CloudSigma, STACKIT, and physical machines.
Applications:
SAP, Microsoft Active Directory, PostgreSQL, Oracle, NGINX, Red Hat Jboss Enterprise, IBM WebSphere, Apache, VMware vSphere, MongoDB, Hadoop, Spark, MySQL, and others.
Recommended configurations#
When deploying Hystax Acura for Disaster Recovery and Backup solution the configuration depends on the total amount of machines and the type of installation - for a test, for a single customer or to provide service.
Examples of typical configurations:
| Type of installation | Total amount of machines | Amount of nodes | Configuration of each node: CPU / RAM / Disk cores |
|---|---|---|---|
| Test | 15 | 1 | 8 / 16 GB / 200 GB SSD |
| Single customer | 50 | 1 | 16 / 32 GB / 200 GB SSD |
| Single customer | 150 | 3 | 16 / 32 GB / 200 GB SSD |
| Single customer | 250 | 3 | 24 / 48 GB / 300 GB SSD |
| Providing service | 500 | 3 | 32 / 64 GB / 300 GB SSD |
| Providing service | 1000 | 5 | 32 / 64 GB / 300 GB SSD |
Hystax Acura limitations#
- Virtual machines with disks engaged in SCSI bus sharing are not supported because VMware does not support snapshotting such VMs.
- RDM virtual disks in physical mode, Independent disks, and disks connected via in-guest iSCSI initiator are not supported. Network shares and mount points targeted to 3rd party storage devices are also skipped, as these volumes/disks are not visible in the VM configuration file.
- Free ESXi is not supported. Hystax Acura leverages vSphere and vStorage APIs that are disabled by VMware in free ESXi.
- Hystax Windows Replication Agent supports NTFS, ReFS filesystems.
- Hystax Windows Replication Agent converts dynamic disks to basic ones while protecting them.
- Hystax Linux Replication Agent supports replication of machines with up to 64 disks.
- Hystax Linux Replication Agent does not support installation or operation on systems with Secure Boot enabled.
- Windows servers with the enabled Storage Replica feature are not supported.
- Ephemeral networks are not supported.
- Virtual machines that use mdraid as the root filesystem have limited support. Recovery options and P2V/V2V migration are limited. For RHEL, CentOS, and similar operating systems, required drivers must be manually added to dracut on the source VM before replication / migration. The
rclocal_scriptandfix_dev_prefixscripts specified in the Recovery Plan are not executed. - The P2V replication and recovery does not support BIOS-to-UEFI conversion. The
firmwareparameter specified in the Recovery Plan must match the firmware mode used by the source machine.
AWS Limitations#
Hystax Acura uses an import image mechanism to launch replicated machines on AWS, therefore all "Import Image" limitations apply. Refer to the official AWS documentation for more details.
Azure Limitations#
- No ssh key can be attached to failover instances, as they are created from volumes.
- Mac address cannot be set for NIC.
- Every failover instance will have an extra temporary storage volume. Volume size depends on the flavor. More information can be found at: https://blogs.msdn.microsoft.com/mast/2013/12/06/understanding-the-temporary-drive-on-windows-azure-virtual-machines/
- No security groups will be assigned to failover instances by
default. Refer to Recovery Plans section
and use the key
security_groupin Recovery Plans. - CentOS 6.2 protection is not supported. Refer to https://docs.microsoft.com/en-us/azure/virtual-machines/linux/endorsed-distros for further details.
KubeVirt Limitations#
-
The only networking option is the pod network. It is used for Cloud Agents and can be used for migrated VMs by setting
podas theSubnet IDin the Recovery Plan. -
Setting an IP address in the Recovery Plan is not applied.
-
Subnet discovery in the Recovery Plan does not return any CIDR.
-
The machine remains blocked until recovery is deleted or detached.
-
If recovery is deleted, the next replication is full.
VMware Limitations#
- Max number of restore points stored for one machine is 29.
- Replication and failover of the same machine can't be started at the same time because both processes work with the same machine on the target side.
Replicated machines licensing on AWS#
According to the AWS requirements, machines running Red Hat Enterprise Linux (RHEL) must have Cloud Access (BYOL) licenses in order to be copied to AWS, whereas Windows machines will use the AWS licensing. For more information, please refer to the official AWS guide