If the Primary site fails, the Secondary needs to take over the role of the Primary. However, the asynchronous Secondary may be behind the Primary. That is, there may be some writes that are completed to the application but have not yet reached the Secondary data volumes; these writes are stored in the Replicator Log on the Bunker node.

To recover from a disaster on the Primary, you can use the Replicator Log on the Bunker node to update the Secondary. If the Bunker storage was directly connected to the Primary when it crashed, then you must import the disk group on the Bunker Secondary. Activate the Bunker and start replication from Bunker node to Secondary.

After all of the pending writes are transferred to the Secondary, the Secondary is as up-to-date as the Primary. The Secondary can take over the role of Primary, with no data loss.

Bunker replication enables you to balance the Recovery Point Objective (RPO) with the Recovery Time Objective (RTO) depending on your specific needs. In the case of a disaster, completely replaying the Bunker Replicator Log to the Secondary provides zero RPO. However, if your required RTO is less than the time required to complete replay of data from the Bunker Replicator Log to the Secondary, then you can choose to stop the replay after some time to recover as much data as possible within the required RTO. If the Secondary is far behind the Primary at the time of the disaster, then the time that is required to recover the complete data (RTO) could be large.

Using Bunker replication, you can stop the replay after a period of time to recover as much data as possible within a target RTO. For example, if your Secondary is 2 hours behind the Primary, you can replay the full Bunker Replicator Log to achieve zero RPO but your RTO could then be about 2 hours. If you require an RTO of 1 hour, you could begin Bunker replay and then stop the replay after 1 hour. You can also perform a normal Secondary take over, without replaying the Bunker at all, if you need the application to be immediately available (RTO is zero). In this case, the writes to the Bunker Replicator Log that have not yet been transferred to the Secondary are lost.

After the Secondary has been updated (either the Bunker replay has completed or the target RTO is reached and the Bunker replay has been stopped), the Secondary can take over the Primary role. If you plan to continue using the new Primary, then the Bunker for the original Primary cannot be used as a Bunker for the new Primary. You must configure another suitable host near the new Primary as a Bunker for the new Primary.