The disaster recovery options with a hyper-converged today are:

1. Multiple clusters utilizing Storage Replica
2. Hyper-V Replica between clusters
3. Backup and Restore

Multiple clusters utilizing Storage Replica

1. Storage Replica enables the replication of volumes and supports both synchronous and asynchronous replication.
   1. synchronous replication, it will sequentially write to both ends at the same time.
   2. asynchronous replication, writes will replicate very fast but could still be lost.
2. Storage Replica is a block level copy mechanism versus file level; meaning, it does not matter what types of data being replicated
3. can utilize different types of drives between the replication partners
4. can be run in Azure as well as on-premises.

The following considerations apply when deploying Storage Replica.

1. Configuring replication is done outside of Failover Clustering
2. Choosing the method of replication will be dependent upon your network latency and RPO (Recovery Point Objective) requirement.
3. In the case of a disaster, failovers between the clusters are not automatic and need to be orchestrated manually through the Storage Replica PowerShell cmdlets
4. A new virtual machine or Scale Out File Server (SOFS) utilizing this data would need to be created inside Failover Cluster Manager on the replica partner.

Hyper-V Replica

Hyper-V Replica provides virtual machine level replication for disaster recovery on hyper-converged infrastructures.

How you wish the initial copy to be sent to the corresponding replica cluster(s).

1. Send the initial copy over the network
2. Send the initial copy to external media so that it can be copied onto your server manually
3. Use an existing virtual machine already created on the replica hosts

Hyper-V Replica Broker

you must have the Hyper-V Replica Broker resource created in each cluster. This resource does several things:

1. Gives you a single namespace for each cluster for Hyper-V Replica to connect to.
2. Determines which node within that cluster the replica (or extended replica) will reside on when it first receives the copy.
3. Keeps track of which node owns the replica (or extended replica) in case the virtual machine moves to another node.

Backup and restore

It is always a recommendation to have periodic backups of the hyper-converged infrastructure.

 Methods  for Restoring the cluster or the database

• Non-authoritative
  1. If you only need to restore a cluster node (and the cluster registry database) and all current cluster information good, you would restore using non-authoritative.
  2. Non-Authoritative restores can be done through the Windows NT Backup interface or the command line WBADMIN.EXE.

How to:

1. restore the node
2. let it join the cluster.
3. update the cluster information (run test cluster without storage test)

• Authoritative
  1. takes the cluster configuration back in time.
  2. should only be accomplished when the cluster information itself has been lost and needs restored.

how to:

1. Run WBADMIN.EXE

   1. Wbadmin get versions

2. Determine if the version backup you have has the cluster registry information in it as a component.

   1. wbadmin get items -backuptarget:\\backupserver\location

3. Start the authoritative restore to recover only the cluster registry version you need

   1. wbadmin start recovery -version:01/03/2018-02:04 -itemtype:app -items:cluster

4. Once the restore has taken place, this node must be the one to start the Cluster Service first and form the cluster. All other nodes would then need to be started and join the cluster.