Replicate the group, not the disk: consistency in array replication
Why replicating each volume alone can leave a remote copy that will not start, how consistency groups fix it, and how to test a replica safely.
Array replication sounds like the simplest kind of disaster recovery: the array copies your disks to another array in another datacenter, and nothing inside your servers has to change. It is that simple, provided you replicate the right things together. Replicate each volume on its own and you can end up with a perfect copy of every disk and a database that refuses to start.
A copy of every disk is not a copy of the application
Most serious applications write to more than one volume. A database keeps its data files on one disk and its transaction log on another. A mail server separates the message store from its logs. A virtual machine may have a system disk and a data disk that only make sense together.
These applications depend on write order. The database writes the log record first and the data page later, and on recovery it replays the log to bring the data files to a consistent point. If the copy of the log volume at the far site is a few seconds older than the copy of the data volume, the remote site holds data pages that refer to log records that do not exist there. The database sees an impossible state. At best it recovers with work; at worst it will not open.
When each volume replicates independently, each copy moves at its own pace, so the remote disks are almost never at the same moment in time. The answer is a consistency group: a set of volumes that the array replicates as one unit, preserving the order of writes across all of them. On HPE 3PAR this is a Remote Copy group. Other arrays have their own name for the same idea. Whatever it is called, the rule is the same. Everything an application needs to start goes into one group.
Choosing what goes in a group
Start from the application, not from the volume list:
- List every volume the application writes to, including the ones that are easy to forget: the volume holding the binary log or write-ahead log archive, a separate temporary tablespace, a configuration disk.
- Put all of them in one group.
- Keep unrelated applications in separate groups, so one can be failed over, tested or paused without touching the other.
Then decide how closely the copy follows the original.
How close should the copy be?
There are two broad families of replication mode, and the choice is about physics as much as preference.
Synchronous keeps the copy current at the cost of a round trip on every write, which is small at metro distance and measurable between countries. Asynchronous runs at local speed and the lag is your recovery point.
Neither is right in general. A transactional system whose last minute of orders is valuable may justify the write latency; a content platform that can lose a few minutes of edits usually does not. The correct answer comes from asking what losing that gap would cost the business, and then measuring whether the application tolerates the latency of the stricter mode.
Keep replication off the production path
Replication traffic competes with host I/O if you let it. Give it dedicated array ports, keep those ports apart from the ports hosts use, and keep each replication link to one partner. Watch the replication lag, not just the link state. A link that is up while the copy falls further behind every hour is the failure mode that turns a disaster recovery plan into a surprise.
Test the replica without breaking it
A replica that has never been started is a hope. The good news is that you can test it without interrupting replication:
- Take a point-in-time snapshot of the secondary volumes of the group on the remote array. Snapshot the whole group at once, so the test copy is as consistent as the replica.
- Present the snapshots to an isolated test host at the remote site. Keep that host off the production network, so the copy cannot answer real traffic, send real email or run scheduled jobs against real systems.
- Start the application exactly as you would in a disaster, using your written runbook and nothing else.
- Check it at the application level: the database opens and passes its own consistency check, row counts and the newest records are where the recovery point says they should be, and an application login works.
- Time it, from the decision to fail over to the first successful transaction. That number is your real recovery time, whatever the plan says.
- Remove the snapshots and record the result, including anything that surprised you.
Run the test after any change to the group, and on a regular schedule even when nothing changed, because applications quietly add volumes.
Replication is not backup
Replication copies changes faithfully, and that includes a dropped table, a ransomware encryption run and a bad deployment. Within seconds or minutes the mistake is in both places. A replica protects you from losing a site; backups with history protect you from your own data. You need both, and the backups should be pulled by a system the production side cannot reach.
How we do it
Between our Athens and Amsterdam datacenters, customer volumes can replicate array to array on HPE 3PAR, with related volumes placed in the same Remote Copy group so they stay consistent with each other. The replication mode is agreed per service, replication runs over dedicated ports, one partner per port pair, over our own private interconnect between the sites, and replicas of EU-hosted data stay inside our EU infrastructure. Inside each site the arrays are federated, so volumes also move between arrays online. Backups sit alongside, separate and pull-only.
If you are not sure your remote copy would start on the day you need it, that is worth finding out on a quiet day. We are happy to help design the groups and the test.
Published 22 October 2026.
All field notes