Disaster recovery management pdf

On Linux, a value of 0 will not allow automatic failover, so on Linux, when using synchronous with automatic failover, the value must be set higher than 0 to achieve automatic failover.

A distributed transaction can be done in one of two ways:. Another enhancement to DTC support for availability groups is that in SQL Server , enabling support for DTC to an availability group could only be done when the availability group was created, and could not be added later.

Clustered installations have been a feature of SQL Server since version 6. This means that everything inside the instance, including databases, SQL Server Agent jobs, linked servers, et al. All FCIs require some sort of shared storage, even if it is provided via networking.

The FCI's resources can only be running and owned by one node at any given time. In the picture below, the first node of the cluster owns the FCI, which also means it owns the shared storage resources associated with it denoted by the solid line to the storage.

There is zero data loss with an FCI, but the underlying shared storage is a single point of failure since there is one copy of the data. FCIs are often combined with another availability method, such as an availability group or log shipping, to have redundant copies of databases. The additional method deployed should use physically separate storage from the FCI. When the FCI fails over to another node, it stops on one node and starts on another, not unlike powering off a server and turning it on.

An FCI goes through the normal recovery process, meaning any transactions that need to be rolled forward will be, and any transactions that are incomplete will be rolled back. Therefore, the database is consistent from a data point to the time of the failure or manual failover, hence no data loss.

Databases are only available after recovery is complete, so recovery time will depend on many factors, and will generally be longer than failing over an availability group.

The tradeoff is that when you fail over an availability group, there may be additional tasks required to make a database usable, such as enabling a SQL Server Agent job. Like an availability group, FCIs abstract which node of the underlying cluster is hosting it. An FCI always retains the same name. Applications and end users never connect to the nodes; the unique name assigned to the FCI is used.

An FCI can participate in an availability group as one of the instances hosing either a primary or secondary replica. If recovery point and recovery time objectives are more flexible, or databases are not considered to be highly mission critical, log shipping is another proven availability feature in SQL Server.

Based on SQL Server's native backups, the process for log shipping automatically generates transaction log backups, copies them to one or more instances known as a warm standby, and automatically applies the transaction log backups to that standby. Log shipping uses SQL Server Agent jobs to automate the process of backing up, copying, and applying the transaction log backups.

Arguably the biggest advantage of using log shipping in some capacity is that it accounts for human error. The application of transaction logs can be delayed. While log shipping is easy to configure, switching from the primary to a warm standby, known as a role change, is always manual.

A role change is initiated via Transact-SQL, and like an availability group, all objects not captured in the transaction log must be manually synchronized. Log shipping also needs to be configured per database, whereas a single availability group can contain multiple databases. Unlike an availability group or FCI, log shipping has no abstraction for a role change. Applications must be able to handle this. When your primary availability location experiences a catastrophic event like an earthquake or flood, the business must be prepared to have its systems come online elsewhere.

This section will cover how the SQL Server availability features can assist with business continuity. One of the benefits of availability groups is that both high availability and disaster recovery can be configured using a single feature.

Without the requirement for ensuring that shared storage is also highly available, it is much easier to have replicas that are local in one data center for high availability, and remote ones in other data centers for disaster recovery each with separate storage. Having additional copies of the database is the tradeoff for ensuring redundancy. An example of an availability group that spans multiple data centers is shown below. One primary replica is responsible for keeping all secondary replicas synchronized.

Outside of an availability group with a cluster type of none, an availability group requires that all replicas are part of the same underlying cluster whether it is a WSFC or Pacemaker.

This means that in the picture above, the WSFC is stretched to work in two different data centers, which adds complexity. Stretching clusters across distance adds complexity. Introduced in SQL Server , a distributed availability group allows an availability group to span availability groups configured on different clusters.

This decouples the requirement to have the nodes all participate in the same cluster, which makes configuring disaster recovery much easier. For more information on distributed availability groups, see Distributed availability groups. FCIs can be used for disaster recovery. As with a normal availability group, the underlying cluster mechanism must also be extended to all locations, which adds complexity.

There is an additional consideration for FCIs: the shared storage. The same disks need to be available in the primary and secondary sites, so an external method such as functionality provided by the storage vendor at the hardware layer or using storage Replica in Windows Server, is required to ensure that the disks used by the FCI exist elsewhere.

Log shipping is one of the oldest methods of providing disaster recovery for SQL Server databases. Log shipping is often used with availability groups and FCIs to provide cost-effective and simpler disaster recovery where other options may be challenging due to environment, administrative skills, or budget.

Similar to the high availability story for log shipping, many environments will delay the loading of a transaction log to account for human error. When deploying new instances or upgrading old ones, a business can't tolerate long outage. This section will discuss how the availability features of SQL Server can be used to minimize the downtime in a planned architecture change, server switch, platform change such as Windows Server to Linux or vice versa , or during patching.

Other methods, such as using backups and restoring them elsewhere, can also be used for migrations and upgrades. They are not discussed in this paper. An existing instance containing one or more availability groups can be upgraded in place to later versions of SQL Server.

While this will require some amount of downtime, with the right amount of planning, it can be minimized. If the goal is to migrate to new servers and not change the configuration including the operating system or SQL Server version , those servers could be added as nodes to the existing underlying cluster and added to the availability group. Once the replica or replicas are in the right state, a manual failover could occur to a new server, and then the old ones could be removed from the availability group, and ultimately, decommissioned.

Finally, availability groups with a cluster type of None can also be used for migration or upgrading. You cannot mix and match cluster types in a typical availability group configuration, so all replicas would need to be a type of None.

A distributed availability group can be used to span availability groups configured with different cluster types. This method is also supported across the different OS platforms. All variants of availability groups for migrations and upgrades allow the most time consuming portion of the work to be done over time - data synchronization.

When it comes time to initiate the switch to the new configuration, the cutover will be a brief outage versus one long period of downtime where all the work, including data synchronization, would need to be completed. Availability groups can provide minimal downtime during patching of the underlying OS by manually failing over the primary to a secondary replica while the patching is being completed. From an operating system perspective, doing this would be more common on Windows Server since often, but not always, servicing the underlying OS may require a reboot.

Patching Linux sometimes needs a reboot, but it can be infrequent. Patching SQL Server instances participating in an availability group can also minimize downtime depending on how complex the availability group architecture is. To patch servers participating in an availability group, a secondary replica is patched first.

Once the right number of replicas are patched, the primary replica is manually failed over to another node to do the upgrade. Any remaining secondary replicas at that point can be upgraded, too. FCIs on their own cannot assist with a traditional migration or upgrade; an availability group or log shipping would have to be configured for the databases in the FCI and all other objects accounted for. A manual failover can be initiated, which means a brief outage instead of having the instance completely unavailable for the entire time that Windows Server is being patched.

Log shipping is still a popular option to both migrate and upgrade databases. Similar to availability groups, but this time using the transaction log as the synchronization method, the data propagation can be started well in advance of the server switch. At the time of the switch, once all traffic is stopped at the source, a final transaction log would need to be taken, copied, and applied to the new configuration.

At that point, the database can be brought online. Log shipping is often more tolerant of slower networks, and while the switch may be slightly longer than one done using an availability group or a distributed availability group, it is usually measured in minutes - not hours, days, or weeks.

Similar to availability groups, log shipping can provide a way to switch to another server in the event of patching. There are two other deployment methods for SQL Server on Linux: containers and using Azure or another public cloud provider. The general need for availability as presented throughout this paper exists regardless of how SQL Server is deployed.

These two methods have some special considerations when it comes to making SQL Server highly available. A container is a complete image of SQL Server that is ready to run. However, there is currently no native support for clustering, and thus, direct high availability or disaster recovery. Currently, the options to make SQL Server databases available using containers would be log shipping and backup and restore.

While an availability group with a cluster type of None can be configured, as noted earlier, it is not considered a true availability configuration. Microsoft is looking at ways to enable availability groups or FCIs using containers. If you are using containers today, if the container is lost, depending on the container platform, it can be deployed again and attached to the shared storage that was used.

Some of this mechanism is provided by the container orchestrator. While this does provide some resiliency, there will be some downtime associated with database recovery and is not truly highly available as it would be if using an availability group or FCI. Some distributions ship them as part of the platform, others rely on external hardware and software vendors. Check with your preferred Linux distribution to see what forms of STONITH are provided so that a supported solution can be deployed in the public cloud.

With SQL Server now supported on both Windows Server and Linux, this section covers the scenarios of how they can work together for availability in addition to other purposes, and the story for solutions that will incorporate more than one Linux distribution.

Distributed availability groups are designed to span availability group configurations, whether those two underlying clusters underneath the availability groups are two different WSFCs, Linux distributions, or one on a WSFC and the other on Linux. A distributed availability group will be the primary method of having a cross platform solution.

A distributed availability group is also the primary solution for migrations such as converting from a Windows Server-based SQL Server infrastructure to a Linux-based one if that is what your company wants to do. As noted above, availability groups, and especially distributed availability groups, would minimize the time that an application would be unavailable for use.

If an availability group is configured with a cluster type of None, it can span Windows Server and Linux, as well as multiple Linux distributions. Since log shipping is based on backup and restore, and there are no differences in the databases, file structures, etc. This means that log shipping can be configured between a Windows Server-based SQL Server installation and a Linux one, as well as between distributions of Linux.

Everything else remains the same. The only caveat is that log shipping, just like an availability group, cannot work when the source is at a higher SQL Server major version against a target that is at a lower version of SQL Server. Since their introduction in SQL Server , secondary replicas have had the ability to be used for read-only queries. There are two ways that can be achieved with an availability group: by allowing direct access to the secondary as well as configuring read only routing which requires the use of the listener.

SQL Server introduced the ability to load balance read-only connections via the listener using a round robin algorithm, allowing read-only requests to be spread across all readable replicas. Short term: Recovery and Rehabilitation 1. It involves the restoration of basic services e. The goal of this phase is not only to restore what existed previously but also to set communities on a better and safer development path and to facilitate resilient recovery. Community-Based Needs Assessments In order to come up with a proper and acceptable program for recovery and rehabilitation, it is also important to understand the felt needs of affected communities.

Consulting affected populations through interviews prior to any recovery program ensures public acceptance and support of any planned endeavour. A needs assessment helps prioritize particular areas that need the most immediate action for rehabilitation. Infrastructure and Services b. Community Livelihood c. Priorities for Habitat Restoration Page 10 of 14 c. Long Term: Reconstruction and Development Measures to rehabilitate human communities and natural ecosystems are critical in post-disaster situations in order to support human lives and sustain the delivery of ecosystem goods and services such as food, fuel and protection from natural events.

A key concept here is climate-resilient recovery CRR where communities are not only provided with assistance to recover from climatic change events but are also equipped to deal with future disasters better. Reconstruction is a much longer-term activity that will involve permanent rebuilding, improved infrastructure, and recovery with enhanced preparation for the next climate change-related event. Climate-Resilient Livelihood 2. Climate-Resilient Infrastructure 3.

Ecological Restoration Ecological restoration encompasses intentional human interventions that are aimed to assist the recovery of ecosystems and habitats after disturbance or damage. Recovery is reckoned to have been achieved when the system contains sufficient living e. Restoration can promote the preservation of the biodiversity of the ecosystem, conservation of endemic and indigenous species, and the sustainable management of the ecosystem.

Incorporation of Indigenous Ideas and Practices Traditional and local conceptions or misconceptions? Regardless of their effects, it is important that they should be taken into consideration and respected at all times. And, if beneficial, these might even be useful to be developed further and then integrate in pre- and Page 11 of 14 post-disaster planning e.

Case Studies B. Assumptions, Dilemmas and Guiding Principles 1. Dangerous assumptions i. Political support will be maintained throughout the period needed for recovery. There will be continuity of funding support throughout. There will be synchronization of perceptions, expectations and capacities of the parties involved in rehabilitation and reconstruction processes. There will be adequate levels of competency to undertake the required rehabilitation and reconstruction tasks.

Recovery is confined to physical reconstruction and it must precede economic and social recovery. Rapid reconstruction is possible without any sacrifice in quality or safety. There will be high levels of acceptance and obedience to the codes and controls that the government imposes. Effective reconstruction is an isolated process from normal pre- disaster planning and building.

Dilemmas and alternatives i. Rapid damage survey versus accurate technical surveys ii. Repairs versus rebuilding iii. Safety standards versus rapid reconstruction iv.

Relocation versus reconstruction on the same site v. Participation versus rapid response Page 12 of 14 vi. Special organization versus existing organization vii. Public versus private investment viii. Physical reconstruction versus economic rehabilitation 3. Guiding principles i. The planning of recovery needs to be broad in scope and fully integrated.

A balance has to be achieved between the conflicting yet vital processes of reform and conservatism iii. Reconstruction should not be delayed to await political, administrative or economic reform. Economic recovery should be regarded as a prerequisite for rapid physical recovery. Reconstruction offers unique opportunities to introduce a range of measures to reduce future risks to persons and property.

The relocation of entire communities is usually not effective and is rarely feasible. Recovery actions can be regarded as a therapeutic process to assist individuals and their communities to rebuild their lives and livelihoods.

The basis of effective recovery is the availability and maintenance of an adequate flow of cash and credit throughout the entire process of recovery. Successful reconstruction is closely linked to the resolution of land ownership problems x. To aid recovery it is preferable to maximize the use of local resources. Physical recovery is dependent on the development of effective local institutions as well as training and leadership at all levels and in all sectors. Political commitment is vital to ensure effective recovery.

Page 13 of 14 C. Activity: Application Time Allotment: 0. Objectives: a. To be able to contextualize and localize rehabilitation and recovery situations b. To identify gaps in knowledge, skills, infrastructure and resources that are needed for rehabilitation and recovery B. Materials: Guide questions printed on sheets a.

We have listed several operational dilemmas and alternatives which are common in the planning for rehabilitation. Which of these are most important to resolve in your own community? Do you have ideas on how best to address them? Procedure: a. Each participant will be given time to answer each of the questions which will be shared with the group. At the end of the activity, participants with the most interesting experiences and insights deemed by group members will be invited to share these in front.

Synthesis - to be facilitated by session trainor Time Allotment: 10 mins E. Disaster Rehabilitation: Towards a New Perspective. Reef Restoration Concepts and Guidelines: Making sensible management choices in the face of uncertainty.

Download from www. Guidance Note on Recovery: Climate Change. Post Laryngectomy Voice Rehabilitation. Post Acute Rehabilitation Services. Post Stroke Rehabilitation. Post-Disaster Recovery Guidelines. Post Disaster Recov Dilemma. Post Disaster Surveillance. Rehabilitation of Post-Surgical Orthopedic Patient. Rehabilitation of post surgical orthopaedic patient.

Regional Knowledge Forum on Post-disaster Recovery. Role of Dentists in Post Disaster Identification. Punishment and Rehabilitation or Punishment as Rehabilitation. Close Save changes. E-mail Back to log-in.