Table of contents
Hystax Acura 4.6 expands the platform’s replication and disaster recovery capabilities across OpenStack and environments where target platform API integration is limited or unavailable, while modernizing key internal components.
One of the major updates is a storage-agnostic Changed Block Tracking (CBT) mechanism for the OpenStack External Replication Agent. It removes the previous dependency on direct Ceph access and enables a more consistent incremental replication approach across compatible OpenStack environments with different Cinder storage backends.
Acura 4.6 also adds Direct2Target support for disaster recovery scenarios, extends Receiver Mesh to D2T workflows, migrates Acura’s internal database from MariaDB to PostgreSQL, and introduces additional VMware, Linux, File Backup Agent, and security updates.
Below, we take a closer look at the key changes in Hystax Acura 4.6 and what they mean in practice.
Storage-agnostic full and incremental replication for OpenStack
In previous versions of Hystax Acura, OpenStack external replication depended on direct access to Ceph. Acura 4.6 introduces a storage-agnostic changed block tracking mechanism for QEMU/KVM, integrated with the OpenStack External Replication Agent.
The new architecture removes the requirement for direct Ceph access and avoids dependence on an API provided by a specific storage system. It makes the replication approach applicable to compatible OpenStack environments using different Cinder storage backends.
Changed disk ranges are identified at the QEMU/KVM layer using QEMU dirty bitmaps. A Bitmap Manager handles changed-block metadata through Libvirt and QEMU, while the External Replication Agent uses standard OpenStack operations to prepare and attach temporary disks and read the required data.
The Bitmap Manager does not read or transfer user data for virtual machines. It only returns information about the disk ranges that have changed. Workload data is read by the External Replication Agent from temporary disks provisioned via OpenStack, and no replication software needs to be installed on each protected guest operating system.
The first replication remains full. During subsequent cycles, Acura can read and transfer only the changed disk ranges, provided that the source virtual machine remains running and its QEMU process is not stopped or recreated.
This approach reduces dependency on the underlying storage technology and provides a more consistent incremental replication architecture for compatible OpenStack environments.
Architecture: CBT Management with Local Bitmap Manager Deployment
Architecture: CBT Management with Remote Bitmap Manager Deployment
Direct2Target adds support for disaster recovery scenarios
Hystax introduced Direct2Target in Acura 4.5 to migrate virtual machines without relying on a target platform’s management API. A dedicated D2T Agent receives replicated data and supports disk-level operations on the target side, making the approach suitable for environments where platform APIs are unavailable, restricted, or difficult to integrate with.
Acura 4.6 extends Direct2Target beyond migration by adding support for disaster recovery scenarios. This provides organizations with an additional way to prepare a recovery target in environments where API-based integration with the destination platform is unavailable.
Receiver Mesh support has also been extended to D2T workflows. Receiver Mesh was introduced in an earlier Acura release to allow Replication Agents to transfer data directly to receiving components, rather than routing all replication traffic through the Acura Controller. In Acura 4.6, Replication Agents can send data directly to D2T Agents. This removes the Controller from the D2T data-transfer path and provides a more direct replication route between source-side and target-side agents.
The release adds support for multiple D2T Agent formats – raw, qcow2, VMDK, OVA, and ISO – along with stability improvements and an optimized user interface for D2T workflows.
Planning cloud migration, disaster recovery, or backup for OpenStack, KVM-based platforms, or environments with limited target API access?
Thank you for your request!
We will be in touch soon.
We respect your privacy. See our Privacy Policy. You can unsubscribe at any time.
Internal database migration to PostgreSQL
Acura 4.6 migrates the platform’s internal database from MariaDB to PostgreSQL. Both are mature open-source relational databases, but PostgreSQL provides an extensible object-relational architecture, broad support for SQL standards, advanced data types such as JSONB, and robust transaction and concurrency management.
These capabilities make PostgreSQL a flexible foundation for software platforms whose functionality, data models, and operational requirements continue to evolve. The migration modernizes a core part of Acura’s internal architecture and provides Hystax with greater flexibility for future product development and maintenance. For Hystax Acura customers, this is a behind-the-scenes change and does not introduce a new workflow or require a different way of using the platform. Its value is architectural: a more flexible internal data layer that supports the continued development and long-term maintainability of Acura.
Additional compatibility, backup, and security updates
Acura 4.6 adds support for thick-provisioned disks when VMware is used as the target cloud. This allows deployments to align with VMware storage configurations and target-side policies that require thick disk allocation.
The File Backup Agent also receives performance and stability improvements. The release expands support for newer Linux distributions and kernels, including RHEL 9.8, RHEL 10.2, and Ubuntu 26.04, helping organizations protect and move workloads running on current Linux environments. Moreover, the release includes general security updates.
Together, the changes in Hystax Acura 4.6 expand OpenStack replication beyond direct Ceph access through a storage-agnostic CBT mechanism, add Direct2Target support for disaster recovery scenarios, and modernize Acura’s internal architecture while improving platform compatibility, security, and operational stability.