페타 바이트 단위의 데이터를 백업하고 저장하는 좋은 방법이 있습니까?

SQL Server 설치에서 수백 테라 바이트의 데이터를 가진 클라이언트를보기 시작했습니다. 일부 기업의 총 데이터 양이 페타 바이트의 의미있는 부분에 접근함에 따라, 대량의 데이터를 다루는 사람들이 데이터를 보호하기 위해 무엇을하고 있는지 파악하기 위해 집단 지식 기반을 조사하고 싶습니다.

명백한 문제는 엔터프라이즈 급 스토리지를 사용하여 RAID-5까지도 많은 데이터의 여러 백업을 저장하는 것이 엄청나게 비싸다는 것입니다.

내가 보는 옵션은 다음과 같습니다.

1. 다른 데이터 센터에서 데이터의 미러 사본을 작성하고 데이터 소스에 사용 가능한 메커니즘 (예 : 로그 전달 또는 SQL Server의 데이터베이스 미러링)을 사용하여 차이점을 지속적으로 제공하십시오.
2. 강력한 압축 알고리즘을 사용하여 정기적으로 백업하십시오 (데이터가 강력하게 압축 되는 경우에만 적합합니다 )
3. 중요한 / 변경되는 데이터 부분을 부분 백업합니다.
4. 데이터를 백업하지 말고 부패한 신들을 신뢰하십시오.

옵션 # 4가 기본값으로 채택되고 있으며 HA / DR 전문가에게는 이것이 무섭지 만 대안으로 무엇을 조언해야합니까? # 1이 최선의 방법이라고 생각하지만 # 4와 # 3 이외의 대안이 제안 될 때 "그렇지 않다"는 것이 일반적인 대답입니다.

물론 데이터의 변화 속도와 중요도에 달려 있습니다. Microsoft에서 일하는 동안 SQL Server의 모든 HA 기능을 담당 했었기 때문에 대답 할 필요가 없으므로 '종속적'인수에 정통합니다.

나는 내가 놓친 대안에 대해 듣고 싶거나 다른 사람들이 모두 같은 배에 있고 더 많은 저장 공간에 많은 돈을 쓰는 것에 대한 현실적인 대안이 없다는 것에 매우 관심이 있습니다.

미리 감사드립니다-모든 잘 생각하고 표현 된 답변에 적법한 학점이 부여됩니다.

벽에서 벗어난 아이디어-저장된 모든 정보가 필요하거나 유용합니까?

정보의 가치는 얼마입니까? 데이터 가치보다 유지 관리에 더 많은 비용을 지출하는 것은 분명히 우스운 것 같습니다.

데이터베이스의 데이터가 데이터베이스의 스토리지에 적합합니까? 예를 들어 지원되는 조직의 데이터베이스에 압축 된 기가 바이트 코어 파일을 유지하면 실제로 어떤 이점이 있습니까?

데이터베이스에 중복 된 데이터가 많이 있습니까? 예를 들어, 천명의 사람들이 매주 10MB 뉴스 레터마다 10 개의 사본을 보관하고 있습니까?

일부 데이터에 "만료 날짜"가 있고 그 이후에는 값이 제공되지 않습니까? 지원 조직 예제로 돌아가서 여러 가지 이유로 수정 사항이 제공된 후 몇 개월 이상 고객 핵심 파일을 유지하는 데 실질적인 이점이 없습니다.

또 다른 생각은 많은 양의 데이터가 회사를 부채로 여는 것입니다. 법률에 따라 일부 데이터는 보관해야합니다. 그러나 일부 데이터는 실수로 또는 악의적으로 부적절한 당사자에게 공개 될 경우 발생할 수있는 위험 때문에 "파쇄"되어야합니다.

예, 또 다른 옵션은 스토리지 가상화입니다. IBM SVC와 같이 서버와 SAN 사이에있는 장치입니다. SVC는 SAN에서 SAN으로의 복사본을 관리하고 원격 복제를 수행 할 수 있습니다 (데이터 변경 률이 낮고 대역폭이 높지 않으면 페타 바이트 수준에서는 상당히 고통 스럽습니다).

매끄러운 부분은 전체 프로세스가 관련된 서버에서 볼 수 없다는 것입니다. SQL Server를 사용하는 경우 변경 률이 낮은 항목 (예 : 3 년 전의 판매 아카이브)과 변경 률이 높은 항목 (현재 판매와 같은)을 별도의 파일 그룹에 유지하도록 파일 그룹을 설계합니다. 완전히 읽기 전용 일 필요는 없습니다. 각 파일 그룹에 대해 다른 복제 방법을 사용할 수 있도록 설계하기 만하면됩니다. SAN 장비는 네트워크, 테이프 또는 SAN을 통해 luns를 동기화 할 수 있습니다. 즉, SAN의 일부를 앞뒤로 배송 할 수 있습니다. 이는 SAN이 참여 장치 풀로 구성된 LeftHand와 같은 장비에서 더 효과적입니다.

그런 다음 유선을 통해 낮은 변화율 항목을 자동으로 동기화하고 높은 변화율을 운동화와 동기화 할 수 있습니다. (내가 그것을 가지고있는 것처럼 들리지만 사실입니다. 볼륨 때문에 와이어를 통해 높은 변화율을 동기화 할 수는 없습니다.) 저급 기어 중 일부조차도 이것을 수용합니다 : LeftHand를 사용하면 다른 것으로 복제 할 수 있습니다 데이터 센터의 LeftHand 장치를 오프 사이트 데이터 센터로 배송하십시오. 플러그를 꽂고 IP와 그룹을 변경하여 원격에 연결하면 이제 원격 백업 SAN의 일부가됩니다. 이것에 대한 LeftHand 판매 피치는 훌륭합니다. 기본 데이터 센터에서 두 개의 SAN을 나란히 설정하고 동기화 한 다음 일부를 현재 원격으로 유지하면서 원격 데이터 센터로 옮길 수 있습니다 동기화 할 데이터 센터 점차적으로 '

그러나 페타 바이트 수준에서는이 작업을 수행하지 않았습니다. 당신은 그들이 말하는 것을 알고 있습니다-이론, 이론 및 실제로는 동일합니다. 실제로...

옵션 1은 미러링이며, 이는 # 4와 거의 비슷합니다. 데이터를 손상시키고 즉시 발견되지 않는 버그는 두 사본을 모두 손상시킵니다.

데이터가 중요한 경우 전용 솔루션을 고려하십시오. IBM의 Shark 제품 (예 : EMS의 경쟁 제품 등)에 대해 읽어보십시오. Flash-copy와 같은 기능을 통해 디스크 요구 사항을 두 배로 늘리지 않고도 파일의 논리적 사본을 즉시 만들 수 있습니다. 그런 다음이 사본을 테이프에 백업 할 수 있습니다. 로봇 테이프 백업도 살펴보십시오.

스토리지가 저렴하지 않은 페타 바이트 규모의 데이터를 저장하려는 사람들을 지적하십시오.

디스크가 저렴하기 때문에 여분의 테라 바이트 온라인 저장 공간이 없다는 것에 대해 신음하는 사람들이 생겨났습니다.

백업을 저장하는 데 엄청나게 비싸다면 안전한 방법으로 데이터를 저장하는 것이 엄청나게 비싸므로 제안 된 솔루션을 실행할 수 없습니다.

백업을해야하는 가장 중요한 이유 중 하나는 사용자 오류 방지 (대부분의 하드웨어 오류 문제는 하드웨어 솔루션으로 처리 할 수 ​​있음)이지만 데이터베이스 미러링조차도 삭제 된 테이블에 대한 보호는 아닙니다 (그렇습니다. DB가 너무 크지 않은 한 삽입물 만 발행하기 때문에 DB에 제거 할 수없는 guff를 얻을 수 있습니다.

내가 볼 수 있듯이 테이프는 더 이상 실행 가능한 솔루션이 아니며 디스크 스토리지로 작업하는 것이 더 저렴합니다 (물리적 스토리지는 어색 할 수 있음). 따라서 유일한 옵션은 합리적인 시간 내에 복원 할 수있을 정도로 작은 크기의 데이터를 청크로 분할 한 다음 정기적으로 디스크 스토리지에 데이터를 가져 오는 몇 가지 방법이라고 생각합니다. 현금).

myspace.com의 아키텍처를 자세히 설명하는 흥미로운 비디오 (SQL2005 백엔드). 여러 DB로 확장 할 때 개별 페타 바이트 DB가 있는지 확실하지 않습니다. SAN 스냅 백업을 사용합니다.

http://wtv.watchtechvideos.com/topic70.html

ZFS. 물론, 아직 막 시작되었지만 ZFS가 이러한 종류의 것을 처리하도록 설계된 영역이 많이 있습니다. 우선, 많은 양의 데이터뿐만 아니라 다양한 스토리지 장치 (로컬, SAN, 파이버 등)를 처리하는 동시에 체크섬과 장치 상태에 대한 "계층 위반"인식으로 데이터를 안전하게 유지하고 실패. 그래도 많은 양의 데이터 백업을 해결하는 데 어떻게 도움이됩니까?

한 가지 방법은 스냅 샷을 사용하는 것입니다. 스냅 샷을 찍어 원격 사이트로 전송할 수 있도록 테이프 / 디스크 / 넷으로 보냅니다. 후속 스냅 샷은 전송 된 데이터 만 전송하며 필요한 경우 실시간 데이터를 양쪽 끝에 유지할 수 있습니다.

다른 하나는 네트워크 대역폭이 충분한 한 두 서버간에 실시간 미러링을 수행 할 수 있고 서버가 다운되면 두 번째 서버가 대신 할 수있는 Solaris Cluster 소프트웨어를 사용하는 것입니다. 고 가용성 (HA)이 중요한 경우에는 더 유용하지만 데이터가 많은 대부분의 장소에서 HA를 원한다고 생각합니다.

그리고 ZFS는 Windows에서 지원되지 않는다고 말합니다. sqlserver를 찾을 수있는 일반적인 장소입니다. 백엔드에서 Sun / ZFS를 실행하고 iSCSI를 통해 연결할 수 있습니다. 어쩌면 그것은 끔찍한 아이디어 일지 모르지만 적어도 생각하지 말아야 할 일을 알면 가치가 있습니다.

옵션으로 Amazon Glacier를 살펴 보셨습니까?

IMO, 어떤 종류의 고질라 수준의 하드웨어가 없다면, 데이터가 많으면 백업 압축 기술을 사용해야합니다. 저는 LiteSpeed에 대해 가장 잘 알고 있지만 다른 공급 업체의 유사한 제품이 있으며 SQL2008에 유사한 기능이 내장되어 있습니다. 10 대 1 압축을 얻지 못할 수도 있지만 백업에 대한 스토리지 요구 사항이 줄어들고 백업 창 요구 사항이 줄어들 수도 있습니다. 여러 백업 세트를 유지하는 것이 목표 인 경우 (어제 + 그 전날, 지난 주에서 하나, 지난 달에서 하나 또는 일련의 차등 + 전체), 많은 데이터를 변경하면 크게 커질 수 있습니다. 데이터베이스), 저장 공간의 간단한 문제입니다.

파일 그룹 기반 백업 (IOW, 비 휘발성 데이터를 특정 FG에 저장하고 가끔 백업하는 경우는 드물게 발생 함)은 개발자 나 사용자가 어떤 데이터가 휘발성인지 아닌지, 브라운 필드에 있는지를 결정하지 못하거나 결정할 수 없기 때문에 결코 비행하지 않는 것처럼 보입니다. 시나리오는 종종 위험을 감수 할 수 없습니다.

장애 조치 사이트가 필요한 경우 (데이터베이스 미러에 대한 생각과 더불어) 클라이언트의 스토리지 공급 업체에 문의하여 하드웨어 기반 데이터 복제 기술인 SRDF와 같은 것을 제공하는지 확인할 수 있습니다. 당연히, 복제 (어떤 종류의, 그러나 특히 실시간 또는 거의 실시간 복제)는 백업을 대체하지 않습니다.

나는 당신이 테이프 v. 디스크에서 선택의 여지가 많이 있다고 생각하지 않습니다. 테이프를 벗기지 않으면 정기적 인 백업 창에서 테이프가 잘리지 않을 것이므로 안정성이 확실하지 않습니다.

따라서 디스크 백업을해야합니다. 버전 관리 중입니까? 백업 2 (현재 db-2 백업)로 돌아가는 것에 대해 걱정하십니까? 아니면 백업 3? 이 경우 문제가있을 수 있지만 처리해야 할 것은 데이터 백업이 아니라 로그 백업 일 것입니다.

일부 데이터를 읽기 전용 / 비 변경으로 분리 할 수있는 경우 관리 가능한 백업 크기 / 창이있을 수 있습니다. 또는 최소한 백업 기술과 대역폭이 데이터 증가에 발 맞추기를 기대하고 있습니다.

기본 문제와 관련하여 문제를 해결하기 위해 두 번째 사본을 보관하는 것만 큼 백업하고 있다고 생각하지 않습니다. 이는 하드웨어, 손상 등을 의미하며 오류가 두 번째 사본으로 전달되지 않도록 매일기도하고 있습니다. 복제본은 SAN-SAN으로 만들어졌으며 일부 스냅 샷 기술이 있습니다. 원본 사본은 전선을 통하지 않고 Fed-Ex를 통해 이루어질 수 있습니다. 100TB를 이동하는 대역폭은 누구에게나 쉽게 제공되지 않습니다.

탁월한 로그 백업 관리 기능을 갖춘 1, 2 및 3 (4 아님)의 조합이 필요하다고 생각합니다.

실제로 저는 어느 시점에서나 실제로 3 개의 데이터 사본을보고 있다고 생각합니다. 두 번째 사본이 실제로 변경 사항을 수신하는 데 사용되는 동안 사본 중 하나에서 CHECKDB 실행 그런 다음 해당 두 번째 사본을 첫 번째 사본으로 스냅 샷하고 계속하십시오. 이 많은 데이터를 통해 여기에 약간의 부지런함이 필요하다고 생각합니다. Paul, checkdb는 온라인 상태 인 다중 사용자 100TB DB에서 어떻게 작동합니까?

언급했듯이, 로그 백업이 아니고 아마도 로그 리더가 중요하지 않습니까? 백업이 아닌 로그에서 테이블 삭제 / 사용자 오류를 복구 할 필요가 없습니까? 약간의 지연을 통해 SAN 사본을 보내이 문제를 해결할 수는 있지만 그 기술을 보지 못했습니다. 데이터를 덮어 쓰기 전에 문제를 복구 할 수 있도록 변경 사항을 4 시간 (또는 일정 간격) 지연시킬 수있는 Log Shipping SAN. 아니면 일부 SAN 차단기 변경 도구가 있습니까? 그렇지 않으면 이러한 트랜잭션 로그를 관리해야합니다. 트랜잭션 로그는 치명적이지 않은 오류로부터 잠재적으로 복구 할 수 있도록 몇 시간 동안 다양한 파일 시스템에서 백업을 추적하는 완전히 다른 수준 일 수 있습니다.

기술적으로 스토리지 는 저렴하지만 페타 바이트 수준에서는 그리 많지 않습니다. 그것은 실제로 응용 프로그램에 달려 있지만, 전략 # 2와 # 3의 조합이 대답이 될 것이라고 말할 것입니다. 저장소에 투자 할 수있는 양과 종류에 따라 # 2와 주어진 # 3이 있습니다. 스토리지 및 IO / 계산 기능을 통해 증분을 최소화하고 최대한 신중하고 완전한 백업을 수행 할 수 있습니다.

또는 대역폭과 데이터에 얼마나 많은 변화가 있는지에 따라 Amazon S3와 같은 기능이 작동 할 수 있습니다.이 볼륨에서 적어도 일부는 다른 사람의 서버에 배치하고 중복에 대해 걱정하게 만듭니다. 비용 효과적입니다.

스토리지 공급 업체에 문의하면 이전에 사용한 중복 제거 제품을 정기적 압축과 결합하여 데이터 풋 프린트를 70 % 줄일 수 있습니다. 물론 페타 바이트 규모의 스토리지에 투자 할 돈이있는 사람도 적절한 백업 솔루션을 구매할 예산을 가지고있을 가능성이 높습니다.

대규모 엔터프라이즈 데이터웨어 하우스에서 많은 데이터는 이미 백업 된 소스에서 가져옵니다. Teradata 및 ODW 설치에서 옵션 # 4를 사용했지만 하루 또는 이틀의 트랜잭션 데이터를 복원하여 소스 시스템에서 변환 할 수 있다는 것을 알고있었습니다.

한 소매 업체 고객 (세계에서 가장 큰 5 대 DW 중 하나 인 약 200TB)은 새로운 페타 바이트를 구매 한 후 옵션 1을 사용했습니다. 클래스 Teradata 서버. 이전 노드는 전날 시스템의 스냅 샷에 사용되는 반면 새 노드는 기존 시스템을 유지 관리했습니다. 이것은 페일 오버 관점에서도 좋았습니다. 가끔씩 유지 관리를 위해 모든 것을 중단하고 오래된 서버를 오래된 데이터와 함께 사용하도록 전환했습니다.

솔직히 말해서, 처리를 계속하는 것은 처리 / 저장 등의 큰 낭비처럼 보였습니다. 특히 가장 큰 장점은 불규칙한 유지 보수를 수행하기 위해 관리자와 NCR 기술 담당자가 저녁 시간을 줄여야한다는 것입니다.