Managing Remote Mirroring

VPSA Asynchronous Remote Mirroring provides the ability to replicate your VPSA’s data asynchronously to a different Pool within the same VPSA, to a different VPSA (either locally within the same Zadara Cloud, or remotely to a VPSA located in a remote region), or even to a different cloud provider. You can replicate a single source Volume to any number of remote (or local) Mirrors.

Asynchronous Mirroring has minimal impact on IO throughput and response time from the Server perspective since the Server IO returns immediately after being written to the local VPSA storage (without waiting for acknowledgment from the remote VPSA, like is required with Synchronous Mirroring). Later, the data is synchronized to the Remote VPSA in the background.

The VPSA Remote Mirroring is snapshot-based, meaning that only modified data chunks between two point-in-time Snapshots are synchronized. This has some major advantages:

  • If a file/block was modified several times between two consecutive snapshots only the last change will be synchronized, thus saving bandwidth.

  • Snapshots are crash-consistent, thus at the Remote Site you always have a crash-consistent point-in-time data set of your application.

  • You can easily create many Read/Write Clones of your remote data at various point-in-time snapshots for Test & Dev.

The VPSA manages checkpoints to track the sync progress within a Volume/Snapshot. In case of a transport failure (line failure, VPSA failure etc.) the VPSA has a clear checkpoint from where to resume the sync.

Remote VPSA communication is strongly authenticated and secured using cryptographic protocols designed to provide secure communication over the Internet. Mirrored data is encrypted before being shipped to the remote VPSA.

Mirrored data is also compressed before being shipped to a remote VPSA in a different region, for efficient bandwidth utilization.

You can establish a “many-to-many” remote mirroring relationship for different Volumes between different VPSAs. This means that a VPSA can mirror Volumes to many remote VPSAs, while at the same time also be the Destination VPSA for other Volumes in any other VPSA.


Remote VPSA communication is done over ports 1339/1340(TCP).

Creating a Local Mirror (on the same VPSA)

To create a Local Mirror, go to the Mirroring page and click the Create button. Give the new Mirror a name, as well as a name for the new Volume it creates. Select the destination Volume you will be mirroring and then click the Next button.


On the next screen select your local VPSA as the Destination VPSA and the Pool you want to replicate to. You cannot replicate to the same Pool in which the source Volume resides. Then click the Next button.


On the final screen select the Snapshot Policies, you want to apply to the Mirrored Volume, and click Submit.


Connect to a remote VPSA

The first step to building a DR plan (i.e. setting up a Mirrored Volume on a remote VPSA) is establishing a trusted relationship between your VPSAs.

If the VPSAs are located in different Zadara Storage Clouds you will need to first assign a Public IP to each VPSA (See Assigning Public IPs for more details) alternatively.

If the remote VPSA is located in the same Zadara cloud replication can take place using the following:

  1. Frontend network - assuming both VPSAs are sharing the same network or on different network where proper route is in place.

  2. Using a VPSA VNI (Virtual Network Interface - additional local network interface allocated to the VPSA)


    Limitation - Replication using VNI (both source and target) over different network is allowed only if a single VNI is attached to the VPSA.

Navigate to the Remote VPSAs page and click the Discover button.

Enter the following details:

  • Remote VPSA IP Address:

    • If the remote VPSA is located in a different Zadara Storage Cloud in a remote Region:

      • Enter the remote VPSA Public IP address. You can find it in the VPSA details in the Management console or in the remote VPSA GUI, under Controllers > Public IP.

      • Select the “Discover remote VPSA through Public IP” checkbox.

    • If the other VPSA is located within the same Zadara Storage Cloud:

      • Enter the remote VPSA Management IP address.

      • In this case, do NOT check the “Discover remote VPSA through Public IP” checkbox.

  • Username & Password – For authentication against the remote VPSA you are required to enter the username and password of a valid user in the remote VPSA. A cryptographic hash value (using a one-way SHA-1 hash function) of the entered password is sent to the remote VPSA.

Remote VPSA Properties

You can review all of the remote VPSAs with which this VPSA has established a trusted relationship. For each VPSA the following details are provided:


  • Local ID – The VPSA ID of the Local VPSA.

  • Remote ID – The VPSA ID of the remote VPSA.

  • Name – The name of the remote VPSA.

  • Provider – The name of the Cloud Provider where the remote VPSA is located.

  • Software Version.

  • IP – Public or Management IP through which the VPSAs are connected.

  • Rate Limit (MB/s) – Maximum tranfer rate allowed for mirroring data to the remote VPSA.


  • Each VPSA publishes the list of Pools that can be used to provision the remote Volume.


This list does not update automatically. Click the Refresh button to update the remote Pools info from the remote VPSA.


  • The logs related to the selected remote VPSA

Creating a Remote Mirror

You can create the Remote Mirror from the Remote Mirroring page by clicking Create. You will see a similar dialog:


Name the Mirror and the destination Volume, select the source Volume and click Next.


Backup job name, similarly to other VPSA entities is limited to:

  • 128 characters in length

  • ASCII characters only (between 32 and 126) with the exception of the following special characters: ",%,;,{,},[,],<,>,\,',&

  • Cannot have a starting or trailing whitespace


Choose the Destination VPSA, WAN Optimization or I/O Performance Optimization (see below) and the destination Pool. Click Next.


Mirroring a volume from a VPSA in a software version which is 19.08 and above to a target VSPA with a software version lower then 19.08 is not supported.

WAN Optimization v. I/O Performance Optimization

The VPSA supports selection between “I/O” and “WAN” data synchronization optimization. When “I/O” is selected, the VPSA synchronizes modified Pool chunks of 25KB or 1MB, depending on the Pool type. When “WAN” is selected, the VPSA synchronizes only modified 4KB sub-chunks. WAN optimization typically reduces WAN traffic bandwidth at the expense of additional workload on the source Volume, which may affect application performance.

imageAFA Dedup and Compression

While mirroring to All Flash remote VPSA, you can decide if the mirrored Volume will be dedup’ed and/or compressed, in order to save space on the mirror destination.


Select the snapshot policies you want to apply to the remote Mirrored Volume and click Submit.

Replicate the same Volume to multiple destinations

It is possible to replicate the same Volume to multiple destinations. Just repeat the above steps, selecting a different destination each time.

Pause & Continue Remote Mirror

It is possible to pause a Remote Mirror. A paused Mirror will stop syncing data immediately and stop creating new Snapshots. The status of the Mirror will change to “Paused”.

To pause a Mirror, select the Mirror in the Mirroring page and press the Pause button.


To resume the Mirror operation, select the Mirror in the Mirroring page and press the Continue button.


Managing Mirror Lifecycle

The Mirror controls the Remote Volume on the destination VPSA. As long as the Mirror is active, the target volume cannot be attached to any Server, nor can it be modified outside the scope of the Mirror. Hence it is treated as a special kind of “Destination Volume.”

You can view Mirror Destination Volumes on the “Dest. Volumes” tab on the Pools Page of the Destination VPSA, but they do not appear in the Volumes page.

Clone Destination Volume for Dev & Test of Remote Mirror

For offline processing (e.g. Dev & Test and other purposes) you can Clone the destination Volume using the data set of any Snapshot that was completely synchronized. You cannot create a Clone of the Snapshot that is currently being synchronized.

The Cloned Volume is independent of the Destination Volume or the Mirror (i.e. you can delete both the Destination Volume and the Mirror and the Cloned Volume will not be affected).

To Clone a Mirrored Destination Volume, go to the Mirroring page on the Destination VPSA. Select a Mirror and click the Clone button.


  • Select the point-in-time Snapshot that contains the data set that you wish to clone. The VPSA will assign a name to the Cloned Volume which is a concatenation of the Dest Mirror Volume name and the timestamp of the selected Snapshot. You can modify this name at any time.

  • You can find the newly created Volume in the Volumes Page.

Breaking a Mirror

Breaking a Mirror is the process of deleting the Mirroring relationship between the Source Volume and the Destination Volume, while leaving sufficient information for to reconnect the Mirror in future. The Destination Volume then becomes a “regular” Volume and the source and the destination Volumes are now independent of each other. A Mirror can be broken from the source or from the destination VPSAs.

You can perform a future Mirror reconnect in both directions. However, there are implications on the data which is retained and data which will be overwritten depending on which side the Mirror reconnect is initiated from. More details on this are in the next section.

To break a Mirror, go to the Mirroring page, select a Mirror and click the Break button. After confirming the operation, the Mirror Object in the Mirroring page will disappear from both the Source and the Destination VPSAs.


While braking a mirror you have the ability to assign the destination volume with the same world wide ID(WWID) as the source volume. WWID is used by some host platforms for volume identification and therefore assigning the source WWID to a target volume might accelerate Disaster recovery procedure in cases where host environments is the main and DR sites have the same volume metadata. To preserve source WWID for the target mirror volume check the Assign source WWID to target volume box on the mirror brake dialog.


To avoid data availability and integrity issues a host should not be exposed to two volumes with the same WWID.

Reconnecting a Mirror

As previously described, the VPSA retains sufficient metadata about each Volume after a Mirror has been broken to enable a future reconnect of the Mirror relationship. Also, all the mirroring snapshot policies (Type = “Remote Mirroring”) are kept in place, but in “Paused” State. as shown in the image below. These snapshots policies are used for reconnecting the mirror.


This metadata allows the VPSA to identify a remote Volume, on a Remote VPSA, that had a Mirroring relationship with a local Volume anytime in the past and find the most recent Snapshot that is in-sync on both Volumes. This enables it to reconnect the Mirror relationship and resume the sync process from the most recently updated data set. If there is a match between policies on the source and destination the matching snapshot policies will be used to reconnect the mirror.

A mirror reconnect can be done in any direction, regardless of the previous Mirror direction. This provides the required flexibility for a DR plan. In case of a suspected source site disaster, you can break the Mirror, assign the Destination Volume to an application server and work on the DR site. Once the source site is back, you can decide in which direction to resume the mirroring relationship.


When resuming Mirroring, the VPSA identifies the most recent point-in-time Snapshot that is completely in-sync on both source and destination Volumes. Any data that was written on the destination Volume after this snapshot will be deleted!

To Reconnect a Mirror:


  • Go to the Mirroring Page and click Reconnect. The system will list candidate volumes with broken mirror. Select the Volume that you wish to act as the Source Volume of the Mirror.

  • Select the Remote VPSA that contains a Volume that used to be a Mirror pair of the selected Source Volume in the past. Press Next.

  • The VPSA will query the remote VPSA and display suggested Remote Volumes which can be Destination Volumes of the Mirror, with the following information:

    • Remote Volume name.

    • New Data – There is new data on the Remote Volume which was written after the last sync point and which needs to be deleted in order to reconnect the Mirror.

    • Last Sync – The timestamp of the most recent Snapshot. Any data written on the Source Volume after that timestamp will be synchronized to the Remote Volume.

    • Snaps to Del – Number of snapshots to delete on the Remote Volume. Please note that it is possible that empty Snaps need to be deleted while no new data is lost on the Remote Volume.


  • Press Continue.

  • Enter a name for the new Mirror.


Objects names can be up to 128 chars long and can contain letters and digits, dashes “-” and underscores “_”

  • If the system finds matching policies on the source and destination VPSA’s they are automatically used. If no matching policy can be found, the following dialog is displayed, asking for the Snapshot Policy to be used. Select Snapshot Policy for the new Mirror.

  • Press Submit to Reconnect the Mirror.



Reconnect Mirror is blocked in the following cases:

  • The Destination Volume is attached to a Server

  • The Destination Volume has active Snapshot Policies. Remote Mirror does not allow to have any non-remote-mirror snapshot policy attached to the destination volume. You have to detach all non-remote-mirror snapshot policies on the destination volume before reconnecting the mirror (this situation is common when reversing the direction).

Viewing Remote Mirror Properties

The Remote Mirroring Page displays the list of Remote Mirrors that the VPSA participates in, either as the Source or the Destination. The Mirrors are not symmetric, so both the source and the destination VPSAs display slightly different info.

Select a Mirror and review the detailed information in the following South Panel tabs:



Each Mirror includes the following properties:




An internally assigned unique ID.


User assigned name. Can be modified anytime.


User free text comment. Can be used for labels, reminders or any other purpose


  • Idle – Mirror has nothing to Sync.

  • Failed

  • Paused

  • Syncing (X%) – Transferring the modified data of the “Current Snapshot” to the remote Volume. X% stands for the syncing location inside the Snapshot.

  • Ready to sync/Syncing (X%) – Same as “Syncing” but at the destination VPSA.

Current Snapshot

EMpty. Snapshots are listed in the Snapshots tab


Return Point Objective – This is the timestamp of the most recent fully synchronized Snapshot.

Rate Limit

Maximum tranfer rate allowed for mirroring data to the remote VPSA.


I/O Performance or WAN optimization


Date & time when the Mirror was created.


Date & time when the Mirror was last modified.

Source VPSA / Provider

The name of the Cloud Provider where the source VPSA resides.

Source VPSA / VPSA

Source VPSA name.

Source VPSA / Pool

Pool name where the Source Volume is provisioned. This parameter is available only at the source VPSA.

Source VPSA / Volume

Source Mirror Volume name.

Destination VPSA / Provider

The name of the Cloud Provider where the destination VPSA resides.

Destination VPSA / VPSA

Destination VPSA name.

Destination VPSA / Provider

Pool name where the destination Volume is provisioned.

Destination VPSA / Pool

Destination Mirror Volume name.


The Snapshots tab for Mirroring, lists the point-in-time Snapshots of the Mirror on this VPSA. Please note that a Mirror configuration supports retaining different numbers of Snapshots on the Source and the Destination VPSAs. Each VPSA will display its own managed list. If you retain many Snapshots, you may want to use the Snapshot Filtering tool to find a specific Snapshot. For more details see Filtering Snapshots.

Snapshot Policies

The Snapshot Policies tab for Mirroring lists the active Snapshot Policies used by this Mirror to manage Snapshots on the Source Volume and the Destination Volume of the Mirror. The snapshot policies only appear on the Source VPSA, not on the Destination VPSA Mirror Snapshot Policies tab.


The Source VPSA manages the Mirror Snapshot Policies, therefore modifications to the Mirror Snapshot Policies are configured on the Source VPSA.

The Source VPSA updates the Destination VPSA regarding any changes to the Dest Delete Policy.

You may make modifications while the Policy is active on a Mirror and the changes become effective immediately. For example, if you change the policy to retain fewer Snapshots, some older Snapshots will be deleted immediately.

The following information is provided per Snapshot Policy on the Source VPSA:

  • Status – Current state of the mirror.

  • Create Policy – Minimum time between Snapshots.

  • Delete Policy – How many Snapshots are retained on Source Volume.

  • Dest Delete Policy – How many Snapshots are retained on the Destination Volume.

The following information is provided per Snapshot Policy on the Destination VPSA:

  • Status – Current state of the mirror.

  • Create Policy – N\A.

  • Delete Policy – How many Snapshots are retained on the Destination Volume. This value is identical to the “Dest Delete Policy” on the Source VPSA.

  • Dest Delete Policy – N\A.


The Mirror Metering tab provides live information of the Mirror’s transfer throughput and IO Time associated with the selected Mirror. You can view the Mirror metering information on either the Source or the Destination VPSA.

The charts display the metering data as it was captured in the past 20 “intervals”. An interval length can be set to one of the following: 1 Second, 1 Minute, 10 Minutes, or 1 Hour. The Auto button lets you see continuously updating live-metering information (refreshed every 3 seconds).



Displays all event logs associated with this Mirror relationship.