디저스터 리커버리

Disaster recovery
이 기사는 비즈니스 연속성 계획에 관한 것입니다.사회적 재해 복구에 대해서는 긴급 관리를 참조하십시오.

disaster recovery에는 자연재해 또는 인재에 의한 재해 후에 중요한 테크놀로지 인프라스트럭처와 시스템을 복구 또는 계속적으로 사용할 수 있도록 하기 위한 일련의 정책, 툴 및 절차가 포함됩니다.disaster recovery는 비즈니스 연속성이 아니라 중요한 비즈니스[1] 기능을 지원하는 IT(정보기술) 또는 테크놀로지 시스템에 초점을 맞춥니다.여기에는 중대한 중단 이벤트에도 불구하고 비즈니스의 모든 중요한 측면을 계속 작동시키는 것이 포함됩니다. 따라서 비즈니스 [2][3]연속성의 하위 집합으로 간주할 수 있습니다.disaster recovery는 프라이머리 사이트가 당분간 복구 불가능한 것으로 가정하고 데이터와 서비스를 secondary survey site에 복원하는 프로세스를 나타냅니다.이것은 원래 위치로 복원하는 것과는 반대입니다.

IT 서비스의 계속성

IT 서비스 연속성[4][5](ITSC)은 BCP([6]비즈니스 연속성 계획)의 서브셋으로, RPO(복구 시점 목표) 및 RTO(복구 시간 목표)에 초점을 맞춥니다.여기에는 IT 디저스터 리커버리 계획과 광범위한 IT 복원 계획이라는 두 가지 계획이 포함됩니다.또, IT인프라스트럭처와 (음성) 텔레포니나 데이터 통신등의 통신에 관한 서비스도 통합하고 있습니다.

백업 사이트의 원칙

주요 기사: 백업 사이트

계획에는 핫 사이트, 웜 사이트, 콜드 사이트 등 백업 사이트와 연속성을 위해 필요한 하드웨어를 갖춘 스탠바이 사이트의 준비가 포함됩니다.

2008년, 영국 표준 협회는 비즈니스 연속성 표준 BS 25999와 연계하여 지원하는 BS25777이라는 특정 표준을 출시하여 컴퓨터 연속성을 비즈니스 연속성에 맞춥니다.이는 2011년 3월 ISO/IEC 27031의 "보안 기술 - 비즈니스 [7]연속성을 위한 정보통신 기술 준비 지침"에 따라 철회되었습니다.

ITIL은 이러한 [8]용어의 일부를 정의했습니다.

복구 시간 목표

리커버리 타임 목표([9][10]RTO)는 비즈니스 [11]연속성 중단과 관련된 허용할 수 없는 결과를 피하기 위해 재해(또는 중단) 후 비즈니스 프로세스를 복원해야 하는 목표 기간 및 서비스 수준입니다.

비즈니스 연속성 계획 방법에 따르면 RTO는 프로세스 소유자에 의해 비즈니스 영향 분석(BIA) 중에 확립됩니다.여기에는 대체 또는 수동 회피책의 기간을 특정하는 것도 포함됩니다.

RPO 또는 RTO('목표')를 충족하지 못하는 더 긴 '실제' 시간을 보여주는 예.그림은 RPO와 RTO라는 용어를 개략적으로 나타낸 것입니다.

이 주제에 관한 문헌에서는 RTO를 리커버리 포인트 목표(RPO)의 보완으로 언급하고 있으며 허용 가능한 또는 "허용 가능한" ITSC 퍼포먼스의 한계를 나타내는2가지 지표가 있습니다.RTO 및 RPO는 통상적인 비즈니스 프로세스 기능에서 손실된 시간과 해당 기간(RPO) 중 데이터 손실 또는 백업되지 않은 시간으로 ITSC 성능을 평가합니다.[11][12]

실제 복구 시간

Forbes의[9] 개요에 따르면 실제 복구 시간(RTA)은 비즈니스 연속성과 재해 복구의 중요한 지표입니다.

비즈니스 연속성 그룹은 일정된 리허설([9][13]또는 실제 리허설)을 실시합니다.이 기간 동안 RTA는 필요에 따라 결정 및 개선됩니다.

복구 시점 목표

복구 시점 목표(RPO)는 대규모 사고로 [11]인해 트랜잭션 데이터가 IT 서비스에서 손실되는 최대 목표 기간입니다.

예를 들어, RPO가 분 단위(또는 몇 시간 단위)로 측정되는 경우, 테이프 상의 매일 오프사이트 백업으로는 [14]충분하지 않기 때문에 실제로 오프사이트 미러 백업을 지속적으로 유지해야 합니다.

복구 시간 목표와의 관계

즉각적인 복구가 아닌 복구는 트랜잭션 데이터를 일정 기간 동안 복원하고 큰 위험이나 [11]손실을 초래하지 않습니다.

RPO는 중대한 사고 발생 시 최근 데이터가 영구적으로 손실될 수 있는 최대 시간을 측정하며 이러한 손실의 양을 직접 측정하지는 않습니다.예를 들어 BC가 사용 가능한 마지막 백업까지 복원할 계획인 경우 RPO는 오프사이트에 안전하게 보관된 백업 간의 최대 간격입니다.

기존 백업 체제에서 RPO를 결정하는 것으로 오해되는 경우가 많지만, 실제로는 비즈니스 영향 분석에 따라 각 서비스의 RPO가 결정됩니다.오프사이트 데이터가 필요한 경우 백업이 오프사이트가 [12]아닌 백업이 준비될 때 데이터가 손실될 수 있는 기간이 시작되는 경우가 많습니다.

데이터 동기화 포인트

데이터 동기화[15] 지점은 실제 데이터가 백업되는 시점입니다.이는 D2D 복사가 이루어지는 동안 업데이트큐의 처리를 정지하기 위해 사용되는 접근법 중 하나입니다.백업 복사본에는 이전[16] 버전의 복사 작업이 반영됩니다. 데이터가 테이프에 복사되거나 다른 곳으로 전송될 때는 반영되지 않습니다.

RTO 및 RPO 값이 컴퓨터 시스템 설계에 미치는 영향

RTO와 RPO는 다른 모든 주요 시스템 설계 [17]기준과 함께 비즈니스 리스크를 고려하여 균형을 이루어야 합니다.

RPO는 백업이 오프사이트로 전송되는 시간과 관련이 있습니다.오프사이트 미러에 동기식 복사를 개입시켜 오프사이트로 이동하면, 대부분의 예기치 않은 문제가 발생합니다.테이프(또는 기타 운반 가능한 미디어)에 물리적인 수송 수단을 사용하면 비교적 저렴한 비용으로 백업 요구를 충분히 충족할 수 있습니다.복구는 미리 정해진 사이트에서 실행할 수 있습니다.공유 오프사이트 공간과 하드웨어로 필요한 [18]패키지가 완성됩니다.

대량의 고부가가치 트랜잭션 데이터의 경우 지리적 영역에 걸쳐 하드웨어를 분할하여 두 개 이상의 사이트로 분할할 수 있으므로 복원력이 향상됩니다.

역사

1970년대 중후반, 컴퓨터 센터 관리자가 조직의 컴퓨터 시스템에 대한 의존도를 인식하기 시작하면서 재해 복구 및 정보기술(IT) 계획이 개발되었습니다.

당시 대부분의 시스템은 배치 지향 메인프레임이었습니다.프라이머리 사이트의 복구가 보류되어 있는 백업 테이프에서 다른 오프사이트 메인프레임을 로드할 수 있었습니다.다운타임이 상대적으로 덜 중요했습니다.

재해 복구[19][20] 산업은 백업 컴퓨터 센터를 제공하기 위해 발전했습니다.그러한 센터 중 가장 초기의 것 중 하나는 스리랑카에 있었다(Sungard Availability Services, 1978).[21][22]

1980년대와 90년대에는 사내 시분할, 온라인 데이터 입력 및 실시간 처리가 증가함에 따라 IT 시스템의 가용성이 향상되었습니다.

규제 기관은 2000년대 인터넷의 급속한 성장 이전에도 관여했다. 2, 3, 4, 또는 5.999%의 목표가 종종 요구되었고 핫 사이트 설비를 위한 고가용성 솔루션이 모색되었다.[citation needed]

IT서비스 연속성은 비즈니스 연속성 관리(BCM)와 정보보안 관리(ICM)의 실장, 및 ISO/IEC 27001과 ISO 22301에 규정되어 있는 비즈니스 연속성 관리의 일환으로서 많은 조직에 있어서 불가결합니다.

2010년 이후 클라우드 컴퓨팅의 부상은 이러한 경향을 계속하고 있습니다.요즘에는 네트워크 자체가 충분히 신뢰성이 있는 한(별도의 문제이며 최신 네트워크는 설계상 복원력이 높기 때문에) 컴퓨팅 서비스가 물리적으로 제공되는 장소가 더 이상 중요하지 않습니다.RaaS(Recovery as a Service)는 Cloud Security [23]Alliance가 추진하고 있는 클라우드 컴퓨팅의 보안 기능 또는 이점 중 하나입니다.

재해의 분류

재해는 세 가지 광범위한 위협과 위험의 결과로 나타날 수 있습니다.첫 번째 범주는 홍수, 허리케인, 토네이도, 지진 및 전염병과 같은 자연재해이다.두 번째 범주는 파이프라인 폭발, 운송 사고, 전력 공급 중단, 댐 붕괴 및 우발적 위험 물질 방출과 같은 시스템 및 구조물의 고장 또는 고장을 포함하는 기술적 위험이다.세 번째 범주는 능동적 공격, 화학 또는 생물학적 공격, 데이터 또는 인프라에 대한 사이버 공격 및 파괴 행위와 같은 의도적인 행위를 포함하는 인간에 의한 위협입니다.모든 종류의 재해에 대한 대비책은 예방, 보호, 경감, 대응, [24]복구의 5가지 임무 영역으로 분류된다.

재해 복구 계획의 중요성

최근의 연구는 보다 전체적인 사전 재해 계획 접근 방식을 구현하는 것이 장기적으로 더 비용 효율적이라는 생각을 뒷받침합니다.재해 복구 계획 등의 위험 완화에 1달러를 지출할 때마다 사회 대응 [25]및 복구 비용이 4달러 절감됩니다.

2015년 재해 복구 통계에 따르면 다운타임은 1시간 동안 지속될 수 있습니다.

  • 8,000달러에 달하는 소규모 기업들,
  • 중견기업은 74,000달러,
  • 70만달러의 [26]대규모 기업

IT시스템이 기업 전체의 원활한 운영에 점점 더 중요해지고 있는 가운데, 이러한 시스템의 계속적인 운용과 신속한 회복의 중요성은 더욱 높아지고 있습니다.예를 들어, 비즈니스 데이터가 크게 손실된 기업 중 43%는 다시 열지 않고 29%는 2년 [citation needed]이내에 문을 닫았습니다.따라서 시스템의 계속 또는 복구를 위한 준비는 매우 신중하게 이루어져야 합니다.여기에는 운영 중단 [27]시 손실을 최소화할 목적으로 시간과 비용이 많이 투자됩니다.

관리책

제어 조치는 조직의 다양한 위협을 줄이거나 제거할 수 있는 단계 또는 메커니즘입니다.Disaster recovery plan(DRP)에는 다양한 유형의 대책을 포함할 수 있습니다.

disaster recovery planning은 비즈니스 연속성 플래닝이라고 불리는 대규모 프로세스의 서브셋으로 애플리케이션, 데이터, 하드웨어, 전자통신(네트워킹 등) 및 기타 IT인프라스트럭처의 [28]재개 계획을 포함합니다.BCP(Business Continuity Plan)에는 주요 인력, 시설, 위기 커뮤니케이션, 평판 보호 등 IT와 관련되지 않은 측면에 대한 계획이 포함됩니다.IT 관련 인프라스트럭처의 복구/계속성에 대해서는 Disaster recovery Plan(DRP)을 참조해야 합니다.

IT 디저스터 리커버리 제어 대책은 다음의 3가지 타입으로 분류할 수 있습니다.

  1. 예방책 – 이벤트 발생을 방지하기 위한 제어입니다.
  2. 탐정 조치 – 원하지 않는 이벤트를 탐지하거나 발견하는 것을 목적으로 하는 제어입니다.
  3. 시정조치 – 장애 또는 이벤트 발생 후 시스템 수정 또는 복원을 목적으로 하는 제어입니다.

적절한 disaster recovery 계획 대책에서는 이들 3종류의 제어가 문서화되어 이른바 DR 테스트에 의해 정기적으로 실행되도록 규정되어 있습니다.

전략들

디저스터 리커버리 전략을 선택하기 전에 disaster recovery 플래너는 먼저 조직의 비즈니스 연속성 계획을 참조합니다.이 계획은 리커버리 포인트 목표와 리커버리 시간 [29]목표의 주요 메트릭을 제시해야 합니다.그런 다음 비즈니스 프로세스의 메트릭이 시스템 및 [30]인프라에 매핑됩니다.

적절한 계획을 세우지 않으면 재해의 [31]영향이 확대될 수 있습니다.메트릭이 매핑되면 조직은 IT 예산을 검토합니다.RTO 및 RPO 메트릭은 사용 가능한 예산에 적합해야 합니다.비용 편익 분석에 따라 구현되는 재해 복구 조치가 결정되는 경우가 많습니다.

NYT는 로컬 및 오프사이트 테이프 아카이브의 이점에 클라우드 기반 백업을 추가하여 "데이터 [32]보호 레이어를 추가"했습니다.

데이터 보호를 위한 일반적인 전략은 다음과 같습니다.

  • 테이프에 백업하여 정기적으로 오프사이트로 전송
  • 온사이트 Disk에 백업하고 오프사이트 Disk에 자동으로 복사하거나 오프사이트 Disk에 직접 백업합니다.
  • 오프사이트 로케이션으로의 데이터 리플리케이션으로 많은 경우 SAN(Storage Area Network) 테크놀로지를 사용하여 데이터를 restore(시스템만 restore 또는 동기화할 필요가 있음)할 필요성을 극복합니다.
  • 관리 데이터(VM, 템플릿 및 디스크)를 프라이빗 클라우드 설정의 일부인 스토리지 도메인에 복제하는 프라이빗 클라우드 솔루션.이러한 관리 데이터는 OVF(Open Virtualization Format)라는 XML 표현으로 구성되며 재해가 발생하면 복원할 수 있습니다.
  • 온사이트 데이터센터와 오프사이트 데이터센터 모두를 복제하는 하이브리드 클라우드 솔루션.이러한 솔루션을 통해 로컬 온사이트 하드웨어에 즉시 페일오버할 수 있습니다.그러나 물리적인 장애가 발생했을 경우 클라우드 데이터 센터에서도 서버를 가동할 수 있습니다.
  • 데이터와 시스템을 모두 오프사이트로 복제하여 재해 발생 후에도 시스템과 데이터에 지속적으로 액세스할 수 있도록 하는 고가용성 시스템 사용(흔히 클라우드 [33]스토리지와 관련됨)

많은 경우 조직은 클라우드 컴퓨팅을 통해 자체 리모트 설비를 사용하는 대신 외부 위탁 디저스터 리커버리 프로바이더를 사용하여 스탠바이 사이트와 시스템을 제공할 수 있습니다.

조직은 시스템 복구의 필요성에 대한 준비와 더불어 재해 예방을 목적으로 예방 조치도 실시합니다.여기에는 다음이 포함됩니다.

  • 시스템 및/또는 데이터의 로컬 미러 및 RAID 등의 디스크 보호 테크놀로지 사용
  • 서지 프로텍터 - 섬세한 전자기기에 대한 전력 서지의 영향을 최소화합니다.
  • 무정전 전원장치(UPS) 및/또는 백업 발전기를 사용하여 정전 발생 시에도 시스템 가동 유지
  • 경보 및 소화기와 같은 화재 예방/감소 시스템
  • 바이러스 대책 소프트웨어 및 기타 보안 대책

서비스로서의 디저스터 리커버리

주요 기사:서비스로서의 리커버리

DRaaS(Disaster recovery as a Service)는 서드파티 [34]벤더와의 계약입니다.일반적으로 서비스 프로바이더가 서비스 포트폴리오의 일부로 제공합니다.

벤더 리스트는 공개되어 있습니다만, Disaster recovery는 제품이 아니라 서비스입니다.단시간에 [35][original research?]설치 및 운용할 수 있는 모바일/모듈러 제품을 개발한 대규모 하드웨어 벤더도 있습니다.

변전소의 전력망에 접속하는 모듈러형 데이터센터

「 」를 참조해 주세요.

레퍼런스

  1. ^ 시스템 및 운영 연속성: 디저스터 리커버리조지타운 대학교.대학 정보 서비스2012년 8월 3일 취득.
  2. ^ Disaster recovery and Business Continuity, 버전 2011.2013년 1월 11일 IBM Wayback Machine에서 보관.2012년 8월 3일 취득.
  3. ^ [1] '비즈니스 연속성 관리란 무엇인가', DRI International, 2017
  4. ^ M. Niemimaa; Steven Buchanan (March 2017). "Information systems continuity process". ACM.com (ACM Digital Library).
  5. ^ "2017 IT Service Continuity Directory" (PDF). Disaster Recovery Journal.
  6. ^ "Defending The Data Strata". ForbesMiddleEast.com. December 24, 2013.
  7. ^ "ISO 22301 to be published Mid May - BS 25999-2 to be withdrawn". Business Continuity Forum. 2012-05-03. Retrieved 2021-11-20.
  8. ^ "ITIL glossary and abbreviations".
  9. ^ a b c "Like The NFL Draft, Is The Clock The Enemy Of Your Recovery Time". Forbes. April 30, 2015.
  10. ^ "Three Reasons You Can't Meet Your Disaster Recovery Time". Forbes. October 10, 2013.
  11. ^ a b c d "Understanding RPO and RTO". DRUVA. 2008. Retrieved February 13, 2013.
  12. ^ a b "How to fit RPO and RTO into your backup and recovery plans". SearchStorage. Retrieved 2019-05-20.
  13. ^ "시계...변경 사항
  14. ^ Richard May. "Finding RPO and RTO". Archived from the original on 2016-03-03.
  15. ^ "Data transfer and synchronization between mobile systems". May 14, 2013.
  16. ^ "Amendment #5 to S-1". SEC.gov. real-time ... provide redundancy and back-up to ...
  17. ^ Peter H. Gregory (2011-03-03). "Setting the Maximum Tolerable Downtime -- setting recovery objectives". IT Disaster Recovery Planning For Dummies. Wiley. pp. 19–22. ISBN 978-1118050637.
  18. ^ William Caelli; Denis Longley (1989). Information Security for Managers. p. 177. ISBN 1349101370.
  19. ^ "Catastrophe? It Can't Possibly Happen Here". The New York Times. January 29, 1995. .. patient records
  20. ^ "Commercial Property/Disaster Recovery". NYTimes.com. October 9, 1994. ...the disaster-recovery industry has grown to
  21. ^ Charlie Taylor (June 30, 2015). "US tech firm Sungard announces 50 jobs for Dublin". The Irish Times. Sungard .. founded 1978
  22. ^ Cassandra Mascarenhas (November 12, 2010). "SunGard to be a vital presence in the banking industry". Wijeya Newspapers Ltd. SunGard ... Sri Lanka's future.
  23. ^ SecaaS 카테고리 9 // BCDR 구현 지침 CSA, 2014년 7월 14일 취득.
  24. ^ "Threat and Hazard Identification and Risk Assessment (THIRA) and Stakeholder Preparedness Review (SPR): Guide Comprehensive Preparedness Guide (CPG) 201, 3rd Edition" (PDF). US Department of Homeland Security. May 2018.
  25. ^ "Post-Disaster Recovery Planning Forum: How-To Guide, Prepared by Partnership for Disaster Resilience". University of Oregon's Community Service Center, (C) 2007, www.OregonShowcase.org. Retrieved October 29, 2018.
  26. ^ "The Importance of Disaster Recovery". Retrieved October 29, 2018.
  27. ^ "IT Disaster Recovery Plan". FEMA. 25 October 2012. Retrieved 11 May 2013.
  28. ^ "Cloud Disaster Recovery: well-prepared for worst case scenario". IONOS Digitalguide. Retrieved 2022-06-23.
  29. ^ "Use of the Professional Practices framework to develop,implement,maintain a business continuity program can reduce the likelihood of significant gaps". DRI International. 2021-08-16. Retrieved 2021-09-02.
  30. ^ 그레고리, 피터CISA Certified Information Systems Auditor 올인원 시험 가이드, 2009.ISBN 978-0-07-148755-9.480쪽.
  31. ^ "Five Mistakes That Can Kill a Disaster Recovery Plan". Dell.com. Archived from the original on 2013-01-16. Retrieved 2012-06-22.
  32. ^ J. D. Biersdorfer (April 5, 2018). "Monitoring the Health of a Backup Drive". The New York Times.
  33. ^ Brandon, John (23 June 2011). "How to Use the Cloud as a Disaster Recovery Strategy". Inc. Retrieved 11 May 2013.
  34. ^ "Disaster Recovery as a Service (DRaaS)".
  35. ^ "Cloud backup and recovery".
  36. ^ "Info and video about Cisco's solution". Datacentreknowledge. May 15, 2007. Archived from the original on 2008-05-19. Retrieved 2008-05-11.
  37. ^ Kraemer, Brian (June 11, 2008). "IBM's Project Big Green Takes Second Step". ChannelWeb. Archived from the original on 2008-06-11. Retrieved 2008-05-11.
  38. ^ "Modular/Container Data Centers Procurement Guide: Optimizing for Energy Efficiency and Quick Deployment" (PDF). Archived from the original (PDF) on 2013-05-31. Retrieved 2013-08-30.
  39. ^ Kidger, Daniel. "Mobull Plug and Boot Datacenter". Bull. Archived from the original on 2010-11-19. Retrieved 2011-05-24.
  40. ^ "HP Performance Optimized Datacenter (POD) 20c and 40c - Product Overview". H18004.www1.hp.com. Archived from the original on 2015-01-22. Retrieved 2013-08-30.
  41. ^ "Huawei's Container Data Center Solution". Huawei. Retrieved 2014-05-17.
  42. ^ "Technical specs of Sun's Blackbox". Archived from the original on 2008-05-13. Retrieved 2008-05-11.

추가 정보

외부 링크