• 아티클

트랜잭션 로그 백업 작업

이 항목에서는 전체 또는 대량 로그 복구 모델을 사용하는 데이터베이스와 관련된 내용을 다룹니다.

이 항목에서는 트랜잭션 로그를 백업 및 복원하거나 적용하는 방법에 대한 개념을 설명합니다. 전체 및 대량 로그 복원 모델에서 데이터를 복구하려면 트랜잭션 로그를 정기적으로 백업(로그 백업)해야 합니다. SQL Server 2005 이상 버전에서는 전체 백업이 실행되는 동안 로그를 백업할 수 있습니다.

첫 번째 로그 백업을 만들기 전에 데이터베이스 백업 또는 파일 백업 집합의 첫 번째 집합과 같은 전체 백업을 만들어야 합니다. 파일 백업만 사용하여 데이터베이스를 복원하면 복잡해질 수 있습니다. 따라서 가능하면 처음에 전체 데이터베이스 백업을 수행하는 것이 좋습니다. 그런 후에 트랜잭션 로그를 정기적으로 백업할 수 있습니다. 이렇게 하면 작업 손실 위험이 최소화될 뿐만 아니라 트랜잭션 로그가 잘립니다. 일반적으로 기존 로그 백업 후에도 트랜잭션 로그가 잘리지만 로그 잘림이 지연될 수 있습니다. 자세한 내용은 로그 잘림을 지연시킬 수 있는 요소를 참조하십시오.

비즈니스 요구 사항, 특히 손상된 로그 드라이브에 의해 발생될 수 있는 작업 손실에 대한 허용 범위를 지원하기 위해 로그 백업을 충분히 자주 수행하는 것이 좋습니다. 로그 백업의 적절한 수행 빈도는 저장 및 관리는 물론 복원까지 가능할 수 있는 로그 백업의 횟수에 의해 조정되는 작업 손실 위험에 대한 허용 범위에 따라 달라집니다. 로그 백업에 걸리는 시간은 매 15분에서 30분이면 충분합니다. 비즈니스에서 작업 손실 위험을 최소화하려는 경우에는 로그 백업을 더 자주 수행해야 합니다. 로그 백업 횟수가 많아지면 로그 잘림이 더 자주 발생하여 로그 파일의 크기가 작아지는 이점이 있습니다.

복원해야 하는 로그 백업의 수를 제한하려면 데이터를 정기적으로 백업해야 합니다. 예를 들어 주별 전체 데이터베이스 백업과 일별 차등 데이터베이스 백업을 예약할 수 있습니다.

[!참고]

기본적으로 백업 작업을 성공적으로 수행할 때마다 SQL Server 오류 로그와 시스템 이벤트 로그에 항목이 추가됩니다. 로그를 자주 백업하는 경우 이러한 성공 메시지는 바로 누적되므로 엄청난 오류 로그가 쌓여 다른 메시지를 찾기 힘들 수 있습니다. 이 경우 스크립트가 이러한 로그 항목에 종속되지 않을 경우 추적 플래그 3226을 사용하여 이러한 항목을 표시하지 않을 수 있습니다. 자세한 내용은 추적 플래그(Transact-SQL)를 참조하십시오.

로그 체인

로그 백업의 연속된 시퀀스를 로그 체인이라고 합니다. 로그 체인은 데이터베이스의 전체 백업으로 시작합니다. 일반적으로 데이터베이스를 처음 백업할 때나 단순 복구 모델에서 전체 또는 대량 로그 복구 모델로 전환한 후에만 새 로그 체인이 시작됩니다.

전체 데이터베이스 백업을 만들 때 기존 백업 집합을 덮어쓰도록 선택하지 않으면 기존 로그 체인이 그대로 유지됩니다. 로그 체인이 그대로 유지되면 미디어 세트의 전체 데이터베이스 백업에서 데이터베이스를 복원한 후 모든 후속 로그 백업을 복구 지점까지 복원할 수 있습니다. 복구 지점은 마지막 로그 백업의 끝이나 로그 백업의 특정 복구 지점일 수 있습니다.

데이터베이스를 오류 발생 시점까지 복원하려면 로그 체인이 온전해야 합니다. 즉 트랜잭션 로그 백업의 연속적인 시퀀스가 오류 발생 지점까지 이어져야 합니다. 이 로그 시퀀스가 시작되는 위치는 복원 중인 데이터 백업의 유형인 데이터베이스, 부분 또는 파일에 따라 달라집니다. 데이터베이스 또는 부분 백업의 경우 로그 백업의 시퀀스는 데이터베이스 또는 부분 백업의 끝 지점에서 이어져야 합니다. 파일 백업 집합의 경우 로그 백업의 시퀀스는 전체 파일 백업 집합의 시작 지점에서 이어져야 합니다.

파일 백업만 사용하는 경우에는 첫 번째 전체 파일 백업의 시작 부분에서 로그를 백업해야 합니다. 첫 번째 전체 파일 백업 후 바로 로그 백업을 수행할 수 있습니다. 첫 번째 로그 백업에 시간이 오래 걸릴 수 있으므로 바로 시작하는 것이 좋습니다. 로그가 백업되는 동안 다른 파일을 백업합니다. 파일 백업에서만 데이터베이스를 복원하려면 전체 파일 백업 집합은 첫 번째 파일 백업과 마지막 파일 백업 간 간격을 포함하는 하나 이상의 로그 백업으로 보강되어야 합니다.

[!참고]

백업 집합에서 로그 체인을 시작하는 백업을 식별하려면 backupset 테이블의 begins_log_chain 열을 쿼리하거나 백업 장치에서 RESTORE HEADERONLY를 실행하여 결과 집합에서 BeginsLogChain 열을 확인합니다.

정기적으로 트랜잭션 로그 백업을 수행해야 합니다. 백업 트랜잭션을 복원할 수 있도록 해 주는 것은 물론 로그 백업에서 로그를 잘라 로그 파일에서 백업된 로그 레코드를 제거합니다. 로그를 자주 백업하지 않으면 로그 파일이 가득 찰 수 있습니다. 전체 트랜잭션 로그를 처리하는 방법은 꽉 찬 트랜잭션 로그 문제 해결(오류 9002)을 참조하십시오.

중요 정보중요

로그 백업이 누락되었거나 손상된 경우 전체 또는 차등 데이터베이스 백업을 만든 다음 트랜잭션 로그를 백업하여 새 로그 체인을 시작하십시오. 누락된 로그 백업보다 앞선 트랜잭션 로그 백업 내의 지정 시간으로 데이터베이스를 복원하려는 경우 트랜잭션 로그 백업을 유지하는 것이 좋습니다. 백업을 보호하는 방법은 백업 및 복원에 대한 보안 고려 사항을 참조하십시오.

로그 백업을 만드는 방법은 트랜잭션 로그 백업 만들기 및 비상 로그 백업을 참조하십시오.

로그 백업의 사용 방법

로그 백업을 복원하면 현재 데이터베이스를 로그 백업 작업이 시작된 시점의 데이터베이스 상태와 정확히 일치하도록 다시 만들기 위해 트랜잭션 로그에 기록된 변경 내용을 롤포워드합니다. 데이터베이스를 복원하는 경우 복원하는 전체 데이터베이스 백업 이후 또는 복원하는 첫 번째 파일 백업의 시작 부분에서 만든 로그 백업을 복원해야 합니다. 일반적으로 가장 최근의 데이터나 차등 백업을 복원하고 나면 복구 지점에 이를 때까지 일련의 로그 백업을 복원한 다음 데이터베이스를 복구해야 합니다. 이때까지 완료되지 않은 트랜잭션은 모두 롤백되며 복구가 완료되면 데이터베이스는 온라인 상태가 됩니다. 데이터베이스가 복구된 후에는 더 이상의 백업을 복원할 수 없습니다.

중요 정보중요

오프라인 복원이나 오류가 발생한 후의 작업 손실을 방지하려면 비상 로그 백업을 수행하여 아직 백업되지 않은 모든 로그 레코드를 캡처하는 것이 좋습니다. 자세한 내용은 비상 로그 백업을 참조하십시오.

트랜잭션 로그 백업 적용.