준비된 백업: 연휴를 기리기 위한 신화 깨기

백업은 모든 아이언에서 외치는 유행 기술 중 하나가 아닙니다. 진지한 회사에 있어야합니다. 그게 전부입니다. 우리는 은행에 있는 수천 대의 서버를 백업합니다. 이것은 복잡하고 흥미로운 작업이며 백업에 대한 일반적인 오해뿐만 아니라 일부 미묘함을 알려주고 싶습니다.

저는 거의 20년 동안 이 주제에 대해 연구해 왔으며 그 중 지난 2년은 Promsvyazbank에서 근무했습니다. 연습 초기에는 단순히 파일을 복사하는 스크립트를 사용하여 거의 수동으로 백업을 수행했습니다. 그런 다음 편리한 도구가 Windows에 나타났습니다. 파일 준비를 위한 Robocopy 유틸리티와 복사를 위한 NT 백업입니다. 그리고 나서야 지금은 Symantec Backup Exec이라고 하는 Veritas Backup Exec과 같은 전문 소프트웨어가 등장했습니다. 그래서 오랫동안 백업에 익숙했습니다.

간단히 말해서 백업은 특정 규칙성이 있는 경우를 대비하여 데이터(가상 머신, 애플리케이션, 데이터베이스 및 파일)의 복사본을 유지하는 것입니다. 각 사례는 일반적으로 하드웨어 또는 논리적 오류로 나타나며 데이터 손실이 발생합니다. 백업 시스템의 목적은 정보 손실을 줄이는 것입니다. 하드웨어 오류는 예를 들어 데이터베이스가 있는 서버 또는 스토리지의 오류입니다. 논리적 - 이것은 인적 요인으로 인한 것을 포함하여 데이터 일부의 손실 또는 변경입니다. 실수로 테이블, 파일을 삭제하고 실행을 위해 비뚤어진 스크립트를 시작했습니다. 예를 들어 최대 몇 년 동안 특정 유형의 정보를 장기간 저장하기 위한 규제 요구 사항도 있습니다.

백업의 가장 일반적인 용도는 다양한 테스트 시스템의 배포를 위해 저장된 데이터베이스 복사본(개발자를 위한 클론)을 복원하는 것입니다.

오래 전에 버려야 할 백업에 대한 몇 가지 일반적인 통념이 있습니다. 다음은 그 중 가장 유명한 것입니다.

오해 1. 백업은 오랫동안 보안 또는 스토리지 시스템 내부의 작은 기능에 불과했습니다.

백업 시스템은 여전히 ​​별도의 솔루션 클래스로 남아 있으며 매우 독립적입니다. 그들은 할 일이 너무 많습니다. 실제로 데이터 무결성과 관련하여 최종 방어선입니다. 따라서 백업은 자체 일정에 따라 자체 속도로 작동합니다. 서버에 대한 일일 보고서가 생성되며 모니터링 시스템의 트리거 역할을 하는 이벤트가 있습니다.

또한 백업 시스템 액세스의 역할 모델을 통해 권한의 일부를 대상 시스템의 관리자에게 위임하여 백업을 관리할 수 있습니다.

신화 2. RAID가 있으면 더 이상 백업이 필요하지 않습니다.

의심할 여지 없이 RAID 어레이와 데이터 복제는 정보 시스템을 하드웨어 장애로부터 보호하는 좋은 방법이며 대기 서버가 있는 경우 주 시스템이 실패할 경우 이를 신속하게 전환하도록 구성할 수 있습니다.

시스템 사용자가 만든 논리적 오류에서 중복 및 복제는 저장되지 않습니다. 다음은 후기입 대기 서버입니다. 예, 동기화되기 전에 오류가 감지되면 도움이 될 수 있습니다. 그리고 그 순간을 놓치면? 시기 적절한 백업만이 여기에서 도움이 될 것입니다. 어제 변경된 데이터를 알고 있다면 시스템을 그저께로 복원하고 필요한 데이터를 추출할 수 있습니다. 논리적 오류가 가장 일반적이라는 사실을 감안할 때 좋은 오래된 백업은 여전히 ​​검증되고 필요한 도구입니다.

신화 3. 백업은 한 달에 한 번 하는 것입니다.

백업 빈도는 주로 백업 시스템 요구 사항에 따라 달라지는 구성 가능한 설정입니다. 거의 변경되지 않고 특별히 중요하지 않은 데이터를 찾는 것이 가능하며 손실이 회사에 중요하지 않습니다.
실제로 그들은 한 달에 한 번 백업할 수 있으며 더 적은 빈도로 백업할 수 있습니다. 그러나 허용 가능한 데이터 손실을 설정하는 RPO(복구 지점 목표) 표시기에 따라 더 중요한 데이터가 더 자주 저장됩니다. 이것은 일주일에 한 번, 하루에 한 번 또는 한 시간에 여러 번일 수 있습니다. 우리는 DBMS에서 이러한 트랜잭션 로그를 가지고 있습니다.

시스템을 상용화할 때는 주요 사항, 업데이트 절차, 시스템 복원 절차, 백업 저장 절차 등을 반영한 백업 문서를 승인해야 합니다.

신화 4. 사본의 양이 지속적으로 증가하고 있으며 할당된 공간을 완전히 차지합니다.

백업에는 보존 기간이 제한되어 있습니다. 예를 들어 365년 동안 매일 2개의 백업을 모두 저장하는 것은 의미가 없습니다. 원칙적으로 일일 사본을 XNUMX주 동안 보관한 후 새 사본으로 교체하고 해당 월에 처음으로 만든 버전을 장기 보관하는 것이 허용됩니다. 차례로 특정 시간 동안 저장됩니다. 각 사본에는 수명이 있습니다.

데이터 손실 보호 기능이 있습니다. 규칙이 적용됩니다. 백업을 삭제하기 전에 다음 백업을 만들어야 합니다. 따라서 서버를 사용할 수 없는 등의 이유로 백업이 완료되지 않은 경우 데이터가 삭제되지 않습니다. 시간 프레임이 존중될 뿐만 아니라 세트의 사본 수도 제어됩니다. 시스템이 두 개의 전체 백업을 갖도록 설계된 경우에는 항상 두 개가 있으며 이전 백업은 새로운 세 번째 백업이 성공적으로 기록된 경우에만 삭제됩니다. 따라서 백업 아카이브가 차지하는 볼륨의 증가는 보호되는 데이터의 양 증가와만 연관되며 시간에 의존하지 않습니다.

오해 5. 백업 시작 - 모든 것이 중단됨

이렇게 말하는 것이 좋습니다. 모든 것이 걸려 있으면 관리자의 손이 거기에서 자라지 않습니다. 일반적으로 백업 성능은 여러 요인에 따라 달라집니다. 예를 들어 백업 시스템 자체의 속도: 디스크 스토리지, 테이프 라이브러리가 얼마나 빠릅니까? 백업 시스템의 서버 속도에서 데이터를 처리할 시간이 있는지 여부, 압축 및 중복 제거를 수행합니다. 또한 클라이언트와 서버 간의 통신 회선 속도도 마찬가지입니다.

백업은 백업 중인 시스템이 멀티스레딩을 지원하는지 여부에 따라 하나 이상의 스트림으로 이동할 수 있습니다. 예를 들어 Oracle DBMS를 사용하면 전송 속도가 네트워크 대역폭 제한에 도달할 때까지 사용 가능한 프로세서 수에 따라 여러 스레드를 제공할 수 있습니다.

많은 수의 스레드를 백업하려고 하면 실행 중인 시스템에 과부하가 걸릴 가능성이 있으며 실제로 속도가 느려지기 시작합니다. 따라서 충분한 성능을 보장하기 위해 최적의 스레드 수를 선택합니다. 약간의 성능 저하라도 중요한 경우 백업이 전투 서버가 아니라 복제본에서 수행될 때 탁월한 옵션이 있습니다. 데이터베이스 용어로는 대기입니다. 이 프로세스는 기본 작업 시스템을 부팅하지 않습니다. 서버가 유지 보수에 사용되지 않기 때문에 더 많은 스트림을 통해 데이터를 검색할 수 있습니다.

대규모 조직에서는 백업이 프로덕션에 영향을 미치지 않도록 백업 시스템에 대해 별도의 네트워크가 생성됩니다. 또한 트래픽은 네트워크가 아니라 SAN을 통해 전송될 수 있습니다.

우리는 또한 시간이 지남에 따라 부하를 분산시키려고 노력합니다. 백업은 주로 근무 외 시간(야간, 주말)에 수행됩니다. 또한 모두 동시에 실행되지 않습니다. 가상 머신의 백업은 특별한 경우입니다. 이 프로세스는 시스템 자체의 성능에 실질적으로 영향을 미치지 않으므로 백업을 낮에 분산하고 밤에 모든 것을 연기할 수 없습니다. 많은 미묘함이 있습니다. 모든 것을 고려하면 백업이 시스템 성능에 영향을 미치지 않습니다.

신화 6. 백업 시스템을 시작했습니다. 이것이 바로 내결함성입니다.

백업 시스템이 최후의 방어선이라는 사실을 잊지 마십시오. 즉, IT 인프라와 엔터프라이즈 정보 시스템의 연속성, 고가용성 및 내재해성을 보장하는 시스템이 XNUMX개 더 있어야 합니다.

백업이 모든 데이터를 복원하고 빠르게 무너진 서비스를 올리기를 바라는 것은 가치가 없습니다. 백업 시점부터 실패 시점까지 데이터 손실이 보장되며, 몇 시간(또는 운이 좋으면 며칠) 동안 새로운 서버에 데이터를 업로드할 수 있습니다. 따라서 모든 것을 백업으로 전환하지 않고 본격적인 내결함성 시스템을 만드는 것이 좋습니다.

신화 7. 백업을 한 번 설정하고 제대로 작동하는지 확인했습니다. 로그를 보는 것만 남아 있습니다.

이것은 가장 해로운 신화 중 하나이며 사건 중에만 가짜임을 깨닫습니다. 성공적인 백업 로그는 모든 것이 실제로 제대로 진행되었음을 보장하지 않습니다. 사전에 배포 가능성을 위해 저장된 사본을 확인하는 것이 중요합니다. 즉, 테스트 환경에서 복구 프로세스를 시작하고 결과를 확인합니다.

그리고 시스템 관리자의 작업에 대해 조금

수동 모드에서는 아무도 오랫동안 데이터를 복사하지 않았습니다. 최신 SRK는 거의 모든 것을 백업할 수 있으므로 올바르게 설정하기만 하면 됩니다. 새 서버가 추가된 경우 정책을 설정합니다. 백업할 콘텐츠를 선택하고 스토리지 옵션을 지정하고 일정을 적용합니다.

동시에 데이터베이스, 메일 시스템, 가상 머신 클러스터, Windows 및 Linux/Unix의 파일 공유를 포함하는 광범위한 서버로 인해 여전히 많은 작업이 필요합니다. 백업 시스템을 계속 실행하는 직원은 가만히 앉아 있지 않습니다.

휴일을 기리기 위해 모든 관리자가 강한 신경, 움직임의 명확성 및 끝없는 백업 저장 공간을 기원합니다!

출처 : habr.com