롤백 기능이있는 중복 스토리지 시스템이있는 경우에도 백업이 필요합니까?

우리 조직은 최근 스토리지 시스템을 구입했습니다. RAID6과 함께 1.5Petabyte를 가지며 물리적으로 다른 위치에 온라인 동기화 미러가 있습니다.

시스템은 기본적으로 최대 30 일까지 롤백 / 파일 복구를 허용하지만이를 늘릴 수 있습니다.

스토리지에만있는 데이터에 대한 추가 백업이 필요한 경우 논의가 진행됩니다.

이 시스템은 중복성이 매우 우수하고 지리적 중복성이 있으며 어느 정도 롤백이 가능하여 정의 된 시간 (기본적으로 30 일)의 오래된 데이터 또는 실수로 삭제 된 데이터를 복구 할 수 있습니다.

이 시나리오에서 여전히 "전통적인"백업을하는 것이 합리적입니까? 전통적으로, 나는 문제가 생겼을 때 복구 할 수있는 스냅 샷이있는 전용 백업 시스템을 의미합니다.

우리는 정말로 그것을 필요로 하는가? 뭔가 빠졌습니까? 나는 단지 전통적인 방식으로 생각하고 열심 인 것입니까?

설명은 지리적으로 분산 된 RAID의 필수 요소이며 RAID 는 결코 백업이 아니 었습니다 .

온라인 동기화는 일반적으로 공격자에 의한 (모든) 스냅 샷 및 / 또는 볼륨 삭제 또는 단순히 관리자 오류와 같은 작업을 포함하여 기본 스토리지에서 수행하는 모든 작업이 백업 시스템에 즉시 복제됨을 의미합니다.

30 일 롤백은 훌륭한 기능이지만 "필수적으로 중요한 파일 xyz"가 손상 / 손상되어 31 일 이상 후에 감지되지 않으면 어떻게됩니까? 이 상황은 백업 스케줄과 아카이브 스케줄의 차이점이지만 설명에서는 후자에 대해서는 언급하지 않았습니다. 보관 시스템은 일반적으로 매우 저렴한 테이프에 저장됩니다. 또한 비즈니스가 30 일 이상 데이터를 보존해야하는 규제 또는 기타 요구 사항이있는 비즈니스인지 여부에 대한 정보는 없습니다.

이것이 당신의 상황에 해당되지 않는다면, 당신은 좋을 것입니다.

데이터가있는 지리적으로 분리 된 시스템을 갖는 것이 좋습니다.

두 사이트 또는 모든 사이트와 관련하여 여러 번 실패하면 어떻게됩니까? 하나의 화재, 다른 서버의 도난? 또는 그들 사이의 회선에 문제가있는 경우 기본 위치의 서버가 꺼지고 HD 컨트롤러가 원숭이를 보내며 정크를 씁니까? 아니면 일부 내부자는 두 가지 모두에 악의적 인 행동을합니까? 또는 FBI는 의심으로 인해 두 위치에서 서버를 압수합니다 (아마도, 그러나 schmucks와 함께 데이터 센터에 공동 호스트되어있을 수도 있습니다). 또는 .. 모든 것이 중복되어 n도 수준으로 분석 된 여러 개의 "클라우드"중단이 생각 나지만 여전히 문제가 발생할 수 있습니다. 나는 당신에게 이것들이 모두 가능하지 않다는 것을 허락 할 것입니다, 그러나 당신은 거의 일어날 수없는 일이 있다는 것을 인정했습니다.

그렇다면 그 데이터가 얼마나 중요하고 귀중한가에 달려 있습니다. 조직이 사라지면 어떻게합니까?

여기서 문제는 고 가용성 / 중복 인프라가 아닌 백업 전에 복제 된 데이터 사본의 연결이 끊어지고 지리적으로 뚜렷이 구분되는 것입니다. 내 직감은 당신이 가까이 있지만 여전히 백업이 필요하다는 것입니다.

다른 답변과 의견에 몇 가지 생각을 모으기 위해 (체리 피킹) "잘, X 기술은 Y 재해 시나리오를 다루지 않으므로 백업이 아닙니다." 당신은 당신에게 합리적인 것을 결정해야하며, 이것이 당신이 묻는 이유 인 것 같습니다. 이것에 대한 나의 느낌과 많은 의견가들의 생각은 백업이 사용중인 데이터와 별도의 기술 인프라에 존재해야 실패, 사고 및 악의적 인 행동이 전파되거나 전파 될 수 없다는 것입니다 훨씬 더 높은 장애물입니다. 의견에 주어진 예는 볼륨을 삭제하는 사람입니다. 이는 필자가 생각하기에 하늘이 아닌 시나리오입니다. 그러나 또한 내 작품의 실제 예입니다. 내가 일하는 대학교 t)이 인프라를 관리하려면) 많은 캠퍼스 시설을 지원하는 심각한 고 가용성 가상화 인프라가 있습니다. 여러 사이트에 있지만 모두 하나의 공급 업체 플랫폼에서 실행되고 있습니다. 언젠가 모호한 버그가 발생하여 단일 서버를 먼저 중단시키는 장애 캐스케이드가 발생했으며,로드가 이동하면 나머지 사이트가 제거되고,로드가 다시 이동하면 다른 사이트 호스팅이 제거되었습니다. 그 인프라. (그 이후로이 문제가 해결되었다고 생각합니다). 이 경우에는 데이터가 손실되지 않았지만 데이터가 있던 시나리오가 상상 가능합니다. 언젠가 모호한 버그가 발생하여 단일 서버를 먼저 중단시키는 장애 캐스케이드가 발생했으며,로드가 이동하면 나머지 사이트가 제거되고,로드가 다시 이동하면 다른 사이트 호스팅이 제거되었습니다. 그 인프라. (그 이후로이 문제가 해결되었다고 생각합니다). 이 경우에는 데이터가 손실되지 않았지만 데이터가 있던 시나리오가 상상 가능합니다. 언젠가 모호한 버그가 발생하여 단일 서버를 먼저 중단시키는 장애 캐스케이드가 발생했으며,로드가 이동하면 나머지 사이트가 제거되고,로드가 다시 이동하면 다른 사이트 호스팅이 제거되었습니다. 그 인프라. (그 이후로이 문제가 해결되었다고 생각합니다). 이 경우에는 데이터가 손실되지 않았지만 데이터가 있던 시나리오가 상상 가능합니다.

백업이이 모든 것에 영향을받지 않고 인프라가 다운 된 상태에서도 액세스 할 수 있기를 원합니다. RAID가 재 구축되는 동안 일주일 동안 데이터를 사용할 수없는 경우 백업에서 업무상 중요한 문서를 복구 할 수있는 것이 좋습니다 (필수는 아님). RAID가 사라지면 다른 사이트로 복제하는 경우 별도의 공급 업체 또는 테이프와 같은 격리 된 미디어에서 백업을 수행하는 것이 좋습니다.

이 모든 것이 말했듯이 백업은 데이터와 별도의 인프라에 있어야한다는 것을 다시 반복하겠습니다. 여기에는 많은 수준의 격리가 있지만 직접 복제를 통해 연결된 것은 백업에 너무 가깝다고 생각합니다. 당신은 또한 무언가를 원할 것입니다.

가정 : 스토리지 시스템은 많은 응용 프로그램에서 사용됩니다.

별도의 백업 시스템을 사용하면 훨씬 더 잘할 수 있다고 생각합니다.

RAID 및 미러링은 백업이 아니지만 내장 롤백 기능이 기존 백업 시스템을 대체 할 수 있습니다.

그러나:

다음과 같은 이유로 복구 정책이 스토리지 기반이 아닌 애플리케이션 / 데이터 기반 인 것을 선호합니다.

1. 응용 프로그램은 복구 및 허용 가능한 데이터 손실과 관련된 요구 사항이 다릅니다 (일부 읽기 전용 매체, 암호화, 지난 X 년 유지 등의 다양한 규정에 의해 부과됨)
2. 일부 응용 프로그램에는 (아주) 훌륭한 백업 및 복구 도구 (oracle, mssql)가 내장되어 있으며 백업 / 복구 부분을 수행하는 방법을 권장합니다 (Oracle DBA로서 Oracle을 선호하며 rman을 사용하여 Oracle과 관련된 모든 백업을 수행합니다).
3. 증가, 공간 사용이 훨씬 빠르게 증가 할 수 있습니다. 이제이 시스템은 30 일의 롤백 데이터를 수용 할 수 있습니다. 이는 향후 보장되지 않습니다.
4. 저렴하고 몇 년의 성장 후에 백업 / 복구 정책을 수용하기 위해 더 큰 테이프를 사용하는 비용은 현재와 동일한 롤백 창을 유지하기 위해 새롭고 더 큰 디스크를 구입하는 비용보다 작습니다