GREENPLUM和许多关系型数据库一样从两个方面实现数据库数据的保护。一方面是通过数据库的备份恢复，实现数据仓库数据的保护。另一方面是通过冗余实现系统的容错，为数据仓库系统提供高可用性。
这部分先介绍数据库的备份。GREENPLUM为数据库的备份提供了两种工具，一种是pg_dump，另一种是gp_dump。pg_dump是从postgre继承过来的工具，它只能通过MASTER节点采用串行方式备份数据库，可以本地备份，也可以远程备份。其具体的参数说明可以通过执行
pg_dump --help获取
用法:
pg_dump [OPTION]... [DBNAME]
常用选项:
-f, --file=FILENAME 备份文件的名称
-F, --format=c|t|p 输出文件的格式，c表示二进制文件，t表示tar,p表示文本
-i, --ignore-version 当服务版本不匹配时，忽略服务版本。
-v, --verbose verbose模式
-Z, --compress=0-9 采用压缩模式存放备份结果，并指定压缩级别
--help 显示帮助
--version 显示版本，然后退出
控制输出内容的选项
-a, --data-only 备份中只含有数据，而没有schema信息。
-b, --blobs 在备份中包含大对象。
-c, --clean 在创建前，删除schema
-C, --create 在备份文件中含有创建数据库的命令。
-d, --inserts 备份数据使用insert命令模式
-D, --column-inserts 备份数据使用insert命令模式，并提供列名。
-E, --encoding=ENCODING 备份文件使用的字符集
-n, --schema=SCHEMA 只备份特定的SCHEMA
-N, --exclude-schema=SCHEMA 备份中排除特定的SCHEMA
-o, --oids 在备份中包含oid
-O, --no-owner 如果采用文本格式备份，越过对象所有者的还原信息。
-s, --schema-only 只备份SCHEMA的信息，而不备份它们的数据。
-S, --superuser=NAME 如果使用文本格式，指定超级用户的名称
-t, --table=TABLE 只备份特定的表，视图，或者序列
-T, --exclude-table=TABLE 备份中排除特定的表，视图或者序列。
-x, --no-privileges 不备份权限(grant/revoke)
--disable-dollar-quoting 只使用表中SQL的""，不需使用$$处理文本分割
--use-set-session-authorization 使用SESSION AUTHORIZATION命令替代
ALTER OWNER commands设置所有权
--gp-syntax 备份中的SQL使用GREENPLUM句法，默认选项
--no-gp-syntax 备份中的SQL不使用GREENPLUM句法
连接选项
-h, --host=HOSTNAME 数据库主机名，或者socket目录
-p, --port=PORT 数据库服务端口
-U, --username=NAME 指定用户名
-W, --password 强制口令提示。
比如例子
pg_dump -f /home/gpadmin/backup/sales_bak -v -F c -p 5432 -h mdw -C -n sales_history sales_history
提供master的连接信息，把数据库sales_history的schema sales_history备份到/home/gpadmin/backup/sals_bak中，并含有建库句法。
这种备份方式实际上是一种逻辑备份方式，而非ORACLE RMAN那样的物理备份。它有两个主要的限制。一方面备份速度受MASTER节点数据吞吐能力的限制。另外，MASTER用来存放备份文件的空间必须足够大，能够存放所有segment节点的备份数据。所以这种方式更适合用在数据迁移的场景中.比如把postgre数据库（或者netezza）的数据迁移到greenplum中，或者在不同架构的GREENPLUM数据库间进行数据迁移，比如4节点的服务的数据，向8节点的服务迁移。
对应pg_dump备份的结果，如果数据库出现故障，或者要进行数据移植，需要进行数据恢复，要使用工具pg_restore。具体参数说明可以通过pg_restore --help获取。
具体用法:
pg_restore [OPTION]... [FILE]
常见选项:
-d, --dbname=NAME 指定连接数据库的名称。
-f, --file=FILENAME 输出文件名称
-F, --format=c|t 指定备份文件格式，c表示自定义，t表示tar
-i, --ignore-version 如果版本不匹配，忽略版本
-l, --list 打印归档TOC的汇总信息
-v, --verbose 使用verbose模式
--help 显示帮助，然后退出
--version 显示版本，然后退出
控制还原的选项
-a, --data-only 只还原数据
-c, --clean 在创建之前删除schema
-C, --create 创建目标数据库
-I, --index=NAME 还原索引
-L, --use-list=FILENAME 按照文件指定顺序还原表
-n, --schema=NAME 只还原特定SCHEMA的对象
-O, --no-owner 跳过特定所有者对象的还原
-P, --function='NAME(args)' 还原特定的函数，函数的名字必须与TOC中的一致，并且使用单引号括起。
-s, --schema-only 只还原SCHEMA，不还原相关数据。
-t, --table=NAME 只还原特定的表
-x, --no-privileges 跳过特定权限的还原 (grant/revoke)
--use-set-session-authorization 使用SESSION AUTHORIZATION替代 ALTER OWNER TO命令
--no-data-for-failed-tables 不还原创建表失败的数据
-1, --single-transaction 还原作为一个单一事务进行。
连接选项:
-h, --host=HOSTNAME 指定数据库服务的主机名或者socket目录
-p, --port=PORT 数据库服务端口号
-U, --username=NAME 指定连接的数据库用户
-W, --password 强制口令提示
-e, --exit-on-error 遇到错误退出，默认模式是继续。
用刚才的备份为列，我们先删除sales表
sales_history=> select count(*) from sales;
count
--------
918843
(1 row)
sales_history=> select count(*) from sales;
ERROR: relation "sales" does not exist
LINE 1: select count(*) from sales;
^
sales_history=> \q
然后利用备份进行表级恢复
gpadmin@mdw:~/backup> pg_restore -F c -d sales_history -v -t sales -h mdw -p 5432 -U sh /home/gpadmin/backup/sales_bak
pg_restore: connecting to database for restore
Password:
pg_restore: creating TABLE sales
pg_restore: restoring data for table "sales"
pg_restore: setting owner and privileges for TABLE sales
完成恢复后检查表
sales_history=> select count(*) from sales;
count
--------
918843
(1 row)
需要注意的是，如果pg_dump备份的文件格式是txt平面文件，则不能用pg_restore进行恢复，应该考虑使用psql进行恢复。否则会得到如下错误信息
pg_restore: [archiver] did not find magic string in file header。这一点也完全适用于postgre数据库。
对于海量数据仓库来而言，通过pg_dump/pg_restore进行备份/恢复，一方面在性能上无法满足业务对备份/恢复时间窗口要求，另外对MASTER可以访问的存储容积和性能也有比较高的要求。为了解决这两点问题，GREENPLUM在POSTGRESQL的基础上提供了自己的备份/恢复工具gp_dump/gp_restore。它们不需要通过master进行数据库的备份恢复，每个segment和master并行备份/恢复自己的数据，这样master就不会再成为瓶颈，从而大幅提高备份/恢复的速度。
先看gp_dump的用法。同样可以通过gp_dump --help查看相关选项。
具体的句法
gp_dump [OPTION]... [DBNAME]
常用选项:
-i, --ignore-version 即使与服务版本不匹配，也继续处理
-v, --verbose 使用verbose模式，显示处理过程的细节信息。并在每个段的状态文件中添加这些信息。
--help 查看帮助
--version 输出版本信息，然后退出。
控制输出内容的选项
-a, --data-only 只备份数据
-c, --clean 在创建之前，先删除schema
-d, --inserts 使用insert命令方式备份数据，而不是copy命令
-D, --column-inserts 使用insert命令方式备份数据，并显示列信息
-E, --encoding=ENCODING 指定备份数据使用的字符集
-n, --schema=SCHEMA 只备份指定的shcema
-N, --exclude-schema=SCHEMA 不备份指定的schema
-o, --oids 备份中包含oid
-O, --no-owner 采用文本格式时，不输出授权语句。
-s, --schema-only 只备份schema的定义
-S, --superuser=NAME 采用文本格式备份时，指定超级管理员
-t, --table=TABLE 只备份特定的表，视图，索引和序列
-T, --exclude-table=TABLE 不备份特定的表，视图，索引和序列
es)
-x, --no-privileges 不备份授权语句
--use-set-session-authorization 使用SESSION AUTHORIZATION替代
ALTER OWNER 命令去设置所有权
连接选项
-h, --host=HOSTNAME 数据库服务主机（ip）或者socket目录
-p, --port=PORT 数据库服务端口号
-U, --username=NAME 连接用户
-W, --password 强制口令提示，默认选项
Greenplum专有选项
--gp-c 用gzip进行内置备份压缩
--gp-d=BACKUPFILEDIR 指定备份文件存放目录，这些目录应该存在于所有master主机和segment主机，或者为这些主机所共享。默认目录就是每个段和master的数据目录。
--gp-r=REPORTFILEDIR 指定备份报告文件的存放目录，这些目录应该存在于所有master主机和segment主机，或者为这些主机所共享。默认目录就是每个段和master的数据目录。
--gp-s=BACKUPSET 备份指示 - p表示备份所有primary segment。i指定特定的primary segment进行备份，要跟上特定segment的dbid。
比如我们要对sales_history进行全库备份。
gpadmin@mdw:~> gp_dump --gp-c sales_history
20110419:15:41:39|gp_dump-[INFO]:-Command line options analyzed.
20110419:15:41:39|gp_dump-[INFO]:-Connecting to master database on host localhost port 5432 database sales_history.
20110419:15:41:39|gp_dump-[INFO]:-Reading Greenplum Database configuration info from master database.
20110419:15:41:39|gp_dump-[INFO]:-Preparing to dump the following segments:
20110419:15:41:39|gp_dump-[INFO]:-Segment 3 (dbid 5)
20110419:15:41:39|gp_dump-[INFO]:-Segment 2 (dbid 4)
20110419:15:41:39|gp_dump-[INFO]:-Segment 1 (dbid 3)
20110419:15:41:39|gp_dump-[INFO]:-Segment 0 (dbid 2)
20110419:15:41:39|gp_dump-[INFO]:-Master (dbid 1)
20110419:15:41:39|gp_dump-[INFO]:-Starting a transaction on master database sales_history.
20110419:15:41:39|gp_dump-[INFO]:-Getting a lock on pg_class in database sales_history.
20110419:15:41:39|gp_dump-[INFO]:-About to spin off 5 threads with timestamp key 20110419154139
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 5: host sdw2 port 50003 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 4: host sdw2 port 50002 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 3: host mdw port 50001 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 2: host mdw port 50000 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 1: host mdw port 5432 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Waiting for remote gp_dump_agent processes to start transactions in serializable isolation level
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 3 connection
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 1 connection
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 2 connection
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 5 connection
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 4 connection
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 1 server
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 3 server
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 2 server
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 5 server
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 4 server
20110419:15:41:42|gp_dump-[INFO]:-backup succeeded for dbid 1 on host mdw
20110419:15:41:42|gp_dump-[INFO]:-All remote gp_dump_agent processes have began transactions in serializable isolation level
20110419:15:41:42|gp_dump-[INFO]:-Waiting for remote gp_dump_agent processes to obtain local locks on dumpable objects
20110419:15:41:42|gp_dump-[INFO]:-All remote gp_dump_agent processes have obtains the necessary locks
20110419:15:41:42|gp_dump-[INFO]:-Committing transaction on the master database, thereby releasing locks.
20110419:15:41:42|gp_dump-[INFO]:-Waiting for all remote gp_dump_agent programs to finish.
20110419:15:41:44|gp_dump-[INFO]:-backup succeeded for dbid 3 on host mdw
20110419:15:41:44|gp_dump-[INFO]:-backup succeeded for dbid 5 on host sdw2
20110419:15:41:45|gp_dump-[INFO]:-backup succeeded for dbid 4 on host sdw2
20110419:15:41:45|gp_dump-[INFO]:-backup succeeded for dbid 2 on host mdw
20110419:15:41:45|gp_dump-[INFO]:-All remote gp_dump_agent programs are finished.
20110419:15:41:45|gp_dump-[INFO]:-Report results also written to /data/gpmaster/gpseg-1/gp_dump_20110419154139.rpt.
Greenplum Database Backup Report
Timestamp Key: 20110419154139
gp_dump Command Line: --gp-c sales_history
Pass through Command Line Options: None
Compression Program: gzip
Individual Results
segment 3 (dbid 5) Host sdw2 Port 50003 Database sales_history BackupFile /data/gpdb_p4/gpseg3/./gp_dump_0_5_20110419154139.gz: Succeeded
segment 2 (dbid 4) Host sdw2 Port 50002 Database sales_history BackupFile /data/gpdb_p3/gpseg2/./gp_dump_0_4_20110419154139.gz: Succeeded
segment 1 (dbid 3) Host mdw Port 50001 Database sales_history BackupFile /data/gpdb_p2/gpseg1/./gp_dump_0_3_20110419154139.gz: Succeeded
segment 0 (dbid 2) Host mdw Port 50000 Database sales_history BackupFile /data/gpdb_p1/gpseg0/./gp_dump_0_2_20110419154139.gz: Succeeded
Master (dbid 1) Host mdw Port 5432 Database sales_history BackupFile /data/gpmaster/gpseg-1/./gp_dump_1_1_20110419154139.gz: Succeeded
gp_dump utility finished successfully.
在master上
一方面可以看到报告文件，所有文件都有一个含有时间戳信息的14位编码，这个编码是将来恢复时选择备份的关键字，并且保证了每个段备份的一致性。
gp_dump_20110419154139.rpt 它提供所有段的备份情况
gp_dump_status_1_1_20110419154139 提供master的备份过程信息。
gp_cdatabase_1_1_20110419154139 提供了创建数据库的句法信息。
gp_dump_1_1_20110419154139.gz master具体的备份数据。
在segment上，只有两个文件
gp_dump_status_0_2_20110419154139 提供了特定段备份的过程信息。
gp_dump_0_2_20110419154139.gz 特定段的备份数据
对应gp_dump的备份需要通过gp_restore进行并行恢复。具体用法如下
gp_restore [OPTIONS]
常用选项
-d, --dbname=NAME 指定数据库名称
-i, --ignore-version 即使服务版本不匹配，忽略版本信息。
-v, --verbose 用verbose模式. 并向每个段的状态文件中添加这些信息
--help 显示帮助然后退出
--version 输出版本信息，然后退出
控制输出内容的选项
-a, --data-only 只恢复数据
-c, --clean 创建之前，删除schema
-s, --schema-only 只恢复schema定义
连接选项
-h, --host=HOSTNAME 指定数据库服务主机名或者socket目录
-p, --port=PORT 指定连接端口号
-U, --username=NAME 指定连接的用户
-W, --password 强制口令提示
Greenplum 特有选项
--gp-c 如果备份时是压缩格式，必须恢复使用该选项解压
--gp-d=BACKUPFILEDIR 指定备份文件目录，默认就是数据目录。
--gp-i 忽略错误
--gp-k=KEY 指定备份14位时间戳信息，必须指定。
--gp-r=REPORTFILEDIR 指定报告存放目录
--gp-l=FILELOCATIONS 指定备份文件是在所有主段（p),还是特定的主段上。
比如刚才的备份进行恢复测试
我们可以先删除数据库sales_history
template1=# drop database sales_history;
DROP DATABASE
template1=# \l
List of databases
Name | Owner | Encoding | Access privileges
-----------+---------+----------+---------------------
postgres | gpadmin | UTF8 |
template0 | gpadmin | UTF8 | =c/gpadmin
: gpadmin=CTc/gpadmin
template1 | gpadmin | UTF8 | =c/gpadmin
: gpadmin=CTc/gpadmin
xjods | gpadmin | UTF8 |
(4 rows)
下面进行恢复，再恢复之前，必须先重建数据库。这可以自己用命令创建，或者使用master上备份时产生脚本进行数据库的重新创建，比如
gpadmin@mdw:/data/gpmaster/gpseg-1> psql -d template1 -f gp_cdatabase_1_1_20110419154139
CREATE DATABASE
完成数据库创建之后，才能进行数据恢复。
gpadmin@mdw:~> gp_restore -d sales_history --gp-k=20110419154139 --gp-c
20110419:16:05:19|gp_restore-[INFO]:-Analyzed command line options.
20110419:16:05:19|gp_restore-[INFO]:-Connecting to master segment on host localhost port 5432 database sales_history.
20110419:16:05:19|gp_restore-[INFO]:-Reading Greenplum Database configuration info from master segment database.
20110419:16:05:19|gp_restore-[INFO]:-Preparing to restore the following segments:
20110419:16:05:19|gp_restore-[INFO]:-Segment 3 (dbid 5)
20110419:16:05:19|gp_restore-[INFO]:-Segment 2 (dbid 4)
20110419:16:05:19|gp_restore-[INFO]:-Segment 1 (dbid 3)
20110419:16:05:19|gp_restore-[INFO]:-Segment 0 (dbid 2)
20110419:16:05:19|gp_restore-[INFO]:-Master (dbid 1)
20110419:16:05:19|gp_restore-[INFO]:-Starting to restore the master database.
20110419:16:05:19|gp_restore-[INFO]:-Creating thread to restore master database: host mdw port 5432 database sales_history
20110419:16:05:19|gp_restore-[INFO]:-Listening for messages from dbid 1 server (source) for dbid 1 restore
20110419:16:05:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 1 to restore dbid 1
20110419:16:05:21|gp_restore-[INFO]:-restore started for source dbid 1, target dbid 1 on host mdw
20110419:16:06:19|gp_restore-[INFO]:-restore succeeded for source dbid 1, target dbid 1 on host mdw
20110419:16:06:19|gp_restore-[INFO]:-Successfully restored master database: host mdw port 5432 database sales_history
20110419:16:06:19|gp_restore-[INFO]:-Creating thread to restore dbid 5 (sdw2:50003) from backup file on dbid 5 (sdw2:50003)
20110419:16:06:19|gp_restore-[INFO]:-Creating thread to restore dbid 4 (sdw2:50002) from backup file on dbid 4 (sdw2:50002)
20110419:16:06:19|gp_restore-[INFO]:-Creating thread to restore dbid 3 (mdw:50001) from backup file on dbid 3 (mdw:50001)
20110419:16:06:19|gp_restore-[INFO]:-Creating thread to restore dbid 2 (mdw:50000) from backup file on dbid 2 (mdw:50000)
20110419:16:06:19|gp_restore-[INFO]:-Waiting for all remote gp_restore_agent programs to finish.
20110419:16:06:19|gp_restore-[INFO]:-Listening for messages from dbid 5 server (source) for dbid 5 restore
20110419:16:06:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 5 to restore dbid 5
20110419:16:06:19|gp_restore-[INFO]:-Listening for messages from dbid 4 server (source) for dbid 4 restore
20110419:16:06:19|gp_restore-[INFO]:-Listening for messages from dbid 2 server (source) for dbid 2 restore
20110419:16:06:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 2 to restore dbid 2
20110419:16:06:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 4 to restore dbid 4
20110419:16:06:19|gp_restore-[INFO]:-Listening for messages from dbid 3 server (source) for dbid 3 restore
20110419:16:06:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 3 to restore dbid 3
20110419:16:06:22|gp_restore-[INFO]:-restore started for source dbid 3, target dbid 3 on host mdw
20110419:16:06:22|gp_restore-[INFO]:-restore started for source dbid 4, target dbid 4 on host sdw2
20110419:16:06:22|gp_restore-[INFO]:-restore started for source dbid 2, target dbid 2 on host mdw
20110419:16:06:22|gp_restore-[INFO]:-restore started for source dbid 5, target dbid 5 on host sdw2
20110419:16:06:26|gp_restore-[INFO]:-restore succeeded for source dbid 3, target dbid 3 on host mdw
20110419:16:06:26|gp_restore-[INFO]:-restore succeeded for source dbid 5, target dbid 5 on host sdw2
20110419:16:06:26|gp_restore-[INFO]:-restore succeeded for source dbid 2, target dbid 2 on host mdw
20110419:16:06:26|gp_restore-[INFO]:-restore succeeded for source dbid 4, target dbid 4 on host sdw2
20110419:16:06:26|gp_restore-[INFO]:-All remote gp_restore_agent programs are finished.
20110419:16:06:26|gp_restore-[INFO]:-updating Append Only table statistics
20110419:16:06:27|gp_restore-[INFO]:-Report results also written to /data/gpmaster/gpseg-1/gp_restore_20110419154139.rpt.
Greenplum Database Restore Report
Timestamp Key: 20110419154139
gp_restore Command Line: -d sales_history --gp-k=20110419154139 --gp-c
Pass through Command Line Options: None
Compression Program: gunzip
Individual Results
Restore of sales_history on dbid 1 (mdw:5432) from /data/gpmaster/gpseg-1/./gp_dump_1_1_20110419154139.gz: Succeeded
Restore of sales_history on dbid 5 (sdw2:50003) from /data/gpdb_p4/gpseg3/./gp_dump_0_5_20110419154139.gz: Succeeded
Restore of sales_history on dbid 4 (sdw2:50002) from /data/gpdb_p3/gpseg2/./gp_dump_0_4_20110419154139.gz: Succeeded
Restore of sales_history on dbid 3 (mdw:50001) from /data/gpdb_p2/gpseg1/./gp_dump_0_3_20110419154139.gz: Succeeded
Restore of sales_history on dbid 2 (mdw:50000) from /data/gpdb_p1/gpseg0/./gp_dump_0_2_20110419154139.gz: Succeeded
gp_restore utility finished successfully.
GREENPLUM备份恢复机制类似oracle数据库的逻辑备份概念。基本上可以满足传统数据仓库对备份恢复的要求。但是GREENPLUM备份工具仍然存在局限性，比如无论是全库备份还是对象级别的备份只能是完全备份，而不支持增量备份。备份虽然是联机备份，但是在备份过程中会在备份的对象上加排他锁，从而影响系统的DML操作。当然，这些问题可以通过对大表进行分区的方式，进行一定的缓解。我们还是希望EMC在将来的版本上可以对GP的备份工具进行改进，使其更加完善好用。
这部分先介绍数据库的备份。GREENPLUM为数据库的备份提供了两种工具，一种是pg_dump，另一种是gp_dump。pg_dump是从postgre继承过来的工具，它只能通过MASTER节点采用串行方式备份数据库，可以本地备份，也可以远程备份。其具体的参数说明可以通过执行
pg_dump --help获取
用法:
pg_dump [OPTION]... [DBNAME]
常用选项:
-f, --file=FILENAME 备份文件的名称
-F, --format=c|t|p 输出文件的格式，c表示二进制文件，t表示tar,p表示文本
-i, --ignore-version 当服务版本不匹配时，忽略服务版本。
-v, --verbose verbose模式
-Z, --compress=0-9 采用压缩模式存放备份结果，并指定压缩级别
--help 显示帮助
--version 显示版本，然后退出
控制输出内容的选项
-a, --data-only 备份中只含有数据，而没有schema信息。
-b, --blobs 在备份中包含大对象。
-c, --clean 在创建前，删除schema
-C, --create 在备份文件中含有创建数据库的命令。
-d, --inserts 备份数据使用insert命令模式
-D, --column-inserts 备份数据使用insert命令模式，并提供列名。
-E, --encoding=ENCODING 备份文件使用的字符集
-n, --schema=SCHEMA 只备份特定的SCHEMA
-N, --exclude-schema=SCHEMA 备份中排除特定的SCHEMA
-o, --oids 在备份中包含oid
-O, --no-owner 如果采用文本格式备份，越过对象所有者的还原信息。
-s, --schema-only 只备份SCHEMA的信息，而不备份它们的数据。
-S, --superuser=NAME 如果使用文本格式，指定超级用户的名称
-t, --table=TABLE 只备份特定的表，视图，或者序列
-T, --exclude-table=TABLE 备份中排除特定的表，视图或者序列。
-x, --no-privileges 不备份权限(grant/revoke)
--disable-dollar-quoting 只使用表中SQL的""，不需使用$$处理文本分割
--use-set-session-authorization 使用SESSION AUTHORIZATION命令替代
ALTER OWNER commands设置所有权
--gp-syntax 备份中的SQL使用GREENPLUM句法，默认选项
--no-gp-syntax 备份中的SQL不使用GREENPLUM句法
连接选项
-h, --host=HOSTNAME 数据库主机名，或者socket目录
-p, --port=PORT 数据库服务端口
-U, --username=NAME 指定用户名
-W, --password 强制口令提示。
比如例子
pg_dump -f /home/gpadmin/backup/sales_bak -v -F c -p 5432 -h mdw -C -n sales_history sales_history
提供master的连接信息，把数据库sales_history的schema sales_history备份到/home/gpadmin/backup/sals_bak中，并含有建库句法。
这种备份方式实际上是一种逻辑备份方式，而非ORACLE RMAN那样的物理备份。它有两个主要的限制。一方面备份速度受MASTER节点数据吞吐能力的限制。另外，MASTER用来存放备份文件的空间必须足够大，能够存放所有segment节点的备份数据。所以这种方式更适合用在数据迁移的场景中.比如把postgre数据库（或者netezza）的数据迁移到greenplum中，或者在不同架构的GREENPLUM数据库间进行数据迁移，比如4节点的服务的数据，向8节点的服务迁移。
对应pg_dump备份的结果，如果数据库出现故障，或者要进行数据移植，需要进行数据恢复，要使用工具pg_restore。具体参数说明可以通过pg_restore --help获取。
具体用法:
pg_restore [OPTION]... [FILE]
常见选项:
-d, --dbname=NAME 指定连接数据库的名称。
-f, --file=FILENAME 输出文件名称
-F, --format=c|t 指定备份文件格式，c表示自定义，t表示tar
-i, --ignore-version 如果版本不匹配，忽略版本
-l, --list 打印归档TOC的汇总信息
-v, --verbose 使用verbose模式
--help 显示帮助，然后退出
--version 显示版本，然后退出
控制还原的选项
-a, --data-only 只还原数据
-c, --clean 在创建之前删除schema
-C, --create 创建目标数据库
-I, --index=NAME 还原索引
-L, --use-list=FILENAME 按照文件指定顺序还原表
-n, --schema=NAME 只还原特定SCHEMA的对象
-O, --no-owner 跳过特定所有者对象的还原
-P, --function='NAME(args)' 还原特定的函数，函数的名字必须与TOC中的一致，并且使用单引号括起。
-s, --schema-only 只还原SCHEMA，不还原相关数据。
-t, --table=NAME 只还原特定的表
-x, --no-privileges 跳过特定权限的还原 (grant/revoke)
--use-set-session-authorization 使用SESSION AUTHORIZATION替代 ALTER OWNER TO命令
--no-data-for-failed-tables 不还原创建表失败的数据
-1, --single-transaction 还原作为一个单一事务进行。
连接选项:
-h, --host=HOSTNAME 指定数据库服务的主机名或者socket目录
-p, --port=PORT 数据库服务端口号
-U, --username=NAME 指定连接的数据库用户
-W, --password 强制口令提示
-e, --exit-on-error 遇到错误退出，默认模式是继续。
用刚才的备份为列，我们先删除sales表
sales_history=> select count(*) from sales;
count
--------
918843
(1 row)
sales_history=> select count(*) from sales;
ERROR: relation "sales" does not exist
LINE 1: select count(*) from sales;
^
sales_history=> \q
然后利用备份进行表级恢复
gpadmin@mdw:~/backup> pg_restore -F c -d sales_history -v -t sales -h mdw -p 5432 -U sh /home/gpadmin/backup/sales_bak
pg_restore: connecting to database for restore
Password:
pg_restore: creating TABLE sales
pg_restore: restoring data for table "sales"
pg_restore: setting owner and privileges for TABLE sales
完成恢复后检查表
sales_history=> select count(*) from sales;
count
--------
918843
(1 row)
需要注意的是，如果pg_dump备份的文件格式是txt平面文件，则不能用pg_restore进行恢复，应该考虑使用psql进行恢复。否则会得到如下错误信息
pg_restore: [archiver] did not find magic string in file header。这一点也完全适用于postgre数据库。
对于海量数据仓库来而言，通过pg_dump/pg_restore进行备份/恢复，一方面在性能上无法满足业务对备份/恢复时间窗口要求，另外对MASTER可以访问的存储容积和性能也有比较高的要求。为了解决这两点问题，GREENPLUM在POSTGRESQL的基础上提供了自己的备份/恢复工具gp_dump/gp_restore。它们不需要通过master进行数据库的备份恢复，每个segment和master并行备份/恢复自己的数据，这样master就不会再成为瓶颈，从而大幅提高备份/恢复的速度。
先看gp_dump的用法。同样可以通过gp_dump --help查看相关选项。
具体的句法
gp_dump [OPTION]... [DBNAME]
常用选项:
-i, --ignore-version 即使与服务版本不匹配，也继续处理
-v, --verbose 使用verbose模式，显示处理过程的细节信息。并在每个段的状态文件中添加这些信息。
--help 查看帮助
--version 输出版本信息，然后退出。
控制输出内容的选项
-a, --data-only 只备份数据
-c, --clean 在创建之前，先删除schema
-d, --inserts 使用insert命令方式备份数据，而不是copy命令
-D, --column-inserts 使用insert命令方式备份数据，并显示列信息
-E, --encoding=ENCODING 指定备份数据使用的字符集
-n, --schema=SCHEMA 只备份指定的shcema
-N, --exclude-schema=SCHEMA 不备份指定的schema
-o, --oids 备份中包含oid
-O, --no-owner 采用文本格式时，不输出授权语句。
-s, --schema-only 只备份schema的定义
-S, --superuser=NAME 采用文本格式备份时，指定超级管理员
-t, --table=TABLE 只备份特定的表，视图，索引和序列
-T, --exclude-table=TABLE 不备份特定的表，视图，索引和序列
es)
-x, --no-privileges 不备份授权语句
--use-set-session-authorization 使用SESSION AUTHORIZATION替代
ALTER OWNER 命令去设置所有权
连接选项
-h, --host=HOSTNAME 数据库服务主机（ip）或者socket目录
-p, --port=PORT 数据库服务端口号
-U, --username=NAME 连接用户
-W, --password 强制口令提示，默认选项
Greenplum专有选项
--gp-c 用gzip进行内置备份压缩
--gp-d=BACKUPFILEDIR 指定备份文件存放目录，这些目录应该存在于所有master主机和segment主机，或者为这些主机所共享。默认目录就是每个段和master的数据目录。
--gp-r=REPORTFILEDIR 指定备份报告文件的存放目录，这些目录应该存在于所有master主机和segment主机，或者为这些主机所共享。默认目录就是每个段和master的数据目录。
--gp-s=BACKUPSET 备份指示 - p表示备份所有primary segment。i指定特定的primary segment进行备份，要跟上特定segment的dbid。
比如我们要对sales_history进行全库备份。
gpadmin@mdw:~> gp_dump --gp-c sales_history
20110419:15:41:39|gp_dump-[INFO]:-Command line options analyzed.
20110419:15:41:39|gp_dump-[INFO]:-Connecting to master database on host localhost port 5432 database sales_history.
20110419:15:41:39|gp_dump-[INFO]:-Reading Greenplum Database configuration info from master database.
20110419:15:41:39|gp_dump-[INFO]:-Preparing to dump the following segments:
20110419:15:41:39|gp_dump-[INFO]:-Segment 3 (dbid 5)
20110419:15:41:39|gp_dump-[INFO]:-Segment 2 (dbid 4)
20110419:15:41:39|gp_dump-[INFO]:-Segment 1 (dbid 3)
20110419:15:41:39|gp_dump-[INFO]:-Segment 0 (dbid 2)
20110419:15:41:39|gp_dump-[INFO]:-Master (dbid 1)
20110419:15:41:39|gp_dump-[INFO]:-Starting a transaction on master database sales_history.
20110419:15:41:39|gp_dump-[INFO]:-Getting a lock on pg_class in database sales_history.
20110419:15:41:39|gp_dump-[INFO]:-About to spin off 5 threads with timestamp key 20110419154139
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 5: host sdw2 port 50003 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 4: host sdw2 port 50002 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 3: host mdw port 50001 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 2: host mdw port 50000 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 1: host mdw port 5432 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Waiting for remote gp_dump_agent processes to start transactions in serializable isolation level
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 3 connection
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 1 connection
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 2 connection
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 5 connection
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 4 connection
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 1 server
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 3 server
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 2 server
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 5 server
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 4 server
20110419:15:41:42|gp_dump-[INFO]:-backup succeeded for dbid 1 on host mdw
20110419:15:41:42|gp_dump-[INFO]:-All remote gp_dump_agent processes have began transactions in serializable isolation level
20110419:15:41:42|gp_dump-[INFO]:-Waiting for remote gp_dump_agent processes to obtain local locks on dumpable objects
20110419:15:41:42|gp_dump-[INFO]:-All remote gp_dump_agent processes have obtains the necessary locks
20110419:15:41:42|gp_dump-[INFO]:-Committing transaction on the master database, thereby releasing locks.
20110419:15:41:42|gp_dump-[INFO]:-Waiting for all remote gp_dump_agent programs to finish.
20110419:15:41:44|gp_dump-[INFO]:-backup succeeded for dbid 3 on host mdw
20110419:15:41:44|gp_dump-[INFO]:-backup succeeded for dbid 5 on host sdw2
20110419:15:41:45|gp_dump-[INFO]:-backup succeeded for dbid 4 on host sdw2
20110419:15:41:45|gp_dump-[INFO]:-backup succeeded for dbid 2 on host mdw
20110419:15:41:45|gp_dump-[INFO]:-All remote gp_dump_agent programs are finished.
20110419:15:41:45|gp_dump-[INFO]:-Report results also written to /data/gpmaster/gpseg-1/gp_dump_20110419154139.rpt.
Greenplum Database Backup Report
Timestamp Key: 20110419154139
gp_dump Command Line: --gp-c sales_history
Pass through Command Line Options: None
Compression Program: gzip
Individual Results
segment 3 (dbid 5) Host sdw2 Port 50003 Database sales_history BackupFile /data/gpdb_p4/gpseg3/./gp_dump_0_5_20110419154139.gz: Succeeded
segment 2 (dbid 4) Host sdw2 Port 50002 Database sales_history BackupFile /data/gpdb_p3/gpseg2/./gp_dump_0_4_20110419154139.gz: Succeeded
segment 1 (dbid 3) Host mdw Port 50001 Database sales_history BackupFile /data/gpdb_p2/gpseg1/./gp_dump_0_3_20110419154139.gz: Succeeded
segment 0 (dbid 2) Host mdw Port 50000 Database sales_history BackupFile /data/gpdb_p1/gpseg0/./gp_dump_0_2_20110419154139.gz: Succeeded
Master (dbid 1) Host mdw Port 5432 Database sales_history BackupFile /data/gpmaster/gpseg-1/./gp_dump_1_1_20110419154139.gz: Succeeded
gp_dump utility finished successfully.
在master上
一方面可以看到报告文件，所有文件都有一个含有时间戳信息的14位编码，这个编码是将来恢复时选择备份的关键字，并且保证了每个段备份的一致性。
gp_dump_20110419154139.rpt 它提供所有段的备份情况
gp_dump_status_1_1_20110419154139 提供master的备份过程信息。
gp_cdatabase_1_1_20110419154139 提供了创建数据库的句法信息。
gp_dump_1_1_20110419154139.gz master具体的备份数据。
在segment上，只有两个文件
gp_dump_status_0_2_20110419154139 提供了特定段备份的过程信息。
gp_dump_0_2_20110419154139.gz 特定段的备份数据
对应gp_dump的备份需要通过gp_restore进行并行恢复。具体用法如下
gp_restore [OPTIONS]
常用选项
-d, --dbname=NAME 指定数据库名称
-i, --ignore-version 即使服务版本不匹配，忽略版本信息。
-v, --verbose 用verbose模式. 并向每个段的状态文件中添加这些信息
--help 显示帮助然后退出
--version 输出版本信息，然后退出
控制输出内容的选项
-a, --data-only 只恢复数据
-c, --clean 创建之前，删除schema
-s, --schema-only 只恢复schema定义
连接选项
-h, --host=HOSTNAME 指定数据库服务主机名或者socket目录
-p, --port=PORT 指定连接端口号
-U, --username=NAME 指定连接的用户
-W, --password 强制口令提示
Greenplum 特有选项
--gp-c 如果备份时是压缩格式，必须恢复使用该选项解压
--gp-d=BACKUPFILEDIR 指定备份文件目录，默认就是数据目录。
--gp-i 忽略错误
--gp-k=KEY 指定备份14位时间戳信息，必须指定。
--gp-r=REPORTFILEDIR 指定报告存放目录
--gp-l=FILELOCATIONS 指定备份文件是在所有主段（p),还是特定的主段上。
比如刚才的备份进行恢复测试
我们可以先删除数据库sales_history
template1=# drop database sales_history;
DROP DATABASE
template1=# \l
List of databases
Name | Owner | Encoding | Access privileges
-----------+---------+----------+---------------------
postgres | gpadmin | UTF8 |
template0 | gpadmin | UTF8 | =c/gpadmin
: gpadmin=CTc/gpadmin
template1 | gpadmin | UTF8 | =c/gpadmin
: gpadmin=CTc/gpadmin
xjods | gpadmin | UTF8 |
(4 rows)
下面进行恢复，再恢复之前，必须先重建数据库。这可以自己用命令创建，或者使用master上备份时产生脚本进行数据库的重新创建，比如
gpadmin@mdw:/data/gpmaster/gpseg-1> psql -d template1 -f gp_cdatabase_1_1_20110419154139
CREATE DATABASE
完成数据库创建之后，才能进行数据恢复。
gpadmin@mdw:~> gp_restore -d sales_history --gp-k=20110419154139 --gp-c
20110419:16:05:19|gp_restore-[INFO]:-Analyzed command line options.
20110419:16:05:19|gp_restore-[INFO]:-Connecting to master segment on host localhost port 5432 database sales_history.
20110419:16:05:19|gp_restore-[INFO]:-Reading Greenplum Database configuration info from master segment database.
20110419:16:05:19|gp_restore-[INFO]:-Preparing to restore the following segments:
20110419:16:05:19|gp_restore-[INFO]:-Segment 3 (dbid 5)
20110419:16:05:19|gp_restore-[INFO]:-Segment 2 (dbid 4)
20110419:16:05:19|gp_restore-[INFO]:-Segment 1 (dbid 3)
20110419:16:05:19|gp_restore-[INFO]:-Segment 0 (dbid 2)
20110419:16:05:19|gp_restore-[INFO]:-Master (dbid 1)
20110419:16:05:19|gp_restore-[INFO]:-Starting to restore the master database.
20110419:16:05:19|gp_restore-[INFO]:-Creating thread to restore master database: host mdw port 5432 database sales_history
20110419:16:05:19|gp_restore-[INFO]:-Listening for messages from dbid 1 server (source) for dbid 1 restore
20110419:16:05:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 1 to restore dbid 1
20110419:16:05:21|gp_restore-[INFO]:-restore started for source dbid 1, target dbid 1 on host mdw
20110419:16:06:19|gp_restore-[INFO]:-restore succeeded for source dbid 1, target dbid 1 on host mdw
20110419:16:06:19|gp_restore-[INFO]:-Successfully restored master database: host mdw port 5432 database sales_history
20110419:16:06:19|gp_restore-[INFO]:-Creating thread to restore dbid 5 (sdw2:50003) from backup file on dbid 5 (sdw2:50003)
20110419:16:06:19|gp_restore-[INFO]:-Creating thread to restore dbid 4 (sdw2:50002) from backup file on dbid 4 (sdw2:50002)
20110419:16:06:19|gp_restore-[INFO]:-Creating thread to restore dbid 3 (mdw:50001) from backup file on dbid 3 (mdw:50001)
20110419:16:06:19|gp_restore-[INFO]:-Creating thread to restore dbid 2 (mdw:50000) from backup file on dbid 2 (mdw:50000)
20110419:16:06:19|gp_restore-[INFO]:-Waiting for all remote gp_restore_agent programs to finish.
20110419:16:06:19|gp_restore-[INFO]:-Listening for messages from dbid 5 server (source) for dbid 5 restore
20110419:16:06:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 5 to restore dbid 5
20110419:16:06:19|gp_restore-[INFO]:-Listening for messages from dbid 4 server (source) for dbid 4 restore
20110419:16:06:19|gp_restore-[INFO]:-Listening for messages from dbid 2 server (source) for dbid 2 restore
20110419:16:06:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 2 to restore dbid 2
20110419:16:06:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 4 to restore dbid 4
20110419:16:06:19|gp_restore-[INFO]:-Listening for messages from dbid 3 server (source) for dbid 3 restore
20110419:16:06:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 3 to restore dbid 3
20110419:16:06:22|gp_restore-[INFO]:-restore started for source dbid 3, target dbid 3 on host mdw
20110419:16:06:22|gp_restore-[INFO]:-restore started for source dbid 4, target dbid 4 on host sdw2
20110419:16:06:22|gp_restore-[INFO]:-restore started for source dbid 2, target dbid 2 on host mdw
20110419:16:06:22|gp_restore-[INFO]:-restore started for source dbid 5, target dbid 5 on host sdw2
20110419:16:06:26|gp_restore-[INFO]:-restore succeeded for source dbid 3, target dbid 3 on host mdw
20110419:16:06:26|gp_restore-[INFO]:-restore succeeded for source dbid 5, target dbid 5 on host sdw2
20110419:16:06:26|gp_restore-[INFO]:-restore succeeded for source dbid 2, target dbid 2 on host mdw
20110419:16:06:26|gp_restore-[INFO]:-restore succeeded for source dbid 4, target dbid 4 on host sdw2
20110419:16:06:26|gp_restore-[INFO]:-All remote gp_restore_agent programs are finished.
20110419:16:06:26|gp_restore-[INFO]:-updating Append Only table statistics
20110419:16:06:27|gp_restore-[INFO]:-Report results also written to /data/gpmaster/gpseg-1/gp_restore_20110419154139.rpt.
Greenplum Database Restore Report
Timestamp Key: 20110419154139
gp_restore Command Line: -d sales_history --gp-k=20110419154139 --gp-c
Pass through Command Line Options: None
Compression Program: gunzip
Individual Results
Restore of sales_history on dbid 1 (mdw:5432) from /data/gpmaster/gpseg-1/./gp_dump_1_1_20110419154139.gz: Succeeded
Restore of sales_history on dbid 5 (sdw2:50003) from /data/gpdb_p4/gpseg3/./gp_dump_0_5_20110419154139.gz: Succeeded
Restore of sales_history on dbid 4 (sdw2:50002) from /data/gpdb_p3/gpseg2/./gp_dump_0_4_20110419154139.gz: Succeeded
Restore of sales_history on dbid 3 (mdw:50001) from /data/gpdb_p2/gpseg1/./gp_dump_0_3_20110419154139.gz: Succeeded
Restore of sales_history on dbid 2 (mdw:50000) from /data/gpdb_p1/gpseg0/./gp_dump_0_2_20110419154139.gz: Succeeded
gp_restore utility finished successfully.
GREENPLUM备份恢复机制类似oracle数据库的逻辑备份概念。基本上可以满足传统数据仓库对备份恢复的要求。但是GREENPLUM备份工具仍然存在局限性，比如无论是全库备份还是对象级别的备份只能是完全备份，而不支持增量备份。备份虽然是联机备份，但是在备份过程中会在备份的对象上加排他锁，从而影响系统的DML操作。当然，这些问题可以通过对大表进行分区的方式，进行一定的缓解。我们还是希望EMC在将来的版本上可以对GP的备份工具进行改进，使其更加完善好用。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25548387/viewspace-692867/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/25548387/viewspace-692867/
775
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
