데이터 백업 및 재해 복구에는 파일 손상, 데이터 손상, 사이버 공격 또는 자연 재해로 인해 데이터가 손실되는 경우 정기적으로 하나 이상의 파일 사본을 생성 또는 업데이트하여 하나 이상의 원격 위치에 저장하고 이 사본을 사용하여 비즈니스 운영을 계속하거나 재개하는 작업이 포함됩니다.
하위 프로세스 '백업'과 '재해 복구'는 때때로 전체 프로세스로 오인되는 경우가 있습니다. 그러나 백업은 파일 복제본을 만드는 프로세스이고, 재해 복구는 운영 중단 후 복제본을 사용하여 애플리케이션, 데이터, IT 리소스에 신속하게 접근할 수 있게 해주는 계획 및 프로세스입니다. 이 계획에는 기본 데이터 센터가 다시 작동할 때까지 중복된 서버 및 스토리지 시스템으로 전환하는 것이 포함될 수 있습니다.
단순히 데이터 사본이 있다고 해서 기업이 비즈니스를 계속 운영할 수 있는 것은 아닙니다. 비즈니스 연속성을 보장하려면 견고하고 검증된 백업 및 재해 복구 계획이 필요합니다.
조직은 백업이나 재해 복구를 소홀히 해서는 안 됩니다. 실수로 데이터를 삭제한 후 손실된 데이터를 검색하는 데 몇 시간이 걸리면 직원이나 파트너가 가만히 있어 기술을 사용하는 비즈니스 크리티컬 프로세스를 완료할 수 없게 됩니다. 재해가 발생한 후 비즈니스를 온라인 상태로 복구하는 데 며칠이 걸리면 고객을 영구적으로 잃을 수 있습니다. 두 경우 모두 손실될 수 있는 시간과 비용을 고려할 때 백업 및 재해 복구에 대한 투자는 충분히 정당화될 수 있습니다.
몇 가지 필수 용어를 이해하면 전략적 결정을 내리고 백업 및 재해 복구 솔루션을 더 잘 평가하는 데 도움이 될 수 있습니다.
마지막으로 재해 복구 프로세스 및 재해 복구 환경을 관리하기 위한 대안을 고려할 때 다음과 같은 조언이 도움이 될 수 있습니다.
주요 개념을 이해했다면 이제 이를 워크로드에 적용할 차례입니다. 많은 조직에는 비즈니스에 대한 각 워크로드의 중요성을 반영하는 여러 RTO 및 RPO가 있습니다.
주요 은행의 경우 온라인 뱅킹 시스템이 중요한 워크로드일 수 있으며, 은행은 시간과 데이터 손실을 최소화해야 합니다. 하지만 은행의 직원 근무 시간 추적 애플리케이션은 그다지 중요하지 않습니다. 재해가 발생하면 은행은 비즈니스에 큰 부정적인 영향을 미치지 않고 몇 시간 또는 하루 동안 애플리케이션이 다운되도록 허용할 수 있습니다. 워크로드를 계층 1, 계층 2 또는 계층 3으로 정의하면 재해 복구 계획을 위한 프레임워크를 제공하는 데 도움이 될 수 있습니다.
재해 복구 계획을 설계하는 다음 단계는 배포 옵션을 평가하는 것입니다. 일부 재해 복구 기능이나 백업 데이터를 온프레미스에 보관해야 하나요? 퍼블릭 클라우드나 하이브리드 클라우드 방식 중 어떤 것이 더 좋을까요?
클라우드 기반 백업 및 재해 복구 솔루션은 모든 규모의 조직에서 점점 더 인기를 얻고 있습니다. 많은 클라우드 솔루션은 데이터 저장을 위한 인프라를 제공하며, 경우에 따라 백업 및 재해 복구 프로세스를 관리하기 위한 도구도 제공합니다.
클라우드 기반 백업이나 재해 복구 서비스를 선택하면 인프라에 대한 대규모 자본 투자와 환경 관리 비용을 피할 수 있습니다. 또한 지역 재해 발생 시 데이터를 안전하게 보호하는 데 필요한 지리적 거리와 빠른 확장성을 확보할 수 있습니다.
클라우드 기반 백업 및 재해 복구 솔루션은 온프레미스와 클라우드 기반 프로덕션 환경을 모두 지원할 수 있습니다. 예를 들어, 프로덕션 환경은 자체 데이터 센터에 유지하면서 백업 또는 복제된 데이터만 클라우드에 저장하기로 결정할 수 있습니다.
이 하이브리드 접근 방식을 사용하면 프로덕션 환경을 옮기지 않고도 확장성과 지리적 거리의 이점을 누릴 수 있습니다. 클라우드 대 클라우드 모델에서는 프로덕션과 재해 복구가 모두 클라우드에 위치하지만, 물리적으로 충분히 분리되도록 서로 다른 사이트에 있습니다.
경우에 따라 특정 백업 또는 재해 복구 프로세스를 온프레미스로 유지하면 데이터를 검색하고 IT 서비스를 신속하게 복구하는 데 도움이 될 수 있습니다. 일부 민감한 데이터를 온프레미스에 유지하는 것은 엄격한 데이터 개인 정보 보호 또는 데이터 주권 규정을 준수해야 하는 경우에도 매력적으로 보일 수 있습니다.
재해 복구를 위한 경우 온프레미스 환경에 전적으로 의존하는 계획은 어려울 수 있습니다. 자연재해나 정전이 발생하면 기본 시스템과 보조 시스템을 모두 포함한 전체 데이터 센터가 영향을 받게 됩니다. 그렇기 때문에 대부분의 재해 복구 전략은 기본 데이터 센터에서 어느 정도 떨어진 보조 사이트를 사용합니다.
성능, 규정 준수 및 보조 사이트에 대한 물리적 접근성과 같은 요소의 균형을 어떻게 조정하느냐에 따라 다른 사이트를 도시 전역, 국가 또는 전 세계에 배치할 수 있습니다.
선택하는 배포 옵션에 따라 재해 복구와 백업에 사용하는 기술 및 프로세스 유형에 대한 여러 가지 대안이 있을 수 있습니다.
수십 년 동안 사용되어 왔음에도 불구하고 기존의 자기 테이프 스토리지는 여전히 백업 계획에서 중요한 역할을 할 수 있습니다. 테이프 솔루션을 사용하면 많은 양의 데이터를 안정적이고 비용 효율적으로 저장할 수 있습니다.
테이프는 백업에는 효과적일 수 있지만, 디스크 기반 스토리지의 빠른 액세스 시간을 필요로 하는 재해 복구에는 일반적으로 사용되지 않습니다. 또한 오프사이트 볼트에서 테이프를 물리적으로 가져와야 하는 경우, 몇 시간 또는 며칠 동안 가용성을 잃을 수도 있습니다.
스냅샷 기반 백업은 특정 시점의 애플리케이션 또는 디스크의 현재 상태를 캡처합니다. 이 방법은 마지막 스냅샷 이후 변경된 데이터만 기록함으로써 스토리지 공간을 절약하면서 데이터를 보호하는 데 도움이 될 수 있습니다.
스냅샷 기반 복제는 백업 또는 재해 복구에 사용할 수 있습니다. 데이터는 가장 최근의 스냅샷만큼만 완전합니다. 매시간 스냅샷을 찍는다면 한 시간 분량의 데이터를 잃을 각오가 되어 있어야 합니다.
많은 조직이 백업뿐만 아니라 재해 복구를 위해 지속적 복제로 전환하고 있습니다. 이 방법을 사용하면 디스크 또는 애플리케이션의 최신 사본이 다른 위치 또는 클라우드에 지속적으로 복제되어 가동 중지 시간을 최소화하고 보다 세분화된 복구 지점을 제공할 수 있습니다.
IBM Storage DS8000는 IBM zSystems 및 IBM Power 서버를 위한 가장 빠르고, 안정적이며, 안전한 스토리지 시스템입니다.
IBM Storage는 데이터 스토리지 하드웨어, 소프트웨어 정의 스토리지, 그리고 스토리지 관리 소프트웨어로 구성된 제품군입니다.
IBM은 웹 서버 및 데이터 센터 인프라를 위한 선제적 지원을 제공하여 다운타임을 줄이고 IT 가용성을 개선합니다.