Veeam 13 MSSQL to PostgreSQL DB 마이그레이션 가이드

개요

기존 Veeam Backup & Replication 환경을 오래 운영했다면 Configuration Database가 Microsoft SQL Server에 구성되어 있는 경우가 많습니다.

Veeam 13에서는 PostgreSQL을 기본 데이터베이스로 사용하는 구성이 일반적이고, Windows 기반 VBR에서도 PostgreSQL을 Configuration DB로 사용할 수 있습니다.

여기서 가장 중요한 점은 SQL Server 데이터베이스를 pg_dump 같은 도구로 직접 변환하는 작업이 아니라는 것입니다.

Veeam이 지원하는 방법은 다음 흐름입니다.

현재 Microsoft SQL Configuration DB
        ↓
Veeam Configuration Backup (.BCO)
        ↓
Configuration Restore Wizard
        ↓
Restore Mode = Migrate
        ↓
Target Database = PostgreSQL
        ↓
VBR이 PostgreSQL DB로 다시 연결

이 글은 Windows 기반 Veeam Backup & Replication 13.1.1.18에서 Microsoft SQL Server를 사용 중인 환경을 기준으로 합니다. Veeam Software Appliance는 PostgreSQL 기반이므로 같은 의미의 MSSQL→PostgreSQL 전환 작업 대상과는 다릅니다.

가장 먼저 확인할 지원 규칙

Veeam은 서로 다른 Database Engine 간 Configuration DB 마이그레이션을 동일한 VBR 버전 내에서만 지원합니다.

예를 들어 다음처럼 진행하는 것이 안전합니다.

VBR 13.1.1.18 + MSSQL
          ↓
VBR 13.1.1.18 + PostgreSQL

반대로 Version Upgrade와 Database Engine Migration을 한 번의 작업처럼 묶으면 안 됩니다.

예:

VBR 12.x + MSSQL
          ↓
VBR 13.x + PostgreSQL

이렇게 버전과 DB Engine을 동시에 바꾸는 방식이 아니라, Upgrade 작업과 DB Migration 작업을 별도 단계로 나눠야 합니다.

Veeam 13에서 지원하는 PostgreSQL

현재 VBR 13.1.1.18 Windows Backup Server 요구사항 기준으로 지원되는 PostgreSQL 계열은 다음과 같습니다.

PostgreSQL 17.x

PostgreSQL 15.x

PostgreSQL 14.x

VBR 13 설치 미디어에는 PostgreSQL 17.10이 포함되어 있습니다.

기본 포함 버전이 아닌 PostgreSQL을 사용할 경우에는 DB 엔진을 직접 준비해야 합니다.

PostgreSQL 구성에서 확인할 것

PostgreSQL 기본 Encoding은 UTF-8

표준 System Database인 postgres DB가 존재해야 함

postgres DB 이름을 변경하지 않음

template1 Database가 UTF-8 Encoding이어야 함

VBR Configuration DB 용도의 PostgreSQL Instance는 가급적 다른 서비스와 공유하지 않음

VBR Configuration DB는 AWS RDS 같은 Cloud Database Service에 배치하는 구성을 지원하지 않음

기본 PostgreSQL Port는 다음과 같습니다.

TCP 5432

Remote PostgreSQL을 사용할 경우 Backup Server에서 해당 PostgreSQL Instance까지 방화벽도 확인합니다.

사전 체크리스트

작업 전에 아래 항목부터 정리합니다.

현재 VBR 정확한 Build 확인

현재 Configuration DB가 연결된 SQL Server/Instance 확인

Configuration Backup 저장 Repository 확보

PostgreSQL Target Instance 준비

PostgreSQL UTF-8 설정 확인

Target DB 계정/권한 확인

모든 Backup/Replication/Restore Session 종료

Scheduled Job 비활성화

Configuration Backup 암호 준비

Enterprise Manager 사용 여부 확인

작업 후 Rollback 기준과 기존 SQL DB 보관 기간 결정

1. 실행 중인 Job 정리

Configuration Backup을 만든 시점 이후 새로운 Backup Session이나 Restore Point가 계속 생기면 복원된 Configuration DB와 실제 Repository 상태 사이에 차이가 생길 수 있습니다.

따라서 Migration 직전에는 실행 중인 Job을 모두 종료하고 Scheduled Job을 비활성화합니다.

마이그레이션용 Configuration Backup을 만든 이후부터 PostgreSQL 전환이 끝날 때까지는 새로운 Job을 실행하지 않는 것이 좋습니다.

2. 암호화된 Configuration Backup 생성

Veeam Console에서 다음 메뉴를 엽니다.

Main Menu
  → Configuration Backup

Backup Repository와 보존 개수를 확인한 뒤 Enable configuration backup file encryption을 활성화합니다.

그 다음 Backup now를 실행합니다.

Configuration Backup 파일은 선택한 Repository 아래에 .BCO 형식으로 생성됩니다.

예:

\VeeamConfigBackup\<BackupServer>\*.bco

왜 암호화를 권장할까

Configuration Backup이 암호화되지 않으면 Credential, Encryption Key, Certificate 같은 민감한 정보가 Backup에 저장되지 않습니다.

Migration 후 서버 자격 증명을 다시 입력해야 하는 상황을 줄이려면 암호화된 Configuration Backup을 사용하는 것이 중요합니다.

Password Manager에 Password가 하나라도 등록되어 있는 환경에서는 Configuration Backup 암호화가 필수로 요구될 수 있습니다.

3. PostgreSQL Target 준비

PostgreSQL이 아직 없다면 Veeam 13 설치 미디어에 포함된 지원 버전을 사용할 수 있습니다.

Remote PostgreSQL을 사용할 경우에는 다음을 확인합니다.

Backup Server → PostgreSQL : TCP 5432

Target DB 이름은 기존과 같게 지정할 수도 있고 새로운 이름을 지정할 수도 있습니다.

기존 DB 이름을 지정하면 Restore 과정에서 내용을 덮어쓸 수 있으므로 테스트나 Migration 작업에서는 새 Database Name을 사용하는 편이 롤백과 비교가 쉽습니다.

4. Configuration Restore 시작

Veeam Console에서 다시 Configuration Backup 메뉴로 이동합니다.

Main Menu
  → Configuration Backup
  → Restore

Configuration Restore Wizard가 시작됩니다.

5. Restore Mode에서 Migrate 선택

Restore Mode는 Migrate를 선택합니다.

Restore Mode
  → Migrate

Veeam의 MSSQL→PostgreSQL 공식 Migration 절차에서도 이 방식을 사용합니다.

6. Configuration Backup 선택

앞에서 만든 최신 .BCO 파일을 선택합니다.

암호화 Backup이라면 Configuration Backup 생성 시 사용한 Password를 입력합니다.

Configuration Backup 시점, Backup Server 이름, VBR 버전을 다시 확인한 뒤 진행합니다.

7. Target Database를 PostgreSQL로 지정

Target Database 단계에서 Database Engine을 다음처럼 선택합니다.

Database: PostgreSQL

Instance는 다음 형식으로 입력합니다.

<postgresql-hostname>:<port>

예:

vbrdb01.example.local:5432

Database Name을 지정하고 PostgreSQL 인증 방식을 선택합니다.

존재하는 Target DB를 지정하면 기존 내용이 삭제되고 Configuration Backup의 데이터로 교체될 수 있습니다. 기존 데이터를 보존해야 한다면 새 DB 이름으로 생성하는 것이 좋습니다.

8. Restore Options 확인

Configuration Restore에서 기본 VBR 인프라, Job, Global Setting은 복원됩니다.

필요에 따라 다음 정보도 복원할 수 있습니다.

Backup/Replica Catalog

Session History

같은 DB에 덮어쓰는 경우에는 기존 Database Backup 옵션도 사용할 수 있습니다.

9. Restore 실행

설정을 확인한 뒤 Restore를 실행하면 Veeam Backup & Replication Service가 일시 중지되고 Configuration DB 복원이 진행됩니다.

작업이 완료되면 Veeam Backup & Replication은 새로 지정한 PostgreSQL Configuration Database로 연결합니다.

10. PostgreSQL 리소스 설정 확인

Migration이 끝난 뒤 Target PostgreSQL Instance가 Veeam 권장 리소스 설정으로 구성되어 있는지 확인합니다.

Veeam에서는 필요할 경우 PowerShell의 다음 Cmdlet을 사용해 PostgreSQL Database Server Limit을 조정할 수 있도록 제공합니다.

Get-Help Set-VBRPSQLDatabaseServerLimits -Full

실제 Parameter 값은 VBR Build와 서버 리소스에 맞춰 현재 PowerShell Reference를 확인한 뒤 적용합니다.

11. 마이그레이션 후 확인

DB 연결만 바뀌었다고 작업을 끝내지 말고 아래 항목을 한 번씩 확인합니다.

Veeam Console

Console 정상 접속

Backup Infrastructure 정상 표시

Repository / Proxy 상태

Managed Server Rescan

Job 목록과 설정

Credential 상태

License 상태

Configuration Backup 설정

Backup 데이터

기존 Backup Chain 표시

Repository Rescan 결과

Restore Point 표시

필요 시 간단한 File-Level Restore Test

Job

Migration 직후에는 테스트 대상 Job 하나를 먼저 실행합니다.

Job Start
 → Snapshot/Processing 정상
 → Repository Write 정상
 → Restore Point 생성 확인

이후 문제가 없다면 Scheduled Job을 다시 활성화합니다.

기존 MSSQL DB는 바로 지우지 않기

마이그레이션이 끝났다고 기존 SQL Server DB를 바로 삭제할 필요는 없습니다.

운영 환경에서는 일정 기간 기존 DB를 Offline 또는 Backup 상태로 보관해 Rollback 기준을 확보하는 편이 좋습니다.

다만 PostgreSQL 전환 이후 양쪽 DB를 동시에 운영하면서 Job을 섞어 실행하면 상태가 갈라질 수 있으므로, 실제 Production VBR이 어떤 DB를 바라보는지는 하나로 명확하게 유지해야 합니다.

Enterprise Manager를 사용한다면

여기서 VBR 12와 VBR 13의 차이를 하나 확인해야 합니다.

일부 VBR User Guide 페이지에는 Enterprise Manager와 관리 대상 VBR이 같은 Database Engine을 사용해야 한다는 기존 설명이 남아 있지만, Veeam KB4409에서는 VBR 13부터 이 제한이 제거되었다고 명시하고 있습니다.

즉 VBR 13에서는 Enterprise Manager와 관리 대상 VBR Server가 서로 다른 Database Engine을 사용하는 구성이 가능합니다.

다만 VBR Configuration DB를 PostgreSQL로 마이그레이션한다고 Enterprise Manager DB까지 같이 이동되는 것은 아닙니다. Enterprise Manager의 MSSQL→PostgreSQL 전환은 KB4409의 별도 절차로 진행해야 합니다.

VBR 12.x 환경에서는 Enterprise Manager와 관리 대상 VBR의 DB Engine 일치 조건이 있었으므로, 구버전 환경을 그대로 적용하면 안 됩니다.

자주 실수하는 부분

SQL DB를 직접 Export/Import

지원되는 Migration 방법은 일반 DB 변환 툴이 아니라 Veeam Configuration Backup + Restore/Migrate입니다.

VBR Upgrade와 DB Migration을 동시에 진행

Cross-engine Migration은 동일 VBR Version 내에서 지원됩니다. 버전 변경과 Engine 변경은 분리합니다.

Configuration Backup 암호화 생략

Credential, Encryption Key, Certificate가 빠질 수 있습니다.

Migration 중 Job 실행

Configuration Backup 이후 생성된 Session/Restore Point 정보가 DB와 어긋날 수 있습니다.

Target PostgreSQL Encoding 미확인

template1과 기본 DB Encoding은 UTF-8 요구사항을 확인합니다.

Enterprise Manager DB도 자동으로 바뀐다고 생각

VBR DB와 Enterprise Manager DB는 별개입니다.

제가 작업 계획서를 만든다면

운영 환경에서는 다음 순서로 Change Window를 잡는 편이 좋습니다.

1. VBR Build / SQL DB / Repository 상태 확인
2. PostgreSQL Target 준비
3. Scheduled Job Disable
4. Running Session 종료 확인
5. Encrypted Configuration Backup
6. .BCO 파일 별도 보관
7. Configuration Restore → Migrate
8. Target Database → PostgreSQL
9. Console/Infrastructure/Repository 검증
10. Test Backup 1개 실행
11. Restore Test
12. Scheduled Job Enable
13. Monitoring
14. 기존 MSSQL DB 보관 후 정책에 따라 정리