In today’s digital landscape, Disaster Recovery (DR) isn’t just a safety net – it’s a lifeline. It ensures data protection, business continuity, and a competitive edge.

A lot of the time I see and speak to people asking about DR solutions when what they really want is HA with a few backups so I wanted to use a blog article to go through some of the technical terms used in conjunction with DR. When people say “I want DR”, I’ll ask them about the sort of disasters they are looking to protect against and most of the time the response is “I want to keep working if my hypervisor crashes”.

As written in the previous post, for ROBO scenario the most interesting HCI (Hyper-Converged Infrastructure) configuration is a two nodes configuration, considering that two nodes could be enough to run dozen VMs (or also more). For this reason, not all hyperconverged solutions could be suitable for this case (for example Nutanix or Simplivity need at least 3 nodes). And is not simple scale down an enterprise solution to a small size, due to the architecture constraints.

Here is an overview dedicated to disaster recovery, more specific, it’s about the DR capabilities of Microsoft Storage Replica – a new feature of Windows Server 2016. It takes a glance on the DR process itself and then brings a few details of the Storage Replica operation, its features, and peculiarities. They include zero data loss, block-level replication, simple deployment and management, guest and host, SMB3 protocol, high security, high performance, consistency groups, user delegation, network constraint, thin provisioning, etc. The post is, basically, an introduction to a series of experiments also listed on the blog. They were conducted in order to check the functionality and performance of Microsoft Storage Replica in different use cases.

Many of you have heard of Virtual Volumes (VVols) storage technology, which allows essential increasing of storage I/O performance within VMware vSphere environment by using logical volumes for certain virtual machines components and transferring of some storage operations to disk arrays.

As I review the marketing pitches of many software-defined storage products today, I am concerned by the lack of attention in any of the software stack descriptions to any capabilities whatsoever for managing the underlying hardware infrastructure. This strikes me as a huge oversight.

The truth is that delivering storage services via software — orchestrating and administering the delivery of capacity, data encryption, data protection and other services to the data that are hosted on a software-defined storage volume – is only half of the challenge of storage administration. The other part is maintaining the health and integrity of the gear and the interconnect cabling that provide the all-important physical underlayment of an increasingly virtualized world.

Personally, I am getting rather tired of the dismissive tone adopted by virtualization and cloud vendors when you raise the issue of disaster recovery.  We previously discussed the limited scope of virtual systems clustering and failover:  active-passive and active-active server clusters with data mirroring is generally inadequate for recovery from interruption events that have a footprint larger than a given equipment rack or subnetwork.  Extending mirroring and cluster failover over distances greater than 80 kilometers is a dicey strategy, especially given the impact of latency and jitter on data transport over WAN links, which can create data deltas that can prevent successful application or database recovery altogether.

At the end of March, an event little known outside of a small community of vendors, will happen:  World Backup Day.  Expect a flurry of blogs and tweets and posts and all of the other stuff that goes along with such marketing events.  Then, expect the discussion to go silent for another year…unless a newsworthy data disaster occurs.