현재 산업계에는 데이터베이스 미러링, 클러스터링, 복제 솔루션을 포함하여 여러 디지털 재해 복구(Disaster Recovery, DR) 기술들이 존재합니다. 그러나 로그 전송(Log Shipping)은 보다 간단하고 구성 및 유지 관리가 용이한 방법입니다. 이 문서에서는 로그 전송을 통한 SQL Server 재해 복구 절차에 대해 설명하겠습니다.
로그 전송을 통한 재해 복구 솔루션
로그 전송은 주로 보조 서버에 백업을 유지하고 필요시 주 서버 역할을 대체함으로써 전체 데이터베이스 가용성을 향상시킵니다. 즉, 재해로 인해 주 데이터베이스를 사용할 수 없게 되면 수동으로 보조 데이터베이스를 온라인 상태로 전환하여 서비스를 계속 제공할 수 있습니다.
데이터베이스에 대해 로그 전달을 구성하려면 SQL Server에서 다음 세 개의 에이전트 작업을 만들어 백업, 복사 및 복원 작업을 자동화합니다:
첫 번째 작업은 기본 인스턴스에서 실행됩니다. 이 작업은 기본 데이터베이스에서 트랜잭션 로그를 백업합니다.
두 번째 작업은 보조 서버에서 실행됩니다. 이 작업은 기본 서버에서 보조 서버로 로그 백업을 복사합니다.
세 번째 작업은 보조 서버에서 실행되며, 로그 백업을 복원하고 보조 데이터베이스의 로그 항목을 업데이트합니다.
SQL Server에서 로그 전달 구성 전 고려사항
로그 전달을 구성하는 것은 어렵지 않지만, 구현 전에 몇 가지 고려해야 할 사항들이 있습니다:
데이터베이스 수준 보호: 재해 발생 시 소규모 데이터베이스만 보호할 필요가 있다면 이 수준으로 충분합니다. 그러나 SQL Server 인스턴스 수준에서 여러 데이터베이스를 보존하려는 경우 독립적인 로그 전달 솔루션은 부적합합니다.
보조 서버에서 수동 장애 조치: 로그 전달만으로는 기본 서버에서 보조 서버로 자동 장애 조치할 수 없습니다. 사용자는 보조 데이터베이스를 수동으로 온라인 상태로 전환해야 합니다.
수동 SQL 로그인 구성: SQL 로그인은 기본 서버에서 보조 서버로 자동으로 전송되지 않습니다. 로그인 정보를 기본 서버 인스턴스에서 보조 서버 인스턴스로 전송하여 로그인 정보를 동기화시켜야 합니다. 또한, 보조 서버에서 다양한 유지 관리 계획 및 연결된 서버, SSIS(SQL Server Integration Services) 패키지를 수동으로 생성해 주어야 하는 경우가 많습니다.
데이터 손실 위험: 일반적으로 기본 데이터베이스를 사용할 수 없게 되면 마지막 트랜잭션 로그 백업만 복원할 수 있습니다. 이는 마지막 로그 백업이 보조 서버에 전송된 이후에 발생한 모든 트랜잭션은 손실된다는 것을 의미합니다. 예를 들어, 기본 서버가 오전 9시에 실패하고, 보조 서버 인스턴스 B에 복사된 마지막 백업이 오전 8시 45분이었다면, 오전 8시 45분부터 오전 9시까지의 모든 데이터가 손실됩니다.
역방향 로그 전송: 전체 데이터베이스 백업을 수행하지 않고 서버 역할을 전환할 때 유용합니다. 예를 들어, 대용량 백업 상태에서 보조 서버의 데이터를 원격 주 서버로 전송해야 할 경우 전체 백업을 복사하는 데 오랜 시간이 걸릴 수 있습니다.
로그 전달을 구성하고 사용하는 방법은 무엇입니까?
일반적으로 로그 전달을 구성하는 과정은 두 가지 별개의 단계로 나눌 수 있습니다:
단계 1 – 보조 서버에서 데이터베이스 초기화
기본 서버 인스턴스에 두 개의 데이터베이스가 있다고 가정하고, TestDB1에 대한 로그를 초기에는 데이터베이스가 없는 보조 서버로 전송(log shipping)해야 한다고 해보자. 로그 전송을 설정하려면 데이터베이스가 FULL 또는 BULK-LOGGED 복구 모드여야 한다는 점에 주의하는 것이 중요하다. 데이터베이스가 SIMPLE 복구 모드인 경우, 트랜잭션 로그 백업을 사용할 수 없기 때문에 로그 전송이 실패한다.
1. 먼저 전체 데이터베이스 백업과 트랜잭션 로그 백업을 수행해야 합니다. "전체" 및 "트랜잭션 로그" 백업을 생성하려면 다음 T-SQL 쿼리를 실행할 수 있습니다:
backup database TestDB1 to disk = 'c:\backup\TestDB1.bak'
backup log TestDB1 to disk = 'c:\backup\TestDB1.bak'
2. 다음으로 보조 서버에서 백업을 복원하십시오.
3. 데이터베이스 복원 인터페이스에서 데이터 소스로 장치를 선택하고 해당 아이콘을 클릭합니다.
4. 백업 장치 선택 대화 상자에서 추가를 클릭하십시오.
5. 복원할 백업 파일을 선택하고 확인을 클릭하십시오.
6. TestDB1 백업의 복원을 실행합니다.
7. 페이지 선택을 클릭하고 필요시 파일로 이동하여 물리적 데이터베이스 파일 위치를 수정하십시오.
8. 그런 다음 왼쪽에서 옵션을 클릭합니다. 옵션 페이지에서 복구 상태 드롭다운 목록에서 대기 상태로 복원을 선택하십시오. 대기 상태로 복원 옵션을 선택하면 데이터베이스가 읽기 전용 상태로 유지된다는 점에 유의하십시오. 복구 없이 복원을 선택할 경우 데이터베이스에 접근할 수 없게 됩니다.
9. 적절한 복구 상태를 선택한 후 성공적인 복원을 위해 OK를 클릭하십시오. 그러면 보조 서버 인스턴스에 테스트DB1이 스탠바이(읽기 전용) 모드로 복원됩니다.
이 시점에서 데이터베이스가 보조 서버에서 성공적으로 초기화되었습니다.
단계 2 – 기본 데이터베이스 활성화
1. 기본 서버 인스턴스에서 TestDB1을 마우스 오른쪽 버튼으로 클릭하고 속성을 클릭합니다.
2. 로그 전달 구성에서 이 항목을 기본 데이터베이스로 사용하도록 설정하려면 이 옵션을 사용하도록 설정을 선택하십시오.
기본적으로 트랜잭션 로그는 15분 간격으로 백업됩니다. 그러나 경우에 따라 트랜잭션 로그가 너무 커져서 미리 정의된 시간 내에 복사 및 복원할 수 없는 경우가 있을 수 있습니다. 이를 해결하기 위해 추가 로그 백업 일정을 설정해야 합니다. 백업 설정을 클릭하고 트랜잭션 로그 백업 설정 화면에서 백업 파일 위치를 지정한 후 일정 설정을 클릭하고 백업 빈도를 1~2분 간격으로 변경하십시오.
3. 추가를 클릭하여 보조 데이터베이스를 설정하십시오. 시스템이 보조 서버 인스턴스에 연결하라는 메시지를 표시합니다.
4. 1단계에서 구성한 대로 보조 데이터베이스 설정 인터페이스에서 아니오, 보조 데이터베이스가 초기화되었습니다.를 선택합니다.
5. 보조 서버의 백업 폴더 위치를 지정하고, 백업 빈도를 설정한 후 확인을 클릭하여 파일 복사로 진행합니다.
6. 트랜잭션 로그 복원 인터페이스에서 데이터베이스 상태를 대기 모드로 설정하고 백업 복원 시 데이터베이스의 사용자 연결 끊기를 선택합니다. 백업 간격을 설정한 후 [확인]을 클릭합니다.
7. 보조 서버 인스턴스 및 데이터베이스를 추가하려면 확인 을 클릭하여 SQL Server 에이전트 작업을 만드세요.
기본 서버의 SQL Server 에이전트에서 트랜잭션 로그 백업 작업을 찾을 수 있습니다.
보조 서버의 SQL Server 에이전트 아래에서 새로 생성된 두 개의 작업을 찾을 수 있습니다: 하나는 기본 데이터베이스에서 트랜잭션 로그 백업을 복사하는 것이고, 다른 하나는 보조 데이터베이스에 트랜잭션 로그 백업을 복원하는 것입니다.
8. 이 시점에서 로그 전송을 통한 재해 복구 솔루션이 완전히 구성됩니다. 만약 기본 데이터베이스에 장애가 발생하면 즉시 보조 데이터베이스를 온라인 상태로 전환할 수 있습니다. 또한 다음 쿼리를 실행하여 보조 데이터베이스가 대기 모드에서 정상적으로 벗어났는지 확인할 수 있습니다:
Select * from Products
RESTORE DATABASE TestDB1 WITH RECOVERY
9. 데이터베이스를 새로 고침하면 보조 서버의 TestDB1이 이제 온라인 상태임을 확인할 수 있습니다.
SQL Server를 위한 보다 포괄적인 데이터 보호 전략
로그 전송과 같은 재해 복구 솔루션을 구현하는 동안 기업은 종종 보다 포괄적이고 효율적인 데이터 보호 전략를 요구합니다. Vinchin Backup & Recovery 는 SQL Server와 같은 VM 및 데이터베이스를 대상으로 설계된 자동 백업 및 복구 솔루션을 제공하며, 전체, 증분 및 차등 백업을 지원합니다. 내장된 중복 데이터 제거 및 압축 기술을 통해 저장소 사용량과 백업 시간을 크게 줄일 수 있습니다.
Vinchin의 백업 솔루션은 복잡한 수동 개입을 불필요하게 하여 데이터베이스의 자동 보호 기능을 가능하게 하며, 크로스 플랫폼 마이그레이션 및 클라우드 스토리지 지원을 함께 제공합니다. SQL Server 장애 발생 시 Vinchin은 관리자가 데이터베이스를 신속하게 복구할 수 있도록 도와 데이터 손실과 장기간의 다운타임을 방지함으로써 기업에 보다 포괄적인 재해 복구 보장을 제공합니다.
SQL Server 데이터베이스 백업 작업을 생성하려면 물리적 백업 > 데이터베이스 백업 > 백업 페이지로 이동하십시오:
1. 백업해야 할 데이터베이스를 선택하십시오.
2. 백업 데이터를 처리하고 저장할 백업 노드를 선택하십시오.
3. 필요에 따라 백업 전략을 구성하십시오.
4. 설정을 검토하고 확인하십시오.
효율적이고 신뢰할 수 있는 데이터 백업 및 복구 솔루션을 경험해 보려면 아래 버튼을 클릭하여 Vinchin의 60일 무료 체험을 시작하십시오!
SQL Server 디자스터 복구 FAQ
1. 고가용성(HA)과 디자스터 복구(DR)의 차이점은 무엇인가요?
HA는 장애 조치 클러스터링, Always On 가용성 그룹 또는 데이터베이스 미러링을 사용하여 다운타임을 최소화하는 반면, DR은 사이트 외부 백업 또는 보조 데이터 센터를 활용하여 대규모 장애 발생 후 서비스 복구에 중점을 둡니다.
2. SQL Server 장애 조치 클러스터 인스턴스(FCI)란 무엇이며, DR에 어떻게 도움이 되나요?
FCI는 SQL Server 인스턴스 수준에서 자동 장애 조치(failover)를 제공하기 위해 Windows Server 장애 조치 클러스터링(WSFC)을 사용하는 고가용성 솔루션입니다. 공유 스토리지(SAN, Storage Spaces Direct 또는 클라우드 기반 솔루션)가 필요합니다. 사이트 전체의 장애를 방지하지 않기 때문에 단독으로는 재해 복구(DR) 솔루션이 되지 않지만, 온프레미스 환경에서는 고가용성에 이상적인 솔루션입니다.
결론
로그 전달은 SQL Server를 위한 경제적이고 효율적이며 간단한 재해 복구 솔루션입니다. 이는 데이터베이스 수준의 재해 복구에 이상적인 선택입니다. 그러나 인스턴스 수준의 재해 복구의 경우 데이터베이스 미러링 또는 장애 조치 클러스터링과 같은 다른 재해 복구 기술을 고려해야 합니다. 또한 로그 전달은 데이터 손실을 초래할 수 있습니다. 손상된 SQL 데이터베이스에서 삭제되거나 액세스할 수 없는 데이터를 복구해야 할 경우 전문 SQL 복구 도구를 사용하는 것을 고려하십시오.
