pg_dump 프로그램으로 만든 텍스트 덤프 파일은 psql 프로그램에서 바로 사용할 수 있다. 일반적인 사용법은 다음과 같다:

psql 데이터베이스이름 < 덤프파일

덤프파일 자리에, pg_dump 명령으로 만든 덤프 파일을 지정한다. dbname 자리에는 psql 클라이언트가 접속 해서, 덤프 파일의 명령을 실행할 데이터베이스 이름을 지정한다. 주의 할 점은 윗 명령으로 해당 데이터베이스가 만들어지지는 않는다. psql 명령을 실행하기 전에 먼저 createdb -T template0 데이터베이스이름 명령과 같이 먼저 접속할 데이터베이스를 만들어 놓아야한다. psql 프로그램도 pg_dump 프로그램과 마찬가지로 데이터베이스 접속과 관련된 접속 인증 방식으로 환경변수와, 명령행 옵션의 사용법이 같다. psql 프로그램에 대한 자세한 설명은 psql 설명서에서 다룬다. 일반 텍스트 덤프 파일이 아닌 백업 파일을 복원할 경우는 pg_restore 명령을 이용한다.

SQL 덤프 파일 안에는 각 객체의 접근 권한을 지정하는 명령도 포함되어 있기 때문에, 그 덤프 파일 안에서 사용하는 모든 사용자들도 새 데이터베이스에 미리 만들어야한다. 해당 사용자가 없다면, 이 접근 권한 설정하는 명령어들은 모두 실패할 것이다. (가끔 이것을 의도해서 이렇게 처리하기도 하지만, 일반적인 방법은 아니다.)

기본적으로 psql 스크립트는 해당 작업 도중 오류가 발생하면, 멈추지 않고, 다음 작업을 진행한다. 만일 이런 기능을 원치 않으며, psql 프로그램을 실행 할 때, ON_ERROR_STOP 변수를 지정한다. 이렇게 하면, 스크립트 실행 도중 오류가 발생하면, 바로 스크립트는 중지되고, psql 실행 리턴 코드 3으로 종료된다. 다음은 그 사용 방법이다:

psql --set ON_ERROR_STOP=on dbname < 덤프파일

이 방법은 스크립트에서 정상적으로 실행된 작업들에 대해서는 해당 데이터베이스에 반영되었다는 것을 의미한다. 이것도 원치 않고, 트랜잭션 처리 방식 처럼, 모든 스크립트가 정상 처리되어야만 전체가 반영되길 원한다면, -1 또는 --single-transaction 옵션을 사용해서, 스크립트 전체를 하나의 트랜잭션으로 처리하도록 한다. 단점은 많은 작업을 해야하는데, 작은 오류 하나로, 전체가 롤백 되면서 많은 시간을 소비할 수 있다는 점이다. 대신에 오류가 발생되면 수동으로 일일히 복잡한 데이터베이스 정리 작업을 하지 않아도 된다.

pg_dump, psql 두 프로그램 모두 표준 입출력을 사용할 수 있기 때문에, 파이프를 사용한다면, 덤프 하면서 바로 다른 데이터베이스 서버에 복원할 수도 있다. 사용법은 다음과 같다:

pg_dump -h 호스트1 데이터베이스이름 | psql -h 호스트2 데이터베이스이름

백업 파일의 복원 작업이 끝난 뒤에는 쿼리 최적화기가 올바른 통계 정보를 사용할 수 있도록, ANALYZE 명령을 실행 한다. 24.1.3절과 24.1.6절 참조. 대용량 데이터베이스 작업에서 보다 낳은 성능을 고려한다면, 24.1.3절을 참조해서, 덤프, 복원 작업을 하기 전에 먼저 서버 환경을 변경하고, 작업을 진행하는 것도 좋은 방법이다.

pg_dump 명령어는 지정한 하나의 데이터베이스만 한 번에 백업한다. 또한 데이터베이스 객체에 속하지 않는 role(데이터베이스 사용자), 테이블스페이스 정보는 백업되지 않는다. 데이터베이스 클러스터 기준 모든 정보를 백업받으려면, pg_dumpall 프로그램을 이용한다. 일반적인 사용법은 다음과 같다:

pg_dumpall > 덤프파일

이 덤프 파일은 psql 프로그램에서 다음과 같이 사용한다:

psql -f 덤프파일 postgres

(정확하게는, 데이터베이스 서버에 접속하기 위해서, postgres 데이터베이스 이름을 지정한 것 뿐이지, 실재로는 접속이 끝나면, 바로 이 데이터베이스에서 작업하기 전에 먼저 데이터베이스 클러스터 전역 정보부터 복원 작업을 시작한다.) pg_dumpall 명령을 사용할 때는 접속할 해당 데이터베이스의 슈퍼유저로 접속해야한다. 그래야, role, 테이블스페이스 정보들을 덤프할 수 있다. 또한 이 덤프된 자료를 복원 할 때도 마찬가지다. 주의 할 점은 만일 기본 테이블스페이스 외에 다른 테이블스페이스를 사용한다면, 그 테이블스페이스의 실재 디렉터리도 덤프 하는 서버에서 사용하는 경로와 똑같이 만들어 놓아야한다.

pg_dumpall 명령은 먼저, 데이터베이스 사용자를 위한 role 정보, 다음 테이블스페이스 정보, 다음 기본 템플릿 데이터베이스에 대한 덤프 작업을 한 다음, 각 데이터베이스를 덤프하기 위해, pg_dump 프로그램을 호출 한다. 이 말은 각 데이터베이스가 각기 다른 시간에 백업 작업을 진행 하기 때문에 데이터베이스간 똑 같은 시간대의 스냅샷 형태의 자료 덤프는 불가능하다는 의미다.

데이터베이스 클러스터의 서버 전역 객체들만 백업하려면, pg_dumpall --globals-only 옵션을 이용한다. 이 경우는 pg_dump 명령을 이용해서 각각의 데이터베이스를 따로 백업해서 복원하려고 할 때, 필요하다.

몇몇 운영체제는 만들 수 있는 최대 파일 크기가 제한 되어 있어, pg_dump 명령으로 만들어지는 파일이 이 최대 파일 크기를 초과하는 경우 문제가 될 수 있다. 다행이, pg_dump 명령의 출력 내용을 표준 출력(stdout)으로 보낼 수 있기 때문에, 표준 유닉스 명령들을 이용한다면, 이런 잠재적인 문제를 피해갈 수 있다. 그 방법은 다음과 같이 여러가지다:

덤프 내용을 압축하라.  gzip과 같은 압축 프로그램을 사용하는 방법:

pg_dump dbname | gzip > filename.gz

복원 할 때는:

gunzip -c filename.gz | psql dbname

또는:

cat filename.gz | gunzip | psql dbname

split 명령을 이용하라.  split 명령은 표준 입력(stdin)으로 들어오는 내용을 지정한 크기로 나누워서 파일로 저장하는 기능을 제공한다. 다음은 1MB 크기로 나눠서 덤프 파일을 생성하는 예제다: make chunks of 1 megabyte:

pg_dump dbname | split -b 1m - filename

복원 할 때는:

cat filename* | psql dbname

pg_dump의 사용자 정의 포멧 기능을 이용하라.  만일 PostgreSQL 배포판을 빌드 할 때, zlib 압축 라이브러를 사용할 수 있도록 했다면, 덤프 파일을 만들 때, 그 내용을 압축해서 만든다. 이 때 최종 덤프 파일은 gzip 프로그램으로 원본 덤프 파일을 압축 했을 때의 크기만큼 줄일 수 있다. 또한 이 기능을 이용해서, 백업을 하면, 테이블을 선택적으로 지정해서 그 테이블만 복원 할 수도 있다. 다음은 사용자 정의 포멧을 지정해서 덤프 하는 예제다:

pg_dump -Fc dbname > filename

이렇게 만들어진 덤프 파일은 psql에서 사용할 수 있는 스크립트 파일이 아니다. 그래서, 다음과 같이 pg_restore 명령을 사용해서 복원 해야한다:

pg_restore -d dbname filename

자세한 사용법은 pg_dump, pg_restore 사용 설명서를 참조하라.

엄청나게 큰 데이터베이스라면, split 명령어와 함께 기타 다른 명령어들을 함께 연결해서 사용할 필요성도 있다.

pg_dump의 병렬적 덤프 기능을 이용하라. .  대용량 데이터베이스의 덤프 속도를 높이기 위해서는 pg_dump의 병렬 모드를 사용하면 된다. 그러면 테이블들을 동시에 덤프한다. 병렬 처리 수준은 -j 매개 변수로 조절할 수 있다. 병렬적 덤프는 “디렉터리” 아카이브 형식만 지원한다.

pg_dump -j num -F d -f out.dir dbname

pg_restore -j를 이용해서 병렬적 덤프를 복구할 수 있다. 이 방식은 “사용자 정의” 혹은 “디렉터리” 아카이브 모드의 아카이브에서 가능하며 pg_dump -j로 만들어지지 않았어도 상관없다.