SQL Server의 백업 및 복원 전략 소개

SQL Server 백업을 만드는 목적은 손상된 데이터베이스를 복구할 수 있게 하는 데 있습니다. 하지만 데이터 백업 및 복원은 특정 환경에 맞게 사용자 지정되어야 하며 적절한 리소스도 마련되어야 합니다. 따라서 복구를 위해 백업 및 복원을 안정적으로 사용하려면 백업 및 복원 전략이 필요합니다. 잘 디자인된 백업 및 복원 전략은 사용자의 특정 비즈니스 요구 사항을 감안해 데이터 가용성을 극대화하고 데이터 손실을 최소화합니다.

중요 정보중요

데이터베이스와 백업을 서로 다른 장치에 배치하십시오. 그렇지 않으면 데이터베이스가 들어 있는 장치가 실패할 경우 백업을 사용할 수 없습니다. 데이터와 백업을 서로 다른 장치에 배치하면 백업 작성 및 데이터베이스의 프로덕션 사용에 대한 I/O 성능도 향상됩니다.

백업 및 복원 전략은 백업에 관련된 부분과 복원에 관련된 부분으로 이루어집니다. 전략의 백업 관련 부분에서는 백업 유형 및 빈도, 백업에 필요한 하드웨어의 특성 및 속도, 백업 테스트 방법 및 백업 미디어 보관 위치 및 보관 방법(보안 고려 사항 포함)을 정의합니다. 전략의 복원 관련 부분에서는 누가 복원을 담당할 것이며 어떻게 데이터베이스 가용성 목표를 충족시키고 데이터 손실을 최소화할 것인가를 정의합니다. 백업 및 복원 절차를 문서화하고 실행 문서에 사본을 보관하는 것이 좋습니다.

효과적인 백업 및 복원 전략 설계를 위해서는 신중한 계획, 구현 및 테스트가 필요합니다. 테스트는 반드시 필요합니다. 복원 전략에 포함된 모든 조합의 백업을 성공적으로 복원해야만 백업 전략을 갖추게 됩니다. 다음과 같은 다양한 요소를 고려해야 합니다.

  • 데이터베이스에 대한 사용자 조직의 생산성 목표(특히 가용성 및 데이터 손실 방지 요구 사항)

  • 크기, 사용 패턴, 내용의 특성, 데이터 요구 사항 등과 같은 각 데이터베이스의 특성

  • 하드웨어, 인력, 백업 미디어 저장 공간, 저장된 미디어의 물리적 보안 등과 같은 리소스의 제약 요건

    [!참고]

    SQL Server 디스크상 저장소 형식은 64비트 및 32비트 환경에서 동일합니다. 따라서 32비트 및 64비트 환경에서 백업 및 복원 작업을 수행할 수 있습니다. 한 환경에서 실행 중인 서버 인스턴스에서 만든 백업을 다른 환경에서 실행하는 서버 인스턴스에서 복원할 수 있습니다.

백업 및 복원에 대한 복구 모델의 영향

백업 및 복원 작업은 복구 모델의 컨텍스트에서 수행됩니다. 복구 모델은 트랜잭션 로그의 관리 방법을 제어하는 데이터베이스 속성입니다. 또한 데이터베이스의 복구 모델은 데이터베이스에 지원되는 복원 시나리오 및 백업 유형을 결정합니다. 일반적으로 데이터베이스는 단순 복구 모델 또는 전체 복구 모델 모두 사용합니다. 전체 복구 모델은 대량 작업 이전에 대량 로그 복구 모델로 전환하여 보완될 수 있습니다. 이러한 복구 모델 및 이러한 복구 모델이 트랜잭션 로그 관리에 미치는 영향에 대한 자세한 내용은 복구 모델 및 트랜잭션 로그 관리를 참조하십시오.

데이터베이스에 가장 적합한 복구 모델은 비즈니스 요구 사항에 따라 달라집니다. 트랜잭션 로그 관리를 방지하고 백업 및 복원을 단순화하려면 단순 복구 모델을 사용하십시오. 관리 오버헤드가 증가하더라도 작업 손실 가능성을 최소화하려면 전체 복구 모델을 사용하십시오. 백업 및 복원에 미치는 복구 모델의 영향에 대한 자세한 내용은 다음 항목을 참조하십시오.

백업 전략 디자인

지정한 데이터베이스에 대해 비즈니스 요구 사항에 맞는 복구 모델을 선택한 후에는 해당 백업 전략을 계획 및 구현해야 합니다. 백업 전략을 최적화하는 요소는 다양합니다. 그 중에서도 특히 다음과 같은 요소에 의해 주로 영향을 받습니다.

  • 응용 프로그램이 하루에 몇 시간 데이터베이스에 액세스해야 합니까?

    사용량이 적은 기간을 예측할 수 있는 경우 해당 기간에 전체 데이터베이스 백업을 예약하는 것이 좋습니다.

  • 얼마나 자주 변경과 업데이트가 발생합니까?

    자주 변경하는 경우 다음을 고려하십시오.

    • 단순 복구 모델에서는 전체 데이터베이스 백업 사이에 차등 백업을 예약하십시오. 차등 백업은 마지막 전체 데이터베이스 백업 이후의 변경 내용만 캡처합니다.

    • 전체 복구 모델에서는 자주 로그 백업을 예약해야 합니다. 전체 백업 사이에 차등 백업을 예약하면 데이터를 복원한 후 복원해야 하는 로그 백업 수가 감소하므로 복원 시간이 줄어들 수 있습니다.

  • 변경이 데이터베이스의 일부분에서만 발생합니까? 아니면 데이터베이스의 대부분에서 발생합니까?

    변경 내용이 파일 또는 파일 그룹의 일부분에만 집중되어 있는 큰 데이터베이스의 경우 부분 백업이나 파일 백업이 유용할 수 있습니다. 자세한 내용은 부분 백업전체 파일 백업을 참조하십시오.

  • 전체 데이터베이스 백업에 필요한 디스크 공간은 어느 정도입니까?

    자세한 내용은 이 항목의 뒷부분에 나오는 "전체 데이터베이스 백업의 크기 예측"을 참조하십시오.

전체 데이터베이스 백업의 크기 예측

백업 및 복원을 구현하기 전에 전체 데이터베이스 백업에 어느 정도의 디스크 공간이 필요한지 예측해야 합니다. 백업 작업은 데이터베이스의 데이터를 백업 파일로 복사합니다. 백업에는 데이터베이스의 실제 데이터만 포함되고 사용하지 않은 공간은 포함되지 않습니다. 따라서 백업은 일반적으로 데이터베이스 자체의 크기보다 작습니다. sp_spaceused 시스템 저장 프로시저를 사용하여 전체 데이터베이스 백업의 크기를 예측할 수 있습니다. 자세한 내용은 sp_spaceused(Transact-SQL)를 참조하십시오.

백업 예약

각 경우에 필요한 백업 유형과 수행 빈도를 결정한 후 데이터베이스 유지 관리 계획의 일부로 데이터베이스에 대한 정기 백업을 예약하는 것이 좋습니다. 유지 관리 계획에 대한 정보와 데이터베이스 백업 및 로그 백업에 대한 유지 관리 계획을 만드는 방법은 데이터베이스 유지 관리(데이터베이스 엔진)유지 관리 계획 마법사를 참조하십시오.

유지 관리 계획을 만들려면

작업을 만들고 예약하려면

백업 테스트

백업을 테스트해야만 복원 전략을 갖추게 됩니다. 데이터베이스 복사본을 테스트 시스템으로 복원하여 각 데이터베이스에 대한 백업 전략을 철저히 테스트하는 것이 중요합니다. 사용할 모든 유형의 백업 복원을 테스트해야 합니다.

각 데이터베이스에 대한 작업 매뉴얼을 작성하여 관리하는 것이 좋습니다. 이 작업 매뉴얼에는 백업 위치, 백업 장치 이름(있는 경우) 및 테스트 백업을 복원하는 데 필요한 시간 등이 수록되어야 합니다.