좋은 SQL Server 백업 일정은 무엇입니까?

백업 작업 설정 프로세스에 관한 많은 정보가 있지만 데이터베이스 백업의 큰 그림보기에 대한 정보는 많지 않습니다. 적어도 해당 정보를 제공하는 검색 엔진 쿼리를 작성하는 것은 어렵습니다. 세 가지 유형의 백업이 있다는 것을 알고 있습니다.

• 전체 데이터베이스 백업
• 차등 데이터베이스 백업
• 트랜잭션 로그 백업

세 가지를 모두 사용해야한다고 생각합니다. 이게 말이되는 일정인가요?

• 매월 1 일 - 전체 데이터베이스 백업을 수행하십시오.
• 매일 자정에 - 차등 데이터베이스 백업을 수행하십시오.
• 15 분마다 - 트랜잭션 로그 백업을 수행하십시오.

이렇게하면 12 일에 데이터베이스에 장애가 발생하면 1 일부터 전체 데이터베이스 백업을 복원하고 1 일부터 12 일까지 12 번의 차등 백업을 수행 한 다음 마지막으로 최신 트랜잭션 로그를 복원합니다 ( 트랜잭션 로그 차이?).

마지막으로, 전체 데이터베이스 백업은 독립적입니까? 즉, 2 월 1 일에 전체 데이터베이스 백업을 수행 한 후 1 월부터 모든 파일을 삭제할 수 있습니까? 물론, 나는 만일을 대비하여 몇 달 전에 몇 세트를 유지했지만 질문은 개념적입니다.

SQL Server의 모든 것과 마찬가지로 의존합니다.

가장 먼저해야 할 일은 각 백업 유형이 무엇을 이해하는지 확인하는 것입니다.

온라인 설명서에는 모든 끈적 끈적한 세부 사항 이 있지만 여기에 요약이 있습니다.

전체 백업에는 데이터베이스 내의 모든 것이 포함됩니다. 차등 백업은 누적 백업이 아닙니다. 예를 들어, 12 일에 데이터베이스가 실패한 경우 1 일부터 전체 백업을 복원 한 다음 12 일에 가장 최근의 차등 만 복원 한 다음 모든 트랜잭션 로그 백업이 실패까지 복구하면됩니다. TRANSACTION LOG 백업은 전체 또는 대량 로그 복구 모델을 사용하는 데이터베이스에만 필요합니다. 단순 복구 모델을 사용하는 경우 트랜잭션 로그 백업이 필요하지 않습니다.

백업 일정을 설계하는 것은 실제로 복구해야하는 데이터의 양과 기저귀 발생시 복구해야하는 속도에 달려 있습니다. 매일 전체 백업으로 시작하는 것이 좋습니다. 나중에 언제든지 주파수를 줄일 수 있습니다. 차등 백업은 마지막 전체 이후 누적 누적되므로 데이터베이스에서 진행되는 양의 변화에 ​​따라 며칠 후 차등이 전체 백업보다 클 수 있습니다. 매일 전체 백업을 수행하는 경우 차이를 전혀 사용할 필요가 없습니다. 그러나 여전히 하루에 한 번 정오에 정할 수 있습니다. 트랜잭션 로그 백업은 로그 만 백업합니다. 로그 백업 빈도에 따라 장애 발생시 손실 될 데이터 양이 결정됩니다. 15 분마다 로그 백업을 실행하면 그런 다음 변경된 마지막 15 분 동안 데이터가 손실 될 것으로 예상합니다. 15 분은 좋은 빈도이지만 30 분마다 내 환경에 완벽하게 작동합니다.

앞서 말했듯이, 그것은 모두 환경에 달려 있습니다. 백업 일정을 설계하고 설정 한 후에는 다른 서버에서 테스트 일정을 테스트해야합니다. 전체 백업, diff 및 로그 백업 복원을 연습하여 설계 한대로 모든 것이 작동하는지 알 수 있습니다.

유지 관리 계획을 사용하려는 경우 온라인 설명서에 유용한 정보가 있지만 유연성을 원한다면 Ola Hallengren의 백업 스크립트 를 확인하십시오 .