공식적인 백업 복구는 데이터베이스 클러스터 단위입니다. 

테이블 스페이스 단위는 공식적으로는 불가능합니다. 비공식적으로 온갖 비법을 동원해 작업을 한다고 해도 그 자료의 정합성 문제가 생길 여지가 너무 많아서  독자적으로 개발한다고 해도 꽤 힘든 작업일 것 같네요. 

 네 말씀주신 내용을 공신 온라인매뉴얼에서 확인하였습니다. ^^

그렇다면 대용량 테이블에 대한 백업은 DUMP 외에 3rd 파티 툴을 이용하면 좀 빠를까요?

이때 테이블스페이스를 일별로 모두 나누는게 IO 병목을 줄이는데 좋을지 고민 중 입니다.

참고로 제가 DUMP (COPY) 툴을 안쓰려는 이유는 배열컬럼이 있는 경우, CPU 코어(1core) 부하가 발생하여

Read 양이 너무 적기 때문 입니다. 옵션 튜닝을 해도 변화가 없더라구요. 1개 테이블에 대한 COPY 명령이 여러 코어를 사용하면 좋을텐데....안되는듯 합니다.

pg의 기본 사상은 온라인 백업은 사용자가 알아서 입니다. 

디비 서버로 '나 지금부터 백업할거야 지금부터 dirty buffer 조각은 full page writing을 하고, 일어나는 모든 DML 로그는 따로 보관해(archiving)' 이렇게 설정하고 - 이게 pg_start_backup 입니다.

그 다음 데이터 클러스터 전체를 다른 곳 (다른 호스트가 될 수도 있고, 다른 디렉터리가 될 수도 있고, 어떤 특정 장치(백업 스토리지)일 수도 있고, 심지어 메일 서버일 수도 있겠죠)으로 보관합니다. 이 데이터 클러스터 전체를 복사하는 하는 작업은 사용자의 몫입니다. 얼마든지 속도를 조절 할 수도 있고, 병렬 프로세스로 처리할 수도 있겠죠. 그 아이디어에 따라. 일반적으로는 rsync를 많이 사용하더군요. 큰 기업에서는 대부분 전용 백업 솔루션을 사용하고요.

이 데이터 클러스터 백업작업이 끝나면, 이제 pg_stop_backup을 합니다. 

그리고 나서 start와,  stop 사이 생긴 따로 보관된(archived) 트랜잭션 로그 조각 파일들을 다시 백업 위치에 따로 보관해 둡니다. 더 극단적으로 이야기하면, pg의 트랜잭션 로그 따로 보관하기(archiving)도 사용자 몫입니다. 

이렇게 백업이 끝나면, 결국 두 묶음이 따로 보관(backuped) 되어있겠죠. 하나는 데이터 클러스터 덩어리고, 다른 하나는 아카이브들의 덩어리고.

이 두 덩어리를 가지고 복원합니다. 이게 일반적인 pg의 백업&복구입니다. 

pg_dump는 백업이라는 개념보다는 export 개념에 더 가깝습니다. 

네 답변 감사합니다. DB가 10~20TB 사이가 되다보니...

export 방식을  고민하다...성능이 안나와 백업 툴에서 일별로 구성된 단일 테이블에 대한 백업을 고민하게 되었습니다.