Implementing Disaster Recovery with SRDF

-

 

How to perform disaster recovery with two locations using SRDF:

 

Disaster recovery (DR) is an essential aspect of any IT infrastructure, especially for critical systems and applications such as SQL Server. There are many DR solutions available, but one of the most popular ones is SRDF, a data replication solution from Dell EMC. In this blog post, we'll discuss how to perform disaster recovery with two locations using SRDF and the responsibilities of the different teams involved in the process.

 

Identify the Primary and Secondary Locations:

The first step is to identify which location is the primary data center and which is the secondary data center. For example, let's say that the primary location is in New York, and the secondary location is in Chicago.

 

Set up SRDF Replication:

The storage team is responsible for configuring the storage arrays at both the New York and Chicago data centers for SRDF replication. This involves creating a replication relationship between the arrays, configuring the replication mode (synchronous or asynchronous), and setting up replication schedules.

 

Initialize the Replication:

The storage team is also responsible for initializing the replication by copying the initial data from the New York data center to the Chicago data center. This can be done using a full backup or by using an incremental backup and restore method.

 

Monitor the Replication:

The storage team is responsible for monitoring the replication to ensure that it is working correctly. This includes monitoring the replication lag, ensuring that the replication schedules are being followed, and checking the replication status regularly.

 

Test the Disaster Recovery Plan:

The DBA team is responsible for performing regular disaster recovery tests to ensure that the replicated data is available in the Chicago data center and that the failover process works correctly. This involves simulating a disaster scenario and failover to the Chicago data center to ensure that critical systems can be brought back online quickly and efficiently. It also involves working with the Windows team to perform DNS flip and failover and ensuring that the SQL Server cluster is taken offline before the DR test and brought back online post-DR.

 

Document the Disaster Recovery Plan:

The storage team, Windows team, and DBA team are jointly responsible for documenting the disaster recovery plan, including the replication schedules, failover procedures, and contact information for key personnel. This documentation should be kept up-to-date and shared with all relevant stakeholders.

 

Conclusion:

By working together, the storage team, Windows team, and DBA team can ensure that organizations with data centers in multiple locations have a comprehensive DR plan in place that protects critical systems and data in the event of a disaster.

 

Reference: https://infohub.delltechnologies.com/l/sap-landscape-consolidation-with-dell-components-1/srdf-replication-3


Comments

Post a Comment

Popular posts from this blog

Interview Questions on AOAG

-
1.What are the prerequisites for setting up AlwaysOn? 2.How do you set up replication in AlwaysOn environment? 3.How do you manage replication during Windows patching or failover if replication has been set up in AlwaysOn? 4.How do you sync logins in AlwaysOn? 5.How do you sync users in AlwaysOn secondary? 6.How do you add database files in AlwaysOn? 7.How do you perform an in-place upgrade of SQL Server in a AlwaysOn environment? 8.What is the procedure for SQL Server patching in AlwaysOn? 9.How do you failover a mirror server if replication has been set up? 10.What is the SPN concept in AlwaysOn? 11.What is file share in AlwaysOn? 12.How do you create multiple AlwaysOn listeners? 13.How do you check latency in AlwaysOn? 14.What is the command used to check latency in replication without using GUI? 15.What are DNS issues in AlwaysOn? 16.If a user is connecting to the primary and not able to connect to the secondary, and the secondary is in read-only mode, how do you fix the issue in A
Read more

All about SQL Server Execution Plan

-
Introduction: SQL Server execution plans hold the key to optimizing query performance. By understanding the various operators and costs within an execution plan, you can uncover hidden inefficiencies and enhance the speed and efficiency of your queries. In this blog, we will dive deep into common operators like Index Scan, Index Seek, Nested Loops, Merge Join, and Sort, and demystify their associated costs. Index Scan: Scans the entire index to locate the requested data. The cost is directly proportional to the number of rows in the index. A high cost may indicate inadequate index utilization or non-selective queries. Index Seek: Directly seeks into the index for specific rows. The cost is proportional to the number of retrieved rows. A high cost might indicate non-selective queries or underutilized indexes. Nested Loops: Joins tables by iterating through each row in one table for matches in the other. The cost is determined by the product of rows in both tables. A high cost could sugg
Read more

Understanding SQL Server Patching: GDR versus CU

-
Introduction: Are you curious about the distinctions between GDR and CU when Microsoft releases a KB article with new fixes or security updates? In this article, we'll delve into the details and provide some helpful tips along the way. Setting the Stage : GDR versus CU: Let's begin by understanding Microsoft's explanation: Microsoft defines the General Distribution Release (GDR) and Cumulative Update (CU) designations as two different servicing options for SQL Server baseline releases, which can be either an RTM release or a Service Pack release. Determining the Baseline: To determine your SQL Server's baseline version, you can use various methods. One way is by executing the following T-SQL code: SELECT @@VERSION; Alternatively, you can check the version by examining the sqlserver.exe file in the corresponding \Binn directory of your installation. Another option is using the SERVERPROPERTY() function for more detailed version information, but that is beyond the scope
Read more