25.2. 파일 시스템 기반 백업

백업 하는 다른 방법으로 PostgreSQL에서 사용하는 데이터 저장 공간 전체를 직접 파일 복사하는 식으로 파일 시스템 차원에서 처리하는 방식이 있다. 해당 파일의 위치는 18.2절에서 자세히 설명하고 있다. 운영체제에서 파일 시스템 백업하는 것과 크게 틀리지 않다. 예를 들면:

tar -cf backup.tar /usr/local/pgsql/data

위와 같은 명령으로 백업 할 수 있다. 하지만, 이 방식에는 다음 두 가지 한계가 있어, 오히려, pg_dump 명령을 사용하는 것보다 실용적인 측면에서 별 도움이 안된다.

1. 정상적인 백업 작업을 하려면, 반드시 데이터베이스 서버를 중지해야한다. 모든 클라이언트의 접속을 막고 파일 시스템을 복사하는 방식도 안전한 백업을 보장하지 않는다. (tar 명령어나, 기타 이 비슷한 도구들 모두, 파일 시스템의 단위적(atomic) 스냅샷을 지원하지 않으며, 서버에서 사용하는 내부적인 버퍼링에 대한 정보를 정확하게 반영할 수 없기 때문이다.) 서버를 중지하는 방법은 18.5절에서 다룬다. 또한 마찬가지로 복원 할 때는 반드시 서버는 중지된 상태여야한다.

2. 만일 데이터베이스에서 사용하는 각종 파일들의 위치와, 용도를 잘 알고 있어, 개별 데이터베이스나, 테이블에 해당하는 파일들만 복사해서 사용할 수 있을 것이다는 생각을 할 수도 있으나, 그렇게 한다고 해도, 커밋 로그 파일 없이는 정상으로 작동하지 않을 것이다. pg_clog/* 파일들이 모든 트랜잭션의 커밋 상태를 보관하고 있다. 이 로그 파일들은 테이블 단위가 아니라, 데이터베이스 크러스터 단위로 처리되기 때문에, 개별 테이블의 물리적인 파일과, 로그 파일을 복사한다고 해도, 다른 테이블과 관계될 가능성이 있어, 부분 백업은 불가능하다.

파일 시스템 기반 백업에서 또 하나 고려해야할 사항은 파일 시스템이 "완전한 스냅샷(consistent snapshot)" 기능을 제공한다면, (그리고, 이 기능이 신뢰성이 있다면) 이 기능을 사용할 때 주의 해야한다는 점이다. 이 파일 시스템 스냅샷 기능을 이용한 전형적인 백업 방법은 먼저 "현 시점 스냅샷 frozen snapshot"을 만들고, 백업 장치로 모든 데이터 클러스터 모든 파일(위에서 언급했듯이, 부분 파일을 백업하는 것은 의미가 없다)을 복사하고, 잠긴 스냅샷을 푸는 방식으로 진행된다. 파일 시스템이 이런 방식의 기능을 제공한다면, 데이터베이스 서버가 운영 중일 때도 백업이 가능하다. 이 때, 운영 중 상태에서 백업을 받았기 때문에, 이 백업본으로 서버를 실행하려고 하며, 먼저 이전 실행 상태를 보관하고 있는 파일들을 정리해야하며, WAL 로그 정리 작업에 문제가 생길 수 있다. 하지만, 백업 시작 전에, CHECKPOINT 명령을 실행했고, 백업 작업 중간에 생긴 WAL 로그들을 따로 보관하고 있다면, 별 문제 없이 실행할 수 있다. (물론 WAL 로그를 무시 할 수도 있다.)

문제는 데이터베이스 서버가 여러 파일 시스템을 쓰는 경우다. 가령 예를 들어서 테이블스페이스를 만들고, 그 테이블스페이스가 다른 파티션을 사용한다면, 데이터베이스 서버가 사용하는 모든 파일 시스템에 대해서 동시에 "현 시점 스냅샷 frozen snapshot"을 만들 수 있어야한다. 이 방식으로 백업을 하려면, 먼저 파일 시스템 관련 문서를 세심하게 읽고, 타당성을 따져 본 후 작업하길 바란다.

동시에 여러 파일 시스템 스냅샷을 만들 수 없다면, 스냅샷을 만드는 동안 데이터베이스 서버를 중지해야한다. 또 다른 방법으로 아카이브 모드 백업(25.3.2절)과, 그 복구(25.3.4절) 방식을 이용해야한다. 자세한 이야기는 다음 절과, 앞 사용설명서를 참조하라.

다른 한 방법은 rsync 응용 프로그램을 이용하는 방법이다. 작업은 두 단계로 진행 된다. 먼저 서버가 실행 중 일 때, 자료를 모두 동기화 하고, (이때, rsync --checksum 명령을 사용한다. --checksum 옵션이 빠지면, 파일 변경 시간 기준으로 변경 사항을 검사하기 때문에 동기화 작업이 완벽하지 않을 수 있다.) 다음 서버를 중지하고, 한 번 더 동기화를 한다. (이 때도 --checksum 옵션을 포함해야 한다) 이렇게 하면, 서버 중지 되면서 변경 된 파일만 동기화를 하기 때문에, 서버 중지 시간을 최소화 할 수 있다.

파일 시스템 백업은 SQL 덤프 보다 일반적으로 많은 백업 공간이 필요하다. (pg_dump 명령으로 만들어진 덤프 파일에는 인덱스와 같이 물리적으로 없고, 인덱스를 만드는 명령어만 들어있는 몇몇 명령어들이 있기 때문이다.) 이 때문에, 복원 작업에 걸리는 시간은 파일 시스템 백업이 훨씬 빠르다.