Storage 101: Replication vs backup, and synchronous vs asynchronous

Replication versus snapshots

Replication is fundamentally a method of producing a clone of a unit of storage. In other words, it is a replica of a drive, volume or logical unit number (LUN), for example. In most cases, what is being strived for is an exact copy – maybe almost immediately, maybe just eventually.

That makes a clone or replica different from a snapshot, because snapshots in most cases can only become a usable replica following some sort of rebuilding process. That’s because snapshots comprise an original copy of the drive or volume plus updates to it, as well as perhaps deleted blocks that have to be reincorporated to create an accurate copy from a previous point in time.

The idea is that snapshots can be re-built and rolled back pretty quickly, but they’re not there as an alternative, usable copy of the source media. Meanwhile, clones and replicas often are.

The simplest clone/replica of all is when, for example, a developer needs a database to run some test queries on. They can clone an exact copy of an existing production database and do what they want with it in the test environment. That clone will be an exact replica of the database at the point in time it was created, but it will not likely ever reflect any further changes to the source copy.

But at the other end of the scale in terms of creating an available, working clone is synchronous replication. This sees data written to two or more units of storage as near to simultaneously as possible to provide a working copy that can be failed over to on-the-fly.

Obviously this comes at a price in terms of cost and technical complexity and there are limitations, as we shall see. But this is often what we mean when we talk about replication.

Replication versus backup

Can replication replace backups? The simple answer is no. Backups and replication (and maybe snapshots too) have to complement each other.

Because replication can be almost continuous and creates a near real-time copy, it can also make a replica of corrupted or infected files. In that case, you need a version to roll back to.

That could be derived from a snapshot, but then they also need to be underpinned by backups – and replication is often costly, so it may be that only certain datasets are replicated while everything is backed up.

Synchronous versus asynchronous array replication

In synchronous replication, data can be written to the second site as soon as it hits cache in the primary site. On receipt, the second site sends an acknowledgement to the primary site storage and the host where the change originated. It’s the method of replication that comes as close to writing multiple copies of data as near to simultaneously as possible.

Synchronous replication is often the preserve of the most high-end block storage arrays.

Asynchronous replication adds a stage to the process, by acknowledging the host at the primary site when the data is written. Then the write is sent to the second site, which acknowledges that write back to the primary site array. Asynchronous replication is found in a wider range of storage products, such as iSCSI storage, network-attached storage (NAS), and so on.

Replication over great distances starts to suffer from about 1 millisecond of latency per 100 miles, and suppliers often recommend no more than a few hundred miles round trip.

For that reason, synchronous replication can have more of an impact on application performance. It demands acknowledgement before the next input/output (I/O) can take place, whereas asynchronous replication acknowledges locally so the next change can take place, with movement of data delayed. Of course, that also means the two data sets will differ for a longer time.

A real-world replication strategy might use a combination of synchronous replication – for the most critical elements of an application such as redo logs – while less critical data that could be restored goes via asynchronous. Snapshots could form part of the mix too, but it would all need to be underpinned with regular backups.

Host, hypervisor and cloud replication

Here we have dealt primarily with synchronous and asynchronous replication in storage arrays.

Other forms of replication exist, such as:

• Host replication – between servers, perhaps of individual applications, databases or the entire server.
• Hypervisor replication – Replication managed at hypervisor level and comprised of its elements, such as individual virtual machines (VMs), and virtual storage, for example.
• Cloud replication – This could be replication to the cloud or multiple clouds as a target, or between clouds.
• Geo-replication – This is where data is stored in multiple remote locations, potentially very distant from each other. This can be for reasons of disaster recovery or to enhance availability. Replication over such long distances is not likely to be synchronous.