Commvault를 사용한 백업: 일부 통계 및 사례

이전 게시물에서는 설정 방법을 공유했습니다. 예약 사본 и 복제 Veeam을 기반으로 합니다. 오늘은 Commvault를 사용한 백업에 대해 이야기하고 싶습니다. 지침은 없지만 고객이 이미 백업하고 있는 내용과 방법을 알려 드리겠습니다.

OST-2 데이터 센터의 Commvault 기반 백업 시스템의 스토리지 시스템입니다.

어떻게 작동합니까?

Commvault는 애플리케이션, 데이터베이스, 파일 시스템, 가상 머신 및 물리적 서버를 위한 백업 플랫폼입니다. 이 경우 초기 데이터는 클라이언트 측, 다른 상용 데이터 센터 또는 클라우드 등 모든 사이트에 있을 수 있습니다.

클라이언트는 백업 개체에 에이전트를 설치합니다. iData 에이전트 - 필요한 백업 정책에 따라 구성합니다. iData Agent는 필요한 데이터를 수집하고 압축, 중복 제거, 암호화하여 DataLine 백업 시스템으로 전송합니다.

프록시 서버 클라이언트 네트워크와 당사 네트워크의 연결을 보장하고 데이터가 전송되는 채널을 격리합니다.

DataLine 측에서는 iData Agent의 데이터가 수신됩니다. 미디어 에이전트 서버 그리고 이를 스토리지 시스템, 테이프 라이브러리 등의 스토리지로 보냅니다. 이 모든 것은 다음에 의해 관리됩니다. 통신. 우리 구성에서 주 제어 서버는 OST 사이트에 있고 백업 서버는 NORD 사이트에 있습니다.

기본적으로 클라이언트 데이터는 한 사이트에 저장되지만 백업을 두 위치에 동시에 구성하거나 백업을 두 번째 사이트로 전송하는 일정을 설정할 수 있습니다. 이 옵션을 "보조 복사"라고 합니다. 예를 들어, 월말의 모든 전체 백업은 자동으로 복제되거나 두 번째 사이트로 이동됩니다.

Commvault 백업 시스템의 작동 방식.

백업 시스템은 주로 VMware 가상화에서 작동합니다. CommServe, 미디어 에이전트 및 프록시 서버는 가상 머신에 배포됩니다. 고객이 당사 장비를 사용하는 경우 백업은 Huawei OceanStor 5500 V3 스토리지 시스템에 저장됩니다. 클라이언트 스토리지 시스템을 백업하고 테이프 라이브러리에 백업을 저장하려면 물리적 서버에 별도의 미디어 에이전트가 사용됩니다.

고객에게 중요한 것은 무엇입니까?

경험에 따르면 Commvault를 백업용으로 선택하는 고객은 다음 사항에 주의해야 합니다.

콘솔. 고객은 백업을 직접 관리하기를 원합니다. Commvault 콘솔에서는 모든 기본 작업을 사용할 수 있습니다.

• 백업용 서버 추가 및 제거;
• iData 에이전트 설정;
• 작업 생성 및 수동 시작
• 백업 자체 복원;
• 백업 작업 상태에 대한 알림 설정
• 사용자의 역할과 그룹에 따라 콘솔에 대한 액세스를 차별화합니다.

중복 제거. 중복 제거를 사용하면 백업 프로세스 중에 중복된 데이터 블록을 찾아서 제거할 수 있습니다. 따라서 스토리지 시스템의 공간을 절약하고 전송되는 데이터 양을 줄여 대역폭 요구 사항을 줄이는 데 도움이 됩니다. 중복 제거가 없으면 백업은 원본 데이터 크기의 최대 XNUMX~XNUMX배를 차지하게 됩니다.

Commvault의 경우 클라이언트 측이나 미디어 에이전트 측에서 중복 제거를 구성할 수 있습니다. 첫 번째 경우에는 고유하지 않은 데이터 블록이 미디어 에이전트 서버로 전송되지 않습니다. 두 번째에서는 반복 블록이 삭제되고 스토리지 시스템에 기록되지 않습니다.

이러한 블록 중복 제거는 해시 함수를 기반으로 합니다. 각 블록에는 일종의 데이터베이스(DDB)인 해시 테이블에 저장되는 해시가 할당됩니다. 데이터를 전송할 때 해시는 이 베이스를 통해 "펀칭"됩니다. 그러한 해시가 이미 데이터베이스에 있는 경우 블록은 고유하지 않은 것으로 표시되고 미디어 에이전트 서버(첫 번째 경우)로 전송되거나 데이터 스토리지 시스템(두 번째 경우)에 기록되지 않습니다.

중복 제거 덕분에 저장 공간을 최대 78%까지 절약할 수 있습니다. 이제 166,4TB가 스토리지에 저장됩니다. 중복 제거가 없으면 744TB를 저장해야 합니다.

권리의 차별화 가능성. Commvault에는 백업 관리에 대한 다양한 액세스 수준을 설정할 수 있는 기능이 있습니다. 소위 "역할"에 따라 어떤 조치가 취해질지 결정됩니다. 허용 된 백업 개체와 관련된 사용자입니다. 예를 들어, 개발자는 데이터베이스가 있는 서버만 특정 위치로 복원할 수 있는 반면, 관리자는 동일한 서버에 대해 비순차적 백업을 실행하고 새 사용자를 추가할 수 있습니다.

암호화. 다음과 같은 방법으로 Commvault를 통해 백업하는 동안 데이터를 암호화할 수 있습니다.

• 클라이언트 에이전트 측: 이 경우 데이터는 이미 암호화된 형식으로 백업 시스템에 전송됩니다.
• 미디어 에이전트 측에서;
• 채널 수준: 데이터가 클라이언트 에이전트 측에서 암호화되고 미디어 에이전트 서버에서 해독됩니다.

사용 가능한 암호화 알고리즘: Blowfish, GOST, Serpent, Twofish, 3-DES, AES(Commvault에서 권장)

일부 통계

27월 중순까지 Commvault의 도움으로 우리는 65명의 클라이언트를 백업하게 되었습니다. 이들 대부분은 소매업체와 금융기관이다. 원본 데이터의 총 용량은 XNUMXTB입니다.

하루에 대략 4400개의 작업이 수행됩니다. 다음은 지난 16일 동안 완료된 작업에 대한 통계입니다.

무엇보다도 Windows 파일 시스템, SQL Server 및 Exchange 데이터베이스는 Commvault를 통해 백업됩니다.

그리고 이제 약속된 사례입니다. 비인격적이지만(NDA가 안녕하세요 :)) 고객이 Commvault 기반 백업을 사용하는 방법과 방법에 대한 아이디어를 제공합니다. 다음은 단일 백업 시스템(예: 공유 소프트웨어, 미디어 에이전트 서버 및 스토리지 시스템)을 사용하는 고객에 대한 사례 연구입니다.

사례 1

고객. 러시아 전역에 분산된 지점 네트워크를 갖춘 제과 시장의 러시아 무역 및 제조 회사입니다.

작업.Microsoft SQL 데이터베이스, 파일 서버, 애플리케이션 서버, Exchange Online 사서함에 대한 백업 구성.

초기 데이터는 러시아 전역(10개 이상의 도시) 사무실에 있습니다. 회사 사무실에서 후속 데이터 복구를 수행하려면 DataLine 사이트에 백업해야 합니다.
동시에 클라이언트는 액세스 제어를 통한 완전한 자체 관리를 원했습니다.
저장 깊이 - 연도. Exchange Online의 경우 온라인 사본의 경우 3개월, 아카이브의 경우 XNUMX년입니다.

해결책. 두 번째 사이트의 데이터베이스에 대한 추가 복사본이 설정되었습니다. 해당 달의 마지막 전체 백업이 다른 사이트로 전송되어 XNUMX년 동안 저장됩니다.

클라이언트 원격 사무실의 채널 품질로 인해 항상 최적의 시간 내에 백업 및 복원이 가능한 것은 아닙니다. 전송되는 트래픽의 양을 줄이기 위해 클라이언트 측에서 중복 제거가 구성되었습니다. 그녀 덕분에 사무실이 멀리 떨어져 있다는 점을 고려하여 전체 백업 시간이 적당해졌습니다. 예를 들어, 상트페테르부르크에서 131GB의 전체 데이터베이스 백업이 16분 안에 완료됩니다. 예카테린부르크에서는 340GB 데이터베이스가 1시간 45분 동안 백업됩니다.

역할을 통해 고객은 개발자에게 백업 또는 복원만 허용하는 다양한 권한을 구성했습니다.

사례 2

고객. 러시아의 어린이 용품 매장 체인입니다.
작업. 백업 구성:
4개의 물리적 서버를 기반으로 하는 고부하 MS SQL 클러스터;
웹 사이트, 애플리케이션 서버, 1C, Exchange 및 파일 서버가 있는 가상 머신.
클라이언트의 지정된 전체 인프라는 OST와 NORD 사이트 사이에 배치됩니다.
SQL 서버의 RPO는 30분, 나머지는 1일입니다.
저장 깊이 - 데이터 유형에 따라 2주에서 30일까지입니다.

해결책. 우리는 Veeam과 Commvault를 기반으로 하는 솔루션 조합을 선택했습니다. Veeam은 클라우드의 파일 백업에 사용됩니다. 데이터베이스 서버, Active Directory, 메일 및 물리적 서버는 Commvault를 통해 백업됩니다.

높은 백업 속도를 달성하기 위해 클라이언트는 백업 작업을 위해 MS SQL이 설치된 물리적 서버에 별도의 네트워크 어댑터를 할당했습니다. 3,4TB 데이터베이스의 전체 백업에는 2시간 20분이 소요되고, 전체 복원에는 5시간 5분이 소요됩니다.

클라이언트에는 많은 양의 초기 데이터(거의 18TB)가 있었습니다. 클라이언트가 이전에 했던 것처럼 데이터를 테이프 라이브러리에 쌓으려면 수십 개의 카트리지가 필요합니다. 이로 인해 클라이언트의 전체 백업 시스템 관리가 복잡해집니다. 따라서 최종 구현에서는 테이프 라이브러리가 스토리지 시스템으로 교체되었습니다.

사례 3

고객. CIS의 슈퍼마켓 체인
작업. 고객은 우리 클라우드에 호스팅된 SAP 시스템을 백업하고 복원하기를 원했습니다. SAP HANA 데이터베이스의 경우 RPO=15분, 애플리케이션 서버가 있는 가상 머신의 경우 RPO=24시간입니다. 보관 기간 - 30일. 사고가 발생한 경우 RTO=1시간, 요청 시 복사본을 복원하는 데 필요한 RTO=4시간.

해결책. HANA 데이터베이스의 경우 DATA 파일과 로그 파일의 백업이 지정된 간격으로 구성되었습니다. 로그 파일은 15분마다 또는 특정 크기에 도달하면 보관되었습니다.

데이터베이스 복구 시간을 줄이기 위해 스토리지 시스템과 테이프 라이브러리를 기반으로 1단계 백업 스토리지를 설정했습니다. 온라인 사본은 주중 언제든지 복구가 가능하도록 디스크에 추가됩니다. 백업이 30주일 이상 경과하면 아카이브인 테이프 라이브러리로 이동되어 추가로 XNUMX일 동안 보관됩니다.

181GB 데이터베이스 중 하나의 전체 백업은 1시간 54분 내에 완료됩니다.

백업을 설정할 때 SAP HANA Studio와 타사 백업 시스템을 통합할 수 있는 SAP backint 인터페이스가 사용되었습니다. 따라서 SAP 콘솔에서 직접 백업을 관리할 수 있습니다. 이를 통해 새 인터페이스에 익숙해질 필요가 없는 SAP 관리자의 업무가 더욱 쉬워집니다.

표준 Commvault 클라이언트 콘솔을 통해서도 클라이언트에서 백업 관리를 사용할 수 있습니다.

오늘은 그게 다야. 댓글로 질문하세요.

출처 : habr.com