0

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. enter image description here

  Data : D:\MSSQL\Data\
  Log: E:\MSSQL\Data\
  Backup: F:\MSSQL\Backup
Improve this question

1 Answer 1

Reset to default
0

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.

Improve this answer
2
  • thanks for your elaborate response. If I manually perform backup and restore of all the DB's in the PROD, it is usually around 2.5 hrs. I will look up about Log Shipping. However, do you think cloning the LUNs and attaching them to DR sql server will automatically make the databases up and running ? Or do I have to perform any other tasks to bring it up ? Thanks for your time.
    – data_weed
    Oct 17, 2019 at 6:25
  • No you will most likely have follow up tasks. Your DR server will probably have a different name and instance of SQL Server, so the DBs won't just attach, you need to restore/recover them which involves additional work. As they won't be cleanly disconnected from the original server, getting them back online may be harder. This is why you should look at SQL native options such as log shipping that require some manual work, but it is simple and quick.
    – HandyD
    Oct 17, 2019 at 22:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.