| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 23. 백업과 복원 | Fast Forward | Next |
백업 전략의 대체안으로서PostgreSQL가 데이터베이스 내의 데이터를 보존하기 위해 사용하고 있는 파일을 직접 카피하는 방법이 있습니다. Section 16.2에 이러한 파일이 어디에 있는지 설명되고 있지만, 이 방법에 흥미가 있는 분은 이미 알고 있을 것입니다. 아래와 같은 보통의 파일 시스템 백업을 실시하기 위한 어떤 방법이라도 사용 가능합니다.
tar -cf backup.tar /usr/local/pgsql/data
그러나 이 방법에는 너무 실용적이지 않다거나, 적어도pg_dump보다 뒤떨어진다고 하는 2개의 제약이 있습니다.
유효한 백업을 실시하려면 데이터베이스 서버를 반드시 정지해야 합니다. 모든 접속을 무효로 할 만한 어중간한 대책에서는 작동하지 않습니다 (tar나 그 유사 툴은 어떤 시점에 있어서의 파일 시스템의 미세한 스냅샷을 취하지 않는 것이 주요 이유 입니다.) 서버의 정지에 관해서는 Section 16.5을 참조해 주십시요. 데이터를 복원 하기 전에도 서버를 정지시킬 필요가 있다는 것은 말할 것도 없습니다.
데이터베이스의 파일 시스템 레이아웃를 상세히 숙지하고 있는 경우, 개별의 테이블이나 데이터베이스를 각각의 파일이나 디렉토리로부터 백업 하거나 복원을 시도하려고 했었을지도 모릅니다. 그러나 그러한 파일은 반 정도의 정보 밖에 보유하고 있지 않고, 이 방법에서는 정상적인 백업은 실시할 수 없습니다 . 다른 반의 정보는 모든 트랜잭션의 처리 상태를 보존하고 있는 처리 로그 파일pg_clog/*에 쓰여져 있습니다. 테이블 파일은 이 정보가 있어야만 사용이 가능합니다. 물론 테이블과 거기에 괸련된pg_clog데이터만으로 복원하는 것 또한 데이터베이스 클러스터에 있는 다른 테이블을 헛되히 끝내게 됨으로 할 수 없습니다. 그러므로, 파일 시스템 백업은 데이터베이스 클러스터 전체의 완전한 복원을 위해서만 동작합니다.
그 외의 파일 시스템 백업 방법으로서 파일 시스템이"일관성을 유지한 snapshot"기능을 지원하고 있는 경우(올바르게 실행되고 있다고 신용하는 경우), 데이터 디렉토리의 스냅샷을 작성하는 방법이 있습니다. 전형적인 순서는 데이터베이스를 포함한 볼륨의"동결 snapshot"을 작성해, 데이터 디렉토리 전체(위에서 설명한 바와 같이, 일부만으로는 안됩니다)를 snapshot로부터 백업 디바이스에 카피하고 , 동결 스냅샷을 해제합니다. 이것은 데이터베이스 서버가 가동 중이라도 동작합니다. 그러나 이렇게 해 작성된 백업은 데이터베이스 서버가 정상적으로 정지되지 않았던 상태의 데이터베이스 파일을 보존합니다. 그 결과, 이 백업 데이터로 데이터베이스 서버를 기동할 때, 그 전에 서버가 크래쉬(에러로 작동하지 않음)한 것으로 간주하고 WAL 로그를 재생하게 됩니다. 이점은 문제가 되지 않습니다. 단지 주의해 주십시요(그리고 확실히 백업에 WAL 파일을 포함해 주십시요).
대상의 데이터베이스가 복수의 파일 시스템에 걸쳐 분산하고 있는 경우, 모든 볼륨에 대해서 완전하게 동기 한 동결 스냅샷을 얻을 방법이 존재하지 않을 가능성이 있습니다. 예를 들면, 데이터 파일과 WAL 로그가 다른 디스크상에 있거나 테이블 공간이 다른 파일 시스템 상에 있는 경우, snapshot는 동시에 일어나지 않으면 안됩니다 그 이유는 snapshot의 백업을 사용할 수 없을 가능성이 있기 때문입니다. 이러한 상황에서는 일관성을 유지한 snapshot 기술을 신용하기 전에 사용하는 파일 시스템의 문서를 숙독(뜻을 생각하며 읽음)해 주십시요. 가장 안전한 방법은 모든 동결 스냅샷을 확정하도록 충분히 길게 데이터베이스 서버를 shut down시키는 것입니다.
파일 시스템을 백업 하는 그 외의 선택사항으로서rsync의 사용을 들 수 있습니다. 이것을 실시하려면, 먼저 데이터베이스 서버가 가동중에rsync를 실행하고, rsync를 실행하는데 충분하도록 데이터베이스 서버를 정지합니다. 다음의rsync는 비교적 전송 하는 데이터량이 적고, 서버가 가동하고 있지 않기 때문에 최종 결과에 모순이 없으며, 최초의rsync보다 보다 신속합니다. 이 방법으로 최소의 가동 정지시간에 파일 시스템의 백업을 실시할 수 있습니다.
파일 시스템 백업은 SQL에 의한 덤프보다 작아진다고는 할 수 없는 것에 주의해 주십시요. 반대로, 이것은 거대하게 되기 쉽습니다. (pg_dump에서는 예를 들어, 인덱스의 내용을 덤프 할 필요는 없습니다. 단지 명령들로 재작성합니다.)