PostgreSQL Log Backup - WAL (Write Ahead Logging)

어떤 목적으로 DB를 운영한다 하더라도 DB 관리자 입장에서 백업은 항상 최우선이다.

다른 것은 다 용서해도 백업을 못한 것은 용서받기 힘들다.

백업은 복구를 위한 것으로 언제 발생할 지 모르는 장애를 위한 것이다.

장애가 발생한 직전 순간까지 최대한 복구를 하고자면 정교한 백업 복구 전략이 필요하다.

내가 아는 DBMS들은 대부분 백업은 크게 전체, 증분 혹은 차등, 로그 백업 3가지 종류를 지원한다.

단순한 백업 복구 정책이라면 증분 혹은 차등 백업은 생략하고 전체, 로그 백업 2가지로 백업 복구 전략을 수립한다.

백업 복구 정책의 결정 및 수립은 해당 시스템의 서비스레벨과 환경, 비용등을 고려하여 결정한다.

PostgreSQL을 사용하기 앞서 가장 두려운 것은 로그 백업이 되는가? 백업된 로그로 복구가 가능한 것인가? 에 대한 걱정이었다.

다행히도 로그 백업과 유사한 개념의 백업을 8.0 이상에서 지원하는 듯 하다. 현재 9.0.2 가 릴리즈 되었으므로 당연히 지원될 것으로 생각되어 테스트를 수행했다.

PostgreSQL은 전체 백업을 file copy 수준으로 하기 때문에 전체 백업 시점을 지정해 주어야 전체 백업이 언제 되었다는 것을 관리자가 직접 파악하고 해당 이후부터 로그를 리플레이하는 방식을 취하는 것 같다.

메뉴얼을 정독하지 않았기 때문에 해당 내용은 더 확인이 필요할 듯 하다.

대충... 개념은 설정->전체백업 표시->전체백업->전체백업 표시 중단 의 순서로 이루어진다.

설정할 부분은 postgresql.conf 에서 PostgreSQL 시작 parameter의 값을 기본값에서 변경을 해주어야 한다.

wal_level = archive

archive_mode = on

archive_command = '/bin/cp -i %p [log backup path]%f > [log backup result log]'

로그 백업을 위해 설정해 주어야 할 부분은 위의 3가지 정도 이다.

참고로 로그 백업이 될 위치를 결정해 주는 부분이 archive_command 인데... CentOS에서는 의도대로 동작했지만, Windows에 설치된 PostgreSQL은 원하는 위치로 로그 백업이 되지 않았다.(당연히 로그백업 자체는 동작했다. 설정을 잘못했는지 알 수 없었지만... 메뉴얼에 모든 플렛폼에서 동작하는 것을 기대하지 말라고 해서 더 확인해 보기도 찜찜하다.)

아직 복구까지 테스트가 끝난것이 아지만, 로그 백업이 이루어지는 결과(로그가 파일로 생성되는 것)를 확인 할 수 있었다.