SharePoint Server의 고가용성 및 재해 복구 개념High availability and disaster recovery concepts in SharePoint Server

요약: 팜에 대한 최상의 전략을 선택할 수 있도록 SharePoint Server 2016 및 SharePoint 2013의 고가용성 및 재해 복구 개념에 대해 알아봅니다.Summary: Understand high availability and disaster recovery concepts in SharePoint Server 2016 and SharePoint 2013 so you can choose the best strategy for your farm.

SharePoint Server 팜에 대한 계획 및 시스템 사양을 만들 때 고가용성과 재해 복구는 우선 순위가 가장 높습니다. 팜 서버 가용성이 높지 않고 팜을 복구할 수 없으면 고성능이나 용량과 같은 다른 계획 요소는 필요하지 않을 것입니다.High availability and disaster recovery is the highest priority when you create a plan and system specifications for a SharePoint Server farm. Other aspects of the plan, such as high performance and capacity, are negated if farm servers are not highly available or a farm cannot be recovered.

효율적이고 중단되지 않는 작업 상태를 유지할 수 있는 효과적인 전략을 설계하고 구현하기 위해서는 고가용성 및 재해 복구의 기본 개념을 이해해야 합니다. 이러한 개념은 또한 사용자의 SharePoint 환경을 위한 최상의 기술 솔루션을 평가하고 선택하기 위해서도 중요합니다.To design and implement an effective strategy that maintains efficient and uninterrupted operations, you should understand the basic concepts of high availability and disaster recovery. These concepts are also important to evaluate and pick the best technical solutions for your SharePoint environment.

비즈니스 연속성 관리 소개Introduction to business continuity management

비즈니스 연속성 관리는 연속된 조직 운영과 관련된 위험 요소들을 정의, 평가 및 관리하는 데 도움을 주는 관리 프로세스 또는 프로그램입니다. 비즈니스 연속성 관리는 부정적인 상황으로 인해 정상적인 비즈니스 운영이 중단되었을 때 운영을 계속하기 위한 로드맵으로 사용할 수 있는 비즈니스 연속성 계획의 작성 및 유지 관리에 집중되어 있습니다. 이러한 부정적 상황은 자연적이거나 인위적이거나 복합적인 것일 수 있습니다. 연속성 계획은 다음과 같은 분석 내용 및 기본 자료로부터 만들어집니다.Business continuity management is a management process or program that defines, assesses, and helps manage the risks to the continued running of an organization. Business continuity management focuses on creating and maintaining a business continuity plan, which is a roadmap for continuing operations when normal business operations are interrupted by adverse conditions. These conditions can be natural, man-made, or a combination of both. A continuity plan is derived from the following analyses and inputs:

  • 비즈니스 영향 분석A business impact analysis

  • 위협 및 위험 분석A threat and risk analysis

  • 영향 시나리오 정의A definition of the impact scenarios

  • 문서화된 복구 요구 사항 집합A set of documented recovery requirements

비즈니스 연속성 관리에 대한 결과는 솔루션 설계 또는 식별된 옵션, 구현 계획, 테스트 및 조직 수용 계획, 유지 관리 계획 또는 일정으로 만들어집니다.The result is a solution design or identified options, an implementation plan, a testing and organization acceptance plan, and a maintenance plan or schedule.

비즈니스 연속성 관리의 예로 Microsoft의 비즈니스 연속성 프로그램 스냅숏을 제공하는 데이터 및 응용 프로그램에 대한 재해 복구 및 보호가 있습니다.An example of business continuity management is Disaster recovery and protection for data and applications, which provides a snapshot of the business continuity program at Microsoft.

IT(정보 기술)는 확실히 많은 조직에서 비즈니스 연속성 계획에 대한 중요한 요소입니다. 하지만 비즈니스 연속성은 이보다 범위가 넓습니다. 여기에는 중요한 중단 사고가 발생했을 때 또는 그러한 사고가 발생한 직후에 조직이 비즈니스를 계속 운영하도록 보장하는 데 필요한 모든 작업이 포함됩니다. 비즈니스 연속성 계획은 다음과 같은 요소들을 포함하지만 이에 제한되지 않습니다.Obviously Information Technology (IT) is a significant aspect of business continuity planning for many organizations. However, business continuity is more encompassing - it includes all the operations that are needed to make sure that an organization can continue to do business during and immediately after a major disruptive event. A business continuity plan includes, but is not limited to, the following elements:

  • 정책, 프로세스 및 절차policies, processes and procedures

  • 가능한 옵션 및 의사 결정 책임possible options and decision-making responsibility

  • 인적 자원 및 설비human resources and facilities

  • 정보 기술information technology

비즈니스 연속성 관리를 이야기할 때 종종 고가용성과 재해 복구가 언급되지만 이 둘은 사실 비즈니스 연속성 관리에 포함된 하위 개념입니다.Although high availability and disaster recovery are often equated to business continuity management; they are in fact, subsets of business continuity management.

고가용성 설명Describing high availability

특정 소프트웨어 응용 프로그램 또는 서비스에서 고가용성은 궁극적으로 최종 사용자의 경험과 기대치에 따라 측정됩니다. 수량화 및 인식할 수 있는 중단 시간이 비즈니스에 미치는 영향은 정보 손실, 자산 손상, 생산성 감소, 기회 비용, 계약상의 손해 또는 목표 손실이라는 용어로 표현될 수 있습니다.For a given software application or service, high availability is ultimately measured in terms of the end user's experience and expectations. The tangible and perceived business impact of downtime may be expressed in terms of information loss, property damage, decreased productivity, opportunity costs, contractual damages, or the loss of goodwill.

고가용성 솔루션의 주요 목표는 중단 시간이 미치는 영향을 최소화하거나 완화하는 것입니다. 이에 대한 올바른 전략은 기술 및 인프라 비용을 통해 비즈니스 프로세스와 SLA(서비스 수준 계약) 사이의 균형을 최적화할 수 있어야 합니다.The principal goal of a high availability solution is to minimize or mitigate the impact of downtime. A sound strategy for this optimally balances business processes and Service Level Agreements (SLAs) with technical capabilities and infrastructure costs.

플랫폼은 계약과 고객 및 이해 당사자의 기대 수준에 따라 가용성이 높은 것으로 고려됩니다. 시스템의 가용성은 다음과 같은 계산을 통해 표현될 수 있습니다.A platform is considered highly available per the agreement and expectations of customers and stakeholders. The availability of a system can be expressed as this calculation:

실제 가동 시간/예상 가동 시간 X 100%Actual uptime/Expected uptime X 100%

결과 값은 업계 솔루션들에서 자주 언급되는 일련의 9로 나타납니다. 이러한 수치는 다시, 연간 가능한 가동 시간 또는 그 반대로 가능한 중단 시간으로 변환되어 표현되기도 합니다.The resulting value is often expressed by industry in terms of the number of 9's that the solution provides; meant to convey an annual number of minutes of possible uptime, or conversely, minutes of downtime.

일련의 9Number of 9's 가용성 비율Availability Percentage 총 연간 중단 시간Total Annual Downtime
22.
99%99%
3일, 15시간3 days, 15 hours
33.
99.9%99.9% for solutions
8시간, 45분8 hours, 45 minutes
44.
99.99%99.99%
52분, 34초52 minutes, 34 seconds
55.
99.999%99.999%
5분, 15초5 minutes, 15 seconds

계획된 중단 시간과 계획되지 않은 중단 시간Planned versus unplanned downtime

시스템 중단은 예상되었거나 계획된 것일 수도 있고 계획되지 않은 장애로 인해 발생할 수도 있습니다. 적절하게 관리만 된다면 중단 시간을 나쁜 것으로만 바라볼 필요가 없습니다. 발생 가능한 중단 시간은 두 가지 유형으로 구분할 수 있습니다.System outages are either anticipated or planned for, or they are the result of an unplanned failure. Downtime need not be considered negatively if it is appropriately managed. There are two key types of foreseeable downtime:

  • 계획된 유지 관리. 소프트웨어 패치 적용, 하드웨어 업그레이드, 암호 업데이트, 오프라인 다시 인덱싱, 데이터 로드 또는 재해 복구 절차 리허설 등 계획된 유지 관리 작업을 위해 미리 일정이 발표되고 조정됩니다. 세밀하게 잘 관리되는 운영 절차는 중단 시간을 최소화하고 모든 데이터 손실을 방지해야 합니다. 계획된 유지 관리 활동은 보다 심각한 계획되지 않은 중단 시나리오를 방지하거나 완화하기 위해 필요한 투자로 이해될 수 있습니다.Planned maintenance. A time window is preannounced and coordinated for planned maintenance tasks such as software patching, hardware upgrades, password updates, offline re-indexing, data loading, or the rehearsal of disaster recovery procedures. Deliberate, well-managed operational procedures should minimize downtime and prevent any data loss. Planned maintenance activities can be seen as investments needed to prevent or mitigate other potentially more severe unplanned outage scenarios.

  • 계획되지 않은 중단 시간. 시스템, 인프라 또는 프로세스 수준의 오류는 계획되지 않았거나, 제어할 수 없는 상태로 발생할 수 있으며, 예상되더라도 발생 가능성이 매우 낮아서 그에 따른 영향이 그리 크지 않은 것으로 간주될 수도 있습니다. 강력한 고가용성 솔루션은 이러한 유형의 오류를 감지하고 중단으로부터 자동으로 복구를 수행하고 내결함성을 다시 설정할 수 있어야 합니다.Unplanned outage. System-level, infrastructure, or process failures may occur that are unplanned or uncontrollable, or that are foreseeable, but considered either too unlikely to occur, or are considered to have an acceptable impact. A robust high availability solution detects these types of failures, automatically recovers from the outage, and then reestablishes fault tolerance.

고가용성에 대한 SLA를 설정할 때는 계획된 유지 관리 활동과 계획되지 않은 중단 시간에 대해 별도의 KPI(핵심 성과 지표)를 계산해야 합니다. 이러한 방식을 통해 계획된 유지 관리 활동에 대한 투자와 계획되지 않은 중단 시간을 방지함으로써 얻게 되는 이익을 비교할 수 있습니다.When establishing SLAs for high availability, you should calculate separate key performance indicators (KPIs) for planned maintenance activities and unplanned downtime. This approach allows you to contrast your investment in planned maintenance activities against the benefit of avoiding unplanned downtime.

가용성 저하Degraded availability

고가용성은 모 아니면 도 식의 접근 방식으로 고려되어서는 안됩니다. 최종 사용자의 입장에서는 기능 또는 성능이 일부 제한되더라도 시스템이 완전히 중단되는 대신 시스템을 부분적으로 사용할 수 있는 것이 오히려 나을 수도 있습니다. 이러한 다양한 가용성 수준은 다음과 같이 분류할 수 있습니다.High availability should not be considered as an all-or-nothing proposition. As an alternative to a complete outage, it is often acceptable to the end user for a system to be partially available, or to have limited functionality or degraded performance. These varying degrees of availability include:

  • 읽기 전용 및 지연된 작업. 유지 관리 시간 또는 단계별 재해 복구 기간 중에도 데이터 검색은 가능하지만 새로운 워크플로 및 백그라운드 처리가 일시적으로 중단되거나 대기 중으로 전환될 수 있습니다.Read-only and deferred operations. During a maintenance window, or during a phased disaster recovery, data retrieval is still possible, but new workflows and background processing may be temporarily halted or queued.

  • 데이터 지연 및 응용 프로그램 응답성. 막대한 작업 부하, 처리 백로그 또는 부분적인 플랫폼 장애로 인해 제한된 하드웨어 리소스가 과도하게 커밋되거나 작게 조정될 수 있습니다. 사용자 경험은 저하될 수 있지만 작업은 덜 생산적인 방식으로 계속 수행될 수 있습니다.Data latency and application responsiveness. Due to a heavy workload, a processing backlog, or a partial platform failure, limited hardware resources may be over-committed or under-sized. User experience may suffer, but work may still get done in a less productive manner.

  • 부분적, 일시적 장애 또는 곧 발생할 장애. 오류 발생 시 작업을 재시도하거나 자동 교정을 수행하는 응용 프로그램 논리 또는 하드웨어 스택의 내결함성. 이러한 유형의 문제는 최종 사용자에게 데이터 지연 또는 응용 프로그램 응답 성능 저하로 표시될 수 있습니다.Partial, transient, or impending failures. Robustness in the application logic or hardware stack that retries or self-corrects upon encountering an error. These types of issues may appear to the end user as data latency or poor application responsiveness.

  • 부분적인 종단 간 장애. 계획되었거나 계획되지 않은 중단은 솔루션 스택의 수직 계층(인프라, 플랫폼 및 응용 프로그램) 내에서 또는 서로 다른 기능적 구성 요소 간에 수평적으로 안전한 방식으로 수행될 수 있습니다. 사용자는 영향을 받는 기능 또는 구성 요소에 따라 부분적인 성공 또는 성능 저하를 경험할 수 있습니다.Partial end-to-end failure. Planned or unplanned outages may occur gracefully within vertical layers of the solution stack (infrastructure, platform, and application), or horizontally between different functional components. Users may experience partial success or degradation, depending upon the features or components that are affected.

이러한 차선적인 시나리오의 수용 가능 여부는 저하된 가용성이 완전한 중단까지 이어지는 범위 및 단계별 재해 복구에서 중간 단계에 따라 결정됩니다.The acceptability of these suboptimal scenarios should be considered as part of a spectrum of degraded availability leading up to a complete outage, and as intermediate steps in a phased disaster recovery.

중단 시간 수량화Quantifying downtime

중단 시간이 발생할 경우, 계획된 것이든, 계획되지 않은 것이든 간에 기본적인 비즈니스 목표는 시스템을 다시 온라인 상태로 되돌리고 데이터 손실을 최소화하는 것입니다. 중단 시간이 발생하면 매분마다 직접 및 간접적인 비용을 초래합니다. 계획되지 않은 중단 시간이 발생한 경우에는 중단이 발생한 이유, 현재 시스템의 상태, 중단으로부터 시스템을 복구하는 데 필요한 단계를 확인하는 시간과 노력을 균형적으로 맞출 수 있어야 합니다.When downtime does occur, either planned, or unplanned, the primary business goal is to bring the system back online and minimize data loss. Every minute of downtime has direct and indirect costs. With unplanned downtime, you must balance the time and effort needed to determine why the outage occurred, what the current system state is, and what steps are needed to recover from the outage.

모든 중단 상황에서는 미리 결정된 지점에서 중단에 대한 조사 또는 유지 관리 작업 수행을 중지하고 시스템을 다시 온라인 상태로 전환하여 중단 상태를 복구하고, 필요에 따라 내결함성을 다시 설정하기 위한 비즈니스 의사 결정을 수행하거나 그러한 가능성을 모색해야 합니다.At a predetermined point in any outage, you should make or seek the business decision to stop investigating the outage or performing maintenance tasks, recover from the outage by bringing the system back online, and if needed, reestablish fault tolerance.

복구 목표Recovery objectives

데이터 중복성은 고가용성 데이터베이스 솔루션의 핵심 구성 요소입니다. 이를 위해서는 기본 SQL Server 인스턴스에서의 트랜잭션 활동이 하나 이상의 보조 인스턴스에 동기적으로 또는 비동기적으로 적용됩니다. 중단이 발생하면 진행 중이던 트랜잭션이 롤백되거나 데이터 전파 지연으로 인해 보조 인스턴스에서 트랜잭션이 손실될 수 있습니다.Data redundancy is a key component of a high availability database solution. Transactional activity on your primary SQL Server instance is synchronously or asynchronously applied to one or more secondary instances. When an outage occurs, transactions that were in flight may be rolled back, or they may be lost on the secondary instances due to delays in data propagation.

중단 시간에 대해서는 그로 인한 영향을 측정하고 비즈니스를 복구하는 데 걸리는 시간 및 복구된 마지막 트랜잭션에서 발생한 지연 시간을 기준으로 복구 목표를 설정할 수 있습니다.You can both measure the impact, and set recovery goals in terms of how long it takes to get back in business, and how much time latency there is in the last transaction recovered:

  • RTO(복구 시간 목표). 중단 상태가 진행되는 기간입니다. 초기 목표는 장애 조사를 시작할 수 있도록 최소한 읽기 전용 기능이 지원되는 온라인 상태로 시스템을 복구하는 것입니다. 하지만 주요 목표는 새 트랜잭션을 수행할 수 있는 지점까지 전체 시스템을 복원하는 것입니다.Recovery Time Objective (RTO). This is the duration of the outage. The initial goal is to get the system back online in at least a read-only capacity to facilitate investigation of the failure. However, the primary goal is to restore full service to the point that new transactions can take place.

  • RPO(복구 지점 목표). RPO는 허용 가능한 데이터 손실 측정 단위라고도 부릅니다. RPO는 장애 이전에 데이터 트랜잭션이 마지막으로 커밋된 시점과 장애 이후 처음으로 데이터가 복구된 시점 사이의 시간 간격 또는 지연 시간을 나타냅니다. 실제 데이터 손실은 장애 시점의 데이터 작업 부하, 장애 유형 및 사용된 고가용성 솔루션 유형에 따라 다를 수 있습니다.Recovery Point Objective (RPO). This is often referred to as a measure of acceptable data loss. It is the time gap or latency between the last committed data transaction before the failure and the most recent data recovered after the failure. The actual data loss can vary depending upon the workload on the system at the time of the failure, the type of failure, and the type of high availability solution used.

    참고

    이와 관련된 목표로 RLO(복구 수준 목표) 가 있습니다. 이 목표는 데이터를 복구할 수 있는 정도를 세부적으로 정의합니다. 즉, 전체 팜, 웹 응용 프로그램, 사이트 모음, 사이트, 목록 또는 라이브러리, 항목 등으로 복구 수준 목표를 세분화할 수 있습니다. 자세한 내용은 SharePoint Server의 백업 및 복구 계획을 참조하십시오.A related objective is Recovery level objective (RLO). This objective defines the granularity with which you must be able to recover data — whether you must be able to recover the whole farm, Web application, site collection, site, list or library, or item. For more information, see Plan for backup and recovery in SharePoint Server.

RTO 및 RPO 값은 비즈니스에서 허용되는 중단 시간, 허용 가능한 데이터 손실 정도를 나타내는 목표 및 가용성 상태 모니터링을 위한 측정 단위로 사용되어야 합니다.You should use RTO and RPO values as goals that indicate business tolerance for downtime and acceptable data loss, and as metrics for monitoring availability health.

ROI 또는 기회 비용의 당위성Justifying ROI or opportunity cost

중단 시간에 대한 비즈니스 비용은 재무적 단위 또는 고객 영업의 형태로 표현될 수 있습니다. 이러한 비용은 시간에 따라 누적되거나 중단 시간 중 특정 시점에 발생할 수도 있습니다. 특정 복구 시간 및 데이터 복구 지점에 따라 중단 발생 비용을 계획하는 것 외에도 RTO 및 RPO 목표를 달성하기 위해 또는 중단 방지를 위한 모든 노력에 필요한 비즈니스 프로세스 및 인프라 투자도 계산할 수 있습니다. 이러한 투자 분야는 다음과 같습니다.The business costs of downtime may be either financial or in the form of customer goodwill. These costs may accrue with time, or they may be incurred at a certain point in the outage window. In addition to projecting the cost of incurring an outage with a given recovery time and data recovery point, you can also calculate the business process and infrastructure investments needed to attain your RTO and RPO goals or to avoid the outage all together. These investment themes should include:

  • 중단 시간 방지. 처음부터 중단이 발생하지 않으면 중단 복구 비용을 완전히 회피할 수 있습니다. 이러한 투자에는 격리된 장애 지점 및 사전 예방적 조치로 계획된 중단 시간 사이에 작업 부하를 분산하는 내결함성 및 중복성을 갖는 하드웨어 또는 인프라의 비용이 포함됩니다.Avoiding downtime. Outage recovery costs are avoided all together if an outage doesn't occur in the first place. Investments include the cost of fault-tolerant and redundant hardware or infrastructure, distributing workloads across isolated points of failure, and planned downtime for preventive maintenance.

  • 복구 자동화. 시스템 장애가 발생할 경우 자동화되고 투명한 방식의 복구를 사용하면 중단 시간이 고객 환경에 미치는 영향을 크게 완화시킬 수 있습니다.Automating recovery. If a system failure occurs, you can greatly mitigate the impact of downtime on the customer experience through automatic and transparent recovery.

  • 리소스 활용률. 보조 또는 대기 인프라는 중단이 발생할 경우를 대비하여 유휴 상태로 유지될 수 있지만, 읽기 전용 작업 부하에 활용하거나 사용 가능한 모든 하드웨어 간에 작업 부하를 분산하여 전반적인 시스템 성능 향상에 도움을 줄 수 있습니다.Resource utilization. Secondary or standby infrastructure can sit idle, awaiting an outage. It also can be leveraged for read-only workloads, or to improve overall system performance by distributing workloads across all available hardware.

특정 RTO 및 RPO 목표에 따라 필요한 가용성 및 복구 투자는 중단 시간에 대한 예상 비용과 함께 시계열 함수로 표현되고 정당화될 수 있습니다. 실제로 중단이 발생하면 이를 통해 경과된 중단 시간을 기준으로 비용에 기반한 의사 결정을 수행할 수 있습니다.For given RTO and RPO goals, the needed availability and recovery investments, combined with the projected costs of downtime, can be expressed and justified as a function of time. During an actual outage, this allows you to make cost-based decisions based on the elapsed downtime.

가용성 상태 모니터링Monitoring availability health

운영적인 관점에서 봤을 때, 실제 중단이 발생한 동안에는 모든 관련 변수를 고려해서 ROI 또는 기회 비용을 실시간으로 계산하려고 하지 않는 것이 좋습니다. 대신 예상된 RPO를 대신해서 대기 인스턴스에서 데이터 지연 시간을 모니터링해야 합니다.From an operational point of view, during an actual outage, you should not attempt to consider all relevant variables and calculate ROI or opportunity costs in real time. Instead, you should monitor data latency on your standby instances as a proxy for expected RPO.

또한 중단이 발생했으면, 일단 근본 원인 조사를 위해 투입되는 초기 시간을 제한하고, 대신 복구 환경의 상태가 유효한지 확인하는 데 집중한 후 이후 예측 분석을 위해 세부 시스템 로그 및 보조 데이터 복사본을 활용해야 합니다.In the event of an outage, you should also limit the initial time spent investigating the root cause during the outage, and instead focus on validating the health of your recovery environment, and then rely upon detailed system logs and secondary copies of data for subsequent forensic analysis.

재해 복구 계획Planning for disaster recovery

고가용성 관련 투자는 중단이 발생하는 것을 방지하기 위한 노력이지만 재해 복구 투자는 중단 후 고가용성을 다시 설정하기 위한 노력입니다.While high availability efforts entail what you do to prevent an outage, disaster recovery efforts address what is done to re-establish high availability after the outage.

재해 복구 절차와 책임은 실제 중단이 발생하기 전에 최대한 정형화되어 있어야 합니다. 실제 모니터링 및 경고를 기반으로 자동 또는 수동 장애 조치(failove) 및 복구 계획을 시작할지 여부는 사전 설정된 RTO 및 RPO 임계값에 따라 결정됩니다. 올바른 재해 복구 계획의 범위에는 다음과 같은 항목들이 포함되어야 합니다.As much as possible, disaster recovery procedures and responsibilities should be formulated before an actual outage occurs. Based upon active monitoring and alerts, the decision to initiate an automated or manual failover and recovery plan should be tied to pre-established RTO and RPO thresholds. The scope of a sound disaster recovery plan should include:

  • 세분화된 장애 및 복구 수준. 장애가 발생한 위치 및 장애 유형에 따라 데이터 센터, 인프라, 플랫폼, 응용 프로그램 또는 작업 부하 등 서로 다른 수준에서 교정 조치를 취할 수 있습니다.Granularity of failure and recovery. Depending upon the location and type of failure, you can take corrective action at different levels; that is, data center, infrastructure, platform, application, or workload.

  • 원본 자료 조사. 기준선 및 최근 모니터링 내역, 시스템 경고, 이벤트 로그 및 진단 쿼리 등은 모두 적합한 당사자가 즉시 액세스할 수 있습니다.Investigative source material. Baseline and recent monitoring history, system alerts, event logs, and diagnostic queries should all be readily accessible by appropriate parties.

  • 종속성 조정. 응용 프로그램 스택 내에서 그리고 여러 당사자 간에 시스템 및 비즈니스의 종속성을 확인해야 합니다.Coordination of dependencies. Within the application stack, and across stakeholders, what are the system and business dependencies?

  • 의사 결정 트리. 역할 책임, 오류 분류, 장애 조치(failover) 기준(RPO 및 RTO 목표 기반), 처방적 복구 단계를 포함하는 미리 결정되었고, 반복 가능하며, 유효성이 검증된 의사 결정 트리가 필요합니다.Decision tree. A predetermined, repeatable, validated decision tree that includes role responsibilities, fault triage, failover criteria in terms of RPO and RTO goals, and prescribed recovery steps.

  • 유효성 검사. 중단으로부터 복구하기 위한 단계를 수행한 후 시스템이 정상 운영 상태로 복구되었다는 것을 확인하기 위한 조치가 필요합니다.Validation. After taking steps to recover from the outage, what must be done to verify that the system has returned to normal operations?

  • 문서화. 위에 나열된 모든 항목들을 일련의 문서로 작성하고 제삼자도 최소한의 도움만으로 복구 계획을 실행할 수 있도록 충분히 자세하고 명확하게 기술합니다. 이러한 유형의 문서화를 일반적으로 '자습서' 또는 '설명서'라고 부릅니다.Documentation. Capture all of the above items in a set of documentation, with sufficient detail and clarity so that a third party team can execute the recovery plan with minimal assistance. This type of documentation is commonly called a 'run book' or a 'cook book'.

  • 복구 리허설. RTO 목표에 대한 기준 요구 사항을 설정하기 위해 재해 복구 계획을 정기적으로 실행해야 하며, 주 시스템의 기본 프로덕션 사이트를 재해 복구 사이트의 보조 사이트와 정기적으로 순환시키는 것이 좋습니다.Recovery rehearsals. Regularly exercise the disaster recovery plan to establish baseline expectations for RTO goals, and consider regular rotation of hosting the primary production site on the primary and each of the disaster recovery sites.

참고 항목See also

개념Concepts

SharePoint Server의 재해 복구 전략 선택Choose a disaster recovery strategy for SharePoint Server