## VDI 통합: .bak 파일 없이 MS SQL 백업 구축
MS SQL Server의 표준 BACKUP DATABASE 명령어는 로컬 디스크 저장으로 제한됩니다. 외부 백업 시스템과의 통합을 위해 VDI가 필요합니다—SQL Server에서 직접 데이터 스트림을 가로채는 인터페이스입니다. 우리는 "Beresta" 프로젝트에서 VDI 클라이언트를 구현하여 중간 .bak 파일 없이 전체 백업 및 복원 주기를 제공하는 방법을 자세히 설명합니다.
현대 백업 시스템에서 VDI가 필요한 이유
기본 SQL Server 백업 메커니즘인 TO DISK는 외부 데이터 보호 시스템의 요구 사항을 충족하지 못합니다. 작업 수명 주기 관리, 데이터 라우팅, 병렬 처리 또는 객체 스토리지와의 통합이 필요할 때 중간 계층의 필요성이 생깁니다. VDI(Virtual Device Interface)는 이러한 다리 역할을 합니다: SQL Server는 표준 BACKUP 및 RESTORE 명령어를 계속 실행하지만, 물리적 파일 대신 외부 애플리케이션이 관리하는 가상 디바이스와 작업합니다.
VDI 접근 방식의 주요 장점:
- 데이터 스트림에 대한 완전한 제어—클라우드 스토리지나 미디어 서버로 직접 기록
- SQL Server 파일 시스템으로부터의 독립성
- 처리량 향상을 위한 스트라이프 작업 지원
- 오류 처리 및 로깅의 단일 지점
- 스토리지 정책 관리에 대한 기업 백업 시스템 요구 사항 준수
간단한 솔루션과 달리 "Beresta" 프로젝트는 SQL Server와 스토리지 백엔드 간의 완전한 전송 어댑터로서 VDI를 구현하며, 2008부터 2022 버전까지의 호환성을 유지합니다.
VDI 클라이언트 아키텍처: 준비부터 실행까지
구현은 두 가지 논리적 단계로 나뉩니다. 준비 단계에서는 매개변수를 검증하고 ODBC를 통해 SQL Server에 연결하며 작업 세트를 형성합니다. 특히 중요한 점은 프로젝트가 여러 ODBC 드라이버(현재 Driver 17/18 포함)를 지원하여 이종 환경에서의 호환성을 높인다는 것입니다.
실행 중에 VDI 스트림이 활성화됩니다:
- CoInitializeEx를 통한 COM 초기화
- IClientVirtualDeviceSet2 객체 생성
- 가상 디바이스용 GUID 생성
- VDConfig 매개변수 설정(블록 크기, 타임아웃, 버퍼 깊이)
- CreateEx를 통한 디바이스 게시
- VIRTUAL_DEVICE를 지정한 T-SQL 명령어 실행
- 워커 스레드에서의 데이터 처리
중심 구성 요소는 SQL Server와의 교환 로직을 구현하는 transferThreadProc입니다:
while (true) {
VDC_Command* command;
device->GetCommand(&command);
switch (command->dwCommandCode) {
case VDC_Write:
WriteToFile(command->pvBuffer, command->dwByteCount);
break;
case VDC_Read:
ReadFromFile(command->pvBuffer, command->dwByteCount);
break;
case VDC_Flush:
FlushBuffer();
break;
}
device->CompleteCommand(command, S_OK);
}이 루프는 동기적 상호 작용을 보장합니다: SQL Server는 블록 데이터의 생산자 역할을 하고, VDI 클라이언트는 소비자 역할을 하여 데이터를 대상 스토리지로 리디렉션합니다.
병렬 처리 및 성능 관리
단일 스레드 처리는 기업 작업에 병목 현상을 일으킵니다. 프로젝트는 각 스트라이프를 별도 스레드가 처리하는 스트라이프 백업/복원을 통해 이를 해결합니다. --stripes=N 매개변수를 지정하면 다음과 같은 파일이 생성됩니다:
db_full_20260412_101530_s0.bak
db_full_20260412_101530_s1.bak
...이 접근 방식은 세 가지 이점을 제공합니다:
- 디스크나 네트워크 채널 간 I/O 부하 분산
- 처리량의 선형 확장성
- 다중 스트림을 특징으로 하는 산업용 백업 시스템 아키텍처와의 정렬
성능에 영향을 미치는 주요 매개변수:
- blockSize—대상 스토리지에 최적화된 블록 크기
- maxTransferSize—최대 전송 패킷 크기
- buffersPerStripe—스레드당 버퍼 깊이
- vdiTimeoutSec—I/O 작업 타임아웃
이러한 매개변수에 대한 실험을 통해 로컬 SSD부터 느린 네트워크 스토리지까지 특정 인프라 특성에 맞게 솔루션을 조정할 수 있습니다.
전체 백업부터 로그까지의 복원 체인
프로젝트는 차등 백업 및 트랜잭션 로그를 포함한 전체 복원 주기를 지원합니다. 올바른 체인 처리가 매우 중요합니다:
- 차등 백업의 경우 동일 타임스탬프의 최신 전체 백업이 자동 선택됩니다
- 전체 복원은 WITH NORECOVERY로 수행된 후 차등은 WITH RECOVERY로 진행됩니다
- 로그 백업은 FULL/BULK_LOGGED 복구 모델의 데이터베이스에만 허용됩니다
- master 데이터베이스는 차등 작업에서 제외됩니다(SQL Server 제한)
세트 발견 메커니즘은 명명 규칙을 사용합니다:
{db}_{type}_{timestamp}_s{n}.bak디렉터리 스캔 함수는 타임스탬프를 기반으로 복원 체인을 구축합니다. 전체 복원의 경우 최신 세트가 선택되고, 차등의 경우 전체 및 차등 파일이 일치하는 것만 사용됩니다. 스트라이프 수는 파일명에서 가장 높은 sN 인덱스로 결정됩니다.
복원 전에 데이터베이스는 반드시 단일 사용자 모드로 전환됩니다:
ALTER DATABASE [db] SET SINGLE_USER WITH ROLLBACK IMMEDIATE이것은 활성 연결과의 충돌을 방지합니다. 복원이 성공하면 데이터베이스는 MULTI_USER 모드로 복원됩니다.
주요 요약
- VDI는 SQL Server 파일 시스템 의존성을 제거하고 데이터 스트림을 임의의 대상 스토리지로 리디렉션합니다
- 자동 복원 체인 구성과 함께 전체/차등/로그 시나리오 지원
- 스트라이프 아키텍처를 통한 병렬 처리로 선형 처리량 확장성 보장
- 특정 ODBC 드라이버에 묶이지 않고 SQL Server 2008-2022 호환
- SQL Server 특성(예: master 데이터베이스 제한) 고려한 구현
"Beresta" 프로젝트는 상대적으로 간결한 VDI 클라이언트 구현만으로도 기업 백업 시스템의 주요 요구 사항을 충족할 수 있음을 보여줍니다. 오류 처리와 데이터베이스 상태 관리를 포함한 전체 작업 주기에 중점을 둔 덕분에 프로덕션 준비가 완료되었습니다. 아키텍처는 로컬 디스크부터 클라우드 객체 스토리지까지 모든 스토리지 백엔드와의 통합에 열려 있으며, 이는 하이브리드 IT 환경에서 특히 중요합니다.
— Editorial Team
아직 댓글이 없습니다.