SQL Server의 장단점 백업 전략 및 해당 사용 시나리오

내가 알 수 있듯이 SQL Server 데이터베이스를 백업하는 세 가지 방법이 있습니다

1. 전체 백업
2. 차등 백업
3. 로그 배송

각 전략의 장단점은 무엇이며 어떤 상황에서 사용해야합니까?

로그 전달은 백업 시나리오가 아닙니다. 반 고 가용성 시나리오입니다.
백업에는 전체, 차등 및 트랜잭션 로그 백업이 있습니다. 모두 함께 사용해야합니다. SLA에 사용 방법이 명시되어 있습니다. 가장 일반적인 시나리오는 자정에 전체 백업, 정오에 diff 백업 및 30 또는 15 분마다 트랜잭션 로그 백업입니다.

기억하십시오 : 백업이 정상인지 테스트하기 위해 복원 할 때까지 유효한 백업이 없습니다.

백업 전략과 같은 개념은 없을 것입니다. 복원 전략은 운영에 복귀 할 때까지 걸리는 시간을 결정하기 때문입니다 *.

차등 및 / 또는 로그 백업의 후속 복원을 수행하려면 모든 전략에 전체 백업이 필요합니다.

실제로 6 개월 전에 15 분 로그 백업으로 전체 백업을 수행 할 수 있습니다. 그러나 마지막 전체 백업에서 모든 로그 백업 을 적용해야합니다 .

임의의 예로서, 하나의 시나리오는 매주 전체, 차등, 로그 15 분일 수 있습니다.

백업 간격은 최악의 경우 손실되는 데이터의 양을 결정합니다. 15 분 로그 백업은 평균 7.5 분인 1 초에서 14 분 59 초 사이의 데이터 손실을 제공합니다. 이것이 허용됩니까?

로그 전달은 수동 장애 조치로 웜 대기 상태입니다. 백업이 아니라 고 가용성 옵션입니다.

모든 상황에 맞는 전략은 없습니다. 그러나 무엇을 이용할 수 있는지 이해하는 것이 중요합니다. 전체 백업은 데이터베이스의 전체 백업에서 트랜잭션 로그를 제외한 전체 백업과 같습니다. 차등 백업은 마지막 전체 백업 이후 데이터 파일의 변경 사항을 백업하는 것입니다. 트랜잭션 로그 백업은 마지막 트랜잭션 로그 백업 이후 트랜잭션 로그에 저장된 모든 트랜잭션을 백업합니다. 트랜잭션 로그 백업을 사용하면 특정 시점으로 복원 할 수 있습니다. 이것이 필요한 경우 복구 모드를 "전체"로 설정해야하며 복구 상황에서 손실 될 데이터 양에 따라 정기적 인 트랜잭션 로그 백업을 수행해야합니다.

트랜잭션 로그 백업을 처리 할 때는 로그 체인이 무엇인지 이해하는 것이 중요합니다. 즉, 로그 체인은 특정 시점으로 데이터베이스를 복원하기 위해 복원해야하는 일련의 백업입니다. 트랜잭션 로그 복원을 시작하려면 먼저 WITH NORECOVERY 옵션을 사용하여 전체 백업을 복원해야합니다. 차등 백업도 수행하는 경우 동일한 WITH NORECOVERY 옵션을 사용하여 복원하려는 시점 이전의 최신 차등 백업을 복원하려고합니다. 이때 최종 백업을 제외한 모든 백업에서 WITH NORECOVERY 옵션을 사용하여 트랜잭션 로그 백업을 순차적으로 복원해야합니다. 특정 시점 복원에 대한 자세한 정보는이 링크를 확인하십시오. http://msdn.microsoft.com/en-us/library/ms175093.aspx

앞에서 언급했듯이 로그 전달은 백업 전략이 아니지만 재해 복구 상황에서 복원 시간을 크게 줄일 수 있습니다. 주의해야 할 것은 복제 복제가 재난 이전과 같이 작동하려면 복제 게시를 로그 전달 서버에 스크립팅하고 초기화해야한다는 것입니다. 출판물이 크면 생산 수준으로 복원하는 데 걸리는 시간이 크게 늘어날 수 있습니다.

도움이 되었기를 바랍니다,

매트

나는 두 번째 Mladen Prajdic. 이 기사 는 데이터베이스의 복구 모델에 따라 올바른 백업 전략을 선택하는 데 도움이됩니다.

이는 SQL Server의 백업 전략이 아닙니다. 전체 및 차등 백업은 SQL Server 데이터베이스에 수행 할 수있는 백업 유형이며 로그 전달은 예약 된 시간에 서버에서 다른 서버로 로그 백업을 이동하고이 두 데이터베이스를 동기화하여 고 가용성 전략입니다. 백업 한도).

재해 복구 (백업 및 복원 :-))에 대한 유용한 정보는 MSDN에서 찾을 수 있습니다 ( 여기 및 여기) . 즉, 장애 발생시 백업에서 복구 할 수있는 데이터 양을 선택해야합니다. 정상적인 백업 전략 샘플은 매일 전체 백업이고 매 시간마다 로그 백업 (필요에 따라 다름)이므로이 경우 전체 백업 + 모든 일일 로그 백업에서 데이터베이스를 복원 할 수 있습니다.

DR에 대한 또 다른 좋은 참고 자료는 Simple_Talk에서 찾을 수 있습니다 .

물론 데이터베이스를 복원해야 할뿐만 아니라 데이터베이스가 속한 서버 및 응용 프로그램의 컨텍스트에서 복구가 이루어집니다. 아직 사용하지는 않았지만 Data Protection Manager 는 필요한 경우보다 포괄적 인 작업을 수행하려고합니다.

가장 좋은 방법은 세 가지 백업 유형을 모두 사용하는 것입니다. 물론 트랜잭션 로그 백업의 차등 백업을 무시할 수 있습니다. 모든 것은 데이터베이스, 성장 속도, 데이터베이스 및 기타 변경 빈도에 따라 다릅니다. 백업 계획을 선택하기 전에 잃어 버릴 데이터 양을 고려하십시오. 데이터베이스 복구에 얼마나 많은 시간을 할애 할 수 있습니까?

예를 들어, 데이터베이스가 빠르게 증가하는 경우 다음과 같은 SQL Server 백업 전략을 사용할 수 있습니다. 전체 백업-하루에 한 번, 차등 백업-2 시간마다 및 트랜잭션 로그 백업-20 분마다. 이 경우 실패가 발생하면 19 분 이상 작업을 잃게됩니다. 또 다른 예로, 데이터베이스가 느리게 증가하면 하루에 한 번 전체 백업을 수행하고 6 시간마다 차등 백업을 수행하며 매 시간마다 트랜잭션 로그 백업을 수행 할 수 있습니다.

한 가지 더 유용한 팁-데이터베이스를 수시로 안전하게 백업하여 테스트 서버에서 백업을 복원하십시오.