SQL 백업에서 "백업 무결성 확인"해제의 영향 / 위험 이해

현재 우리는 환경에서 SQL Server 2005 / 2008 / 2008R2 / 2012 서버의 백업에 대한 표준 유지 관리 계획을 사용하며 "백업 무결성 확인"상자가 항상 선택되어 있습니다.

일부 백업은 매우 오래 실행되므로 해당 옵션을 해제하는 것이 좋습니다. 그러나 관리자는이 변경의 영향과 위험을 문서화해야합니다.

나는이 옵션의 사용과 역사를 이해하고, 그냥 백업 작업의 시간을 두 배로 나에게 불필요한 보인다 때 (내 생각에) 어떤 오류 가능성이 동안 발생할 수있는 발생하는 백업 이 아닌 확인 중 단계.

내가 잘못? 디스크에 백업하고 테이프 등을 스트리밍하지 않는 경우이 기능을 끄는 것이 최소한의 위험입니까? (관련된 경우 네트워크를 통해 EMC DD-800 백업 어플라이언스에 백업합니다.)

이 기능을 해제해도 안전한 경우에 대한 공식적인 MS 권장 사항이 있습니까?

환경의 모든 백업에서 "확인"을 실행합니까? 당신은 그들을 확인합니까?

편집 : 명확히하기 위해 유지 관리 계획에서 "백업 무결성 확인"을 확인하면 SQL은 각 백업 직후 각 데이터베이스에서 전체 복원을 VERIFYONLY 로 수행합니다. 이는 원래 백업만큼 데이터 / IO를 많이 사용하며 백업 작업의 전체 시간을 (기본적으로) 두 배로 늘립니다. 이다 하지 (내가 아는 한, 마법사에서 수행 할 수 없음) 백업에서 "검사"옵션을 사용하도록 설정과 동일.

내가 잘못? 디스크에 백업하고 테이프 등을 스트리밍하지 않는 경우이 기능을 끄는 것이 최소한의 위험입니까?

아니오, 당신이 맞습니다 :-)

RESTORE VERIFYONLY손상이 발생한 경우 데이터베이스를 복구 할 수는 없습니다. 본질적으로 무결성 검사를 수행하지 않습니다.

더 좋은 방법은 정기적으로 백업을 수행하고 다른 서버에서 유효한 복원을 수행하고 DBCC CHECKDB를 수행하는 것입니다.

이것이 GUI가 T-SQL에 의해 달성 될 수있는 것과 같은 많은 옵션을 노출시키지 않기 때문에 유지 보수 계획에 관심이없는 이유 중 하나 backup .. with CHECKSUM입니다.

에서 바울 랜달의 신화 블로그

24p) RESTORE… WITH WITH VERIFYONLY를 사용하면 전체 백업의 유효성이 검사됩니다

아니요. VERIFYONLY를 사용하면 백업 헤더가 백업 헤더처럼 보이는지 확인합니다. WITH CHECKSUM을 사용하여 백업을 수행하고 REVER… WITH VERIFYONLY 를 사용하여 복원하고 WITH CHECKSUM을 사용하는 경우에만 전체 백업에 대한 체크섬을 포함하여 복원이보다 광범위한 검사를 수행합니다.

환경의 모든 백업에서 "확인"을 실행합니까? 당신은 그들을 확인합니까?

나는 정말로 달리지 않는다. 대신 CHECKSUM으로 백업 한 다음 다른 서버에서 + CHECKDB를 복원했습니다. 창의성을 발휘하려면 데이터베이스 백업 확인을위한 통계 샘플링 방법을 따르십시오 .

이것은 백업에서 "체크섬"옵션을 활성화하는 것과 다릅니다 (이것은 내가 아는 한 마법사에서 수행 할 수 없음).

BACKUP 명령에 대해 옵션이 자동으로 활성화 되도록 추적 플래그 3023을 활성화 할 수 있습니다 CHECKSUM. 항상 그렇듯이 환경에서 추적 플래그의 동작을 테스트하십시오!

결론은-유지 보수 계획을 버리고 더 합리적인 백업 솔루션 (힌트 : Ola의 백업 솔루션) 을 사용하여 필요에 따라 사용자 정의 할 수 있습니다.

(관련된 경우 네트워크를 통해 EMC DD-800 백업 어플라이언스에 백업합니다.)

디스크에 로컬로 백업 한 다음 서버에서 네트워크 공유 (백업 서버)로 로컬로 백업을 복사하는 PowerShell 전송 작업이 있습니다. 네트워크 공유에 직접 복사하는 것보다 빠릅니다.

또한 즉각적인 파일 초기화를 활성화하면 데이터 파일의 자동 증가에 도움이 될뿐만 아니라 데이터베이스를 복원해야하는 경우 복원 시간을 단축 할 수 있습니다. 옵션을 편리하게 사용하는 것이 좋습니다.

좋은 읽기는 다음과 같습니다 백업 : 계획 복구 전략

결론은 데이터베이스 복원을 수행하지 않으면 주어진 백업 파일이 양호하다는 것을 완전히 확신 할 수 없다는 것입니다.

백업을 확인하기위한 이상적인 테스트는 일상적인 프로세스의 일부로 데이터베이스 백업 및 데이터베이스 로그 백업이 항상 복원되는 환경을 설정하는 것입니다. 이것은 로그 전달을 사용하는 이점 중 하나입니다 ...

여전히 확인 전용을 유지하려는 경우 특별히 환경을 설정할 수 있습니다. 이것은 (아마도) 프로덕션 서버에서 작업을 오프로드하고 작업 시간을 줄입니다.

마지막으로 유지 보수 계획에서 벗어나는 것을 고려 했습니까? Ola의 스크립트와 같은 스크립트는 백업 및 유지 관리를 제외하고 https://ola.hallengren.com/

기술적으로 복원 verfyonly는 복원을 수행하는 것과 같지만 실제로 데이터베이스를 복원하여 유효한 백업을 확인하는 것이 더 좋습니다. 우리는 verifyonly가 통과 한 인스턴스가 있었지만 손상으로 인해 데이터베이스가 복원되지 않을 것입니다. 제 시점은 백업이 괜찮은 확인으로 여기에 포함되지 않습니다. 우리는 이제 모든 데이터베이스를 별도의 인스턴스에 복원하여 유효성을 확인하는 시스템을 개발했습니다. 항상 가능하지는 않으므로 일주일에 특정 데이터베이스를 샘플링하십시오. 길고 짧은 검증 100 %를 신뢰하지 않습니다.