Disaster Recovery through cloning drives in sql server 2014 enterprise

Question

I am a DBA noob and recently my work has considered to have a disaster recovery plan for their production DB lets say A (sql server 2014 enterprise). The production server A and Disaster recovery server B are in different geographical locations. We have just 10 databases in the production A and each DB size does not exceed 4GB. During the installation, I have changed the default locations to D, E and F respectively and the system databases and tempdb files are stored in D and E drive as well. However I left the root directory as default in C drive in both the servers A and B. I have followed the similar path configuration in Disaster Recovery (DR) server as well.

So my management plan is to make clone copies in Disaster Recovery (B) server of all LUNs that are replicated each hour from production server A. Once this copies ( D and E drive from A) are completed, they are planning to mount these in DR server.

So my question, is this appropriate way to follow Disaster Recovery ? Also, what issues I might face ? I am little worried whether databases will be up and running once this mounting is completed in DR server ? If not what steps should I consider ? Any suggestions highly appreciated.

  Data : D:\MSSQL\Data\
  Log: E:\MSSQL\Data\
  Backup: F:\MSSQL\Backup

Answer 1

Firstly, you need to determine what the acceptable Recovery Point Objective (total data loss) and Recovery Time Objective (time taken to restore the system) is for each database on your production server.

If the amount of data loss your business is willing to accept is less than the interval that your disks are replicated to your DR site then this won't work as a strategy. If it takes longer to clone and provision the disks for your DR server than the RTO, then this solution won't work.

Download Brent Ozar's First Responder Kit, which includes a High Availability and Disaster Recovery worksheet to help you determine and design a suitable DR solution for your databases.

There are many options within SQL Server itself for providing DR capabilities that might be better suited than SAN replication (although that is always an option). Log Shipping, for example, is a simple, low-cost solution that might achieve lower RPO and RTO than hourly SAN replication and can be simpler than having to clone LUNs and attach them to the SQL Server.