복구 경로
차등 백업이나 로그 백업을 사용하는 경우 또는 다음 방법 중 하나로 데이터베이스를 이전 시점으로 복구하는 경우 복구 경로를 이해해야 합니다.
지정 시간 복원 수행
모든 로그 백업이나 가장 최근의 차등 백업을 먼저 복원하지 않고 복구 수행
데이터베이스를 이전 복구 지점으로 복구하고 그 지점부터 새로 데이터베이스를 사용하면 새 복구 경로가 시작됩니다. 복구 경로는 일반적으로 데이터베이스를 사용하거나 특정 데이터 및 로그를 복원하여 데이터베이스를 특정 지정 시간으로 복원하는 데이터 및 로그 백업 시퀀스입니다. 복구 경로는 데이터베이스의 일관성은 계속 유지한 채 시간 경과에 따라 점진적으로 데이터베이스를 변경시키는 특정 변환의 고유 집합으로 구성됩니다. 다음 그림에서는 복구 지점과 결과 복구 경로 간의 관계를 보여 줍니다.
.gif "복구 지점 및 결과 복구 경로")
다음 상황에서는 데이터베이스가 "끝 시점"으로 복원되지 않으므로 새 복구 경로가 생성됩니다. 그 후에는 데이터베이스에 대해 두 개 이상의 복구 경로를 사용할 수 있으며 모두 같은 LSN 범위를 사용하는 백업이 존재하게 됩니다.
전체 데이터베이스 백업을 복원하고 다른 유형의 백업을 사용하지 않고 데이터베이스를 복구하는 경우
가장 최근의 차등 백업이 아닌 다른 차등 백업의 끝에 데이터베이스를 복구하는 경우
전체 데이터베이스 백업 및 차등 데이터베이스 백업을 복원하고 기존의 트랜잭션 로그 백업을 적용하지 않고 데이터베이스를 복구하는 경우
가장 최근의 트랜잭션 로그 백업이 아닌 다른 트랜잭션 로그 백업의 끝에서 데이터베이스를 복구하는 경우
트랜잭션 로그 백업 내의 특정한 시간 또는 표시된 트랜잭션에서 데이터베이스를 복구하는 경우
일반적으로 복구 지점에서 트랜잭션을 롤백할 경우 해당 복구 지점에서 새 복구 경로가 시작됩니다. 이제 기존 백업의 LSN(로그 시퀀스 번호)은 이 복구 지점의 LSN보다 커지며 이러한 백업의 LSN은 현재 복구 작업으로 생성된 새 분기와는 다른 복구 분기에 존재하게 됩니다.
최상의 방법 여러 복구 분기 지점이 있는 복구 경로가 생성되는 것을 방지하려면 데이터베이스를 복구하자마자 전체 데이터 집합의 백업을 수행합니다. 이 방법을 사용하면 모든 백업이 단일 복구 분기에서 수행됩니다. 이를 확인하려면 데이터를 백업한 후 RESTORE HEADERONLY 결과 집합 또는 backupset 테이블의 last_recovery_fork_guid 열을 살펴봅니다.
복구 경로의 예
다음 그림과 같이 처음에는 데이터베이스의 모든 백업이 단일 복구 경로를 구성합니다. 이 그림에서 복구 경로에는 시간 t1에 수행된 데이터베이스 백업과 t2, t3 및 t4에 수행된 로그 백업 3개가 포함됩니다.
.gif "원래 복구 경로")
다음 그림에서는 이전 지정 시간으로 데이터베이스를 복구하여 발생한 복구 분기 지점을 보여 줍니다. 백업 t4의 문제로 인해 데이터베이스 관리자가 t3 로그 백업의 끝에서 데이터베이스를 복구합니다. 이러한 복원으로 인해 복구 분기 지점이 발생합니다. 시간 t5에서 새 로그 백업에서는 새로운 복구 분기인 복구 분기 2를 시작합니다.
.gif "두 번째 복구 분기 생성")
[!참고]
t5 로그 백업에는 이 백업을 복구 분기 1의 t3 로그 백업으로 연결하는 복구 분기 지점 메타데이터가 들어 있습니다. 복구 분기 지점 메타데이터에 대한 자세한 내용은 이 항목의 뒷부분에 나오는 "복구 분기 지점 관리"를 참조하십시오.
앞의 그림에서 보았던 예에서는 새 복구 경로를 만들어 다음 그림에서 보여 줍니다. 새 복구 경로에는 복구 분기 1(t1 - t3)의 일부 백업과 복구 분기 2(t5 - t9)의 모든 로그 백업이 들어 있습니다. 복구 경로의 큐브 뷰에서 로그 백업 t4는 사용되지 않습니다.
.gif "새 복구 경로")
지정 시간 복원 후 다음 백업에서는 항상 복구 분기 지점이 발생합니다. 다음 그림에서 지정 시간 복원은 t4 로그 백업 과정의 중간에서 완료됩니다. 데이터베이스를 해당 지정 시간으로 복구하면 복구 분기 지점이 발생합니다. 로그 백업이 복구된 데이터베이스에서 시간 t5에 생성되면 복구 분기 2가 구성되고 새로운 복구 경로가 생성됩니다. 새 분기의 첫 번째 로그 백업인 t5에는 로그 백업 t3을 대체하고 이와 동일한 첫 번째 LSN이 포함됩니다. 따라서 t3 및 t4 백업은 모두 새 복구 경로에서 사용되지 않습니다.
.gif "지정 시간 복원 이후의 새 복구 경로")
이러한 새 복구 경로에 백업을 복원하기 위한 복원 순서는 t1, t2 및 t5입니다. 이후 백업은 복구 분기 2에서 수행되면 새 복구 경로에 이 백업이 통합됩니다.
이전 경로를 따라 복원 및 롤포워드하려면
일반적으로 여러 복구 경로가 있을 경우 이중 최신 복구 경로가 데이터베이스 복원을 위한 기본 경로가 됩니다. 이전 복구 경로는 사용하지 않는 것이 좋습니다. 그러나 필요한 경우 현재 복구 경로가 생성되기 전에 수행된 백업 시퀀스를 따라 이전 복구 경로를 롤포워드할 수 있습니다. 예를 들어 지정 시간 복구 전에 수행된 백업을 사용하여 이전 경로를 따라 지정 시간 이후 지점에 도달할 수 있습니다.
예를 들어 로그 백업 t5이 생성된 후에도 위의 그림에서 생성된 백업을 기반으로 t1에서 수행된 전체 데이터베이스 백업에서 로그 백업 t4의 끝으로 복원할 수 있습니다. 이것은 이전 복구 경로에 있습니다.
이전 경로에서 새 경로로 복원 및 롤포워드하려면
SQL Server 데이터베이스 엔진은 복원 시퀀스에 서로 양립할 수 없는 백업, 즉 서로 다른 복구 경로를 따라 롤포워드되는 백업이 사용되는 것을 방지합니다. 이 제한으로 복구 후 데이터베이스의 일관성이 유지 관리됩니다.
새 복구 경로를 따라 복원 및 롤포워드하려면 복구 지점 이전의 백업과 복구 지점 이후의 백업에 대해 별개의 복원 시퀀스를 생성합니다.
새 복구 경로를 정의한 복구 전에 수행된 백업을 복원합니다. 이때 복구 지점을 포함하는 백업은 제외합니다.
복구 경로가 생성된 후 수행된 백업을 복원하여 새 복구 경로를 따라 롤포워드합니다.
복구 분기 지점 관리
복구 분기는 동일한 GUID를 공유하는 LSN의 범위입니다. 복구 경로는 시작점(LSN,GUID)에서부터 끝점(LSN,GUID)까지의 범위를 나타냅니다. 복구 경로의 LSN 범위는 하나 이상의 복구 분기의 시작부터 끝 전체에 이를 수 있습니다. 데이터베이스가 만들어질 때 및 RESTORE WITH RECOVERY가 복구 분기 지점을 만들 때 새 복구 분기가 시작됩니다.
복구 분기 지점은 RESTORE WITH RECOVERY가 수행될 때마다 새 복구 분기가 시작되는 지점(LSN,GUID)입니다. 각 복구 분기 지점은 복구 분기 간 부모-자식 관계를 결정합니다.
데이터베이스를 복구하면 다음 LSN을 포함한 전체 데이터베이스 상태가 복구 지점으로 설정됩니다. 그런 다음 fork_point_lsn부터 시작하여 LSN이 다시 사용됩니다. 따라서 복원 시퀀스를 생성하는 경우 동일한 LSN이 둘 이상의 분기 지점에 존재할 수 있으므로 백업은 LSN뿐만 아니라 복구 분기 지점으로 연결되어야 합니다. 다음은 LSN의 재사용을 설명하는 그림으로 여러 다른 복구 분기 지점에서 LSN이 다시 사용되는 방식을 보여 줍니다. 다음 그림에서 녹색 상자는 동일한 LSN을 사용하는 두 개의 백업을 나타냅니다.
.gif "여러 다른 복구 분기에서 LSN이 다시 사용되는 방식")
복원 시퀀스에 복구 분기 지점을 이동하는 백업이 통합되어야 하는 경우 사용한 백업이 올바른 복구 경로를 따라 복구 지점에 도달하도록 복원 시퀀스가 구성되어야 합니다. 이를 위해 백업에는 첫 번째 복구 분기 지점 GUID 및 마지막 복구 분기 지점 GUID가 포함됩니다.
GUID는 복구 경로 추적과 관련된 다른 메타데이터와 함께 backupset 기록 테이블에 저장되고 RESTORE HEADERONLY 문에 의해 반환됩니다. 다음 표에서는 복구 분기 지점을 이동하는 복원 시퀀스 생성과 연관된 메타데이터 값을 요약합니다. 이러한 값의 열 이름이 기록 테이블 및 RESTORE HEADERONLY 문의 결과 집합과 다릅니다.
LSN |
설명 |
backupset 열 이름 |
RESTORE HEADERONLY 열 이름 |
|---|---|---|---|
첫 번째 복구 분기 지점 GUID |
복구 분기 시작 지점의 ID입니다. |
first_recovery_fork_guid |
FirstRecoveryForkID |
마지막 복구 분기 지점 GUID |
복구 분기 끝 지점의 ID입니다. |
last_recovery_fork_guid |
RecoveryForkID |
첫 번째 LSN |
백업 세트에서 첫 번째 또는 가장 오래된 로그 레코드의 로그 시퀀스 번호입니다. |
first_lsn |
FirstLSN |
마지막 LSN |
백업 세트 다음에 오는 로그 레코드의 로그 시퀀스 번호입니다. |
last_lsn |
LastLSN |
분기 지점 LSN |
첫 번째 복구 지점 GUID가 마지막 복구 지점 GUID와 같지 않을 경우 분기 지점의 로그 시퀀스 번호입니다. 그 외의 경우에는 백업에서 복구 분기 지점이 발생하지 않고 분기 지점은 NULL입니다. |
fork_point_lsn |
ForkPointLSN |
차등 기반 GUID |
단일 백업을 기준으로 하는 차등 백업의 경우 값은 차등 기반의 고유 식별자입니다. 여러 백업을 기반으로 하는 차등 백업의 경우 값은 NULL이며 기본 차등 백업은 파일 수준에서 결정해야 합니다. 자세한 내용은 backupfile(Transact-SQL)을 참조하십시오. 비차등 백업 유형의 경우 값은 NULL입니다. |
differential_base_guid |
DifferentialBaseGUID |
이 설명의 나머지 부분은 backupset 기록 테이블에 있는 값의 이름만 사용합니다.
마지막 복구 분기 지점 GUID 및 첫 번째 복구 분기 지점 GUID는 백업을 연결하여 순서가 올바른 분기 지점을 따르도록 하는 데 사용됩니다. 순서의 각 로그 백업을 복원하려면 first_recovery_fork_guid가 순서에 있는 이전 백업의 last_recovery_fork_guid와 같아야 합니다.
.gif "first_recovery_fork_guid가 last_recovery_fork_guid와 같음")
데이터 백업과 차등 백업도 연결해야 합니다.
로그 백업이 전체 데이터베이스 백업이나 차등 데이터베이스 백업의 마지막 LSN과 분기 지점을 모두 포함하는 경우 연결 테스트는 분기 지점을 기반으로 하여 마지막 LSN의 위치에 따라 결정됩니다.
다음은 backupset 값을 사용하는 연결 테스트입니다.
last_lsn이 fork_point_lsn보다 작거나 같을 경우 데이터 백업이나 차등 백업의 last_recovery_fork_guid가 로그 백업의 first_recovery_fork_guid와 같아야 합니다. 다음 그림에서는 last_lsn이 fork_point_lsn보다 작은 경우를 보여 줍니다.
.gif "last_lsn이 fork_point_lsn보다 작음")
last_lsn이 fork_point_lsn보다 클 경우 데이터 백업이나 차등 백업의 last_recovery_fork_guid가 로그 백업의 last_recovery_fork_guid와 같아야 합니다. 다음 그림에서는 last_lsn이 fork_point_lsn보다 큰 경우를 보여 줍니다.
.gif "last_lsn이 fork_point_lsn보다 큼")
차등 백업에서는 backupset.differential_base_guid를 사용하여 차등 기반을 찾습니다.
차등 백업이 다중 기반이고 backupset.differential_base_guid가 NULL인 경우 backupfile.differential_base_guid를 사용하여 파일별로 차등 기반을 결정해야 합니다.