PostgreSQL增量备份

首先了解下什么是增量备份，按照百度百科Copy如下：

增量备份

　　增量备份是针对于上一次备份（无论是哪种备份）：备份上一次备份后，所有发生变化的文件。

　　（增量备份过程中，只备份有标记的选中的文件和文件夹，它清除标记，既：备份后标记文件，换言之，清除存档属性。）说白了就是：只备份当天有变化的数据，并且是带标记的数据，当备份完后还要清除标记，总之他占用空间小，恢复起来麻烦。

　　在Windows中一般都有三种备份种类：完全备份、差异备份、增量备份。

　　完全备份：备份全部选中的文件夹，并不依赖文件的存档属性来确定备份那些文件。（在备份过程中，任何现有的标记都被清除，每个文件都被标记为已备份，换言之，清除存档属性）。

　　差异备份：差异备份是针对完全备份：备份上一次的完全备份后发生变化的所有文件。（差异备份过程中，只备份有标记的那些选中的文件和文件夹。它不清除标记，既：备份后不标记为已备份文件，换言之，不清除存档属性）说白了就是：差异将把前一次的数据都备份，一定要搞清是前一次的，另外他不管有没有打过标记他都备份，总之好恢复但太占空间。

　　不同备份类型可以存在一定组合，下面的示例供您参考：

　　完全备份和差异备份

　　在星期一进行完全备份，在星期二至星期五进行差异备份。如果在星期五数据被破坏了，则你只需要还原星期一完全的备份和星期四的差异备份。这种策略备份数据需要较多的时间，但还原数据使用较少的时间。

　　完全备份和增量备份

　　在星期一进行完全备份，在星期二至星期五进行增量备份。如果在星期五数据被破坏了，则你需要还原星期一正常的备份和从星期二至星期五的所有增量备份。这种策略备份数据需要较少的时间，但还原数据使用较多的时间。

 

增量备份 PostgreSQL
一、介绍
   PITR 的全称是 Point In Time Recovery, 它结合文件系统级备份 WAL 日志文件, 达
   到增量备份 PostgreSQL 数据库系统.
   WAL 的全称是 Write Ahead Log, 它记录着数据库修改数据文件的每一个动作. 如果
   系统挂了, 读入这些日志文件可以很方便快捷安全的恢复数据.
   要知道的是, PITR 备份不只是备份一张或几张表, 它是完全的备份, 不管是表、存储
   过程等. 它几乎是把原来的数据库系统做了一次克隆. 也就是说, 这种备份让我们无需
   关心数据库系统中有几个数据库, 每个数据库中又有些什么数据, 不用像 pg_dump 要
   指定数据库名称, 也不用像 slony 那样在配置文件中指定表, 还得是有主键的表.
   别幻想什么东西都是十全十美的, PITR 不是全能的. 它不能做 "高可用", 即 Master
   和 Slave 的东东, 它也不能做 "负载均衡". 如果你一定要这些东西, 可以配合其他软
   件实现.
   OK, 唠叨许多废话. 嗯... 说明你很有耐心, 呵呵!!!
二、设置及操作
   实现 PITR 备份方案, 接下来我们说说设置、备份及恢复.
   * 设置
   建立备份目录. 备份分基线 (baseline) 和日志备份, 所以我们要建立两个目录:
       mkdir -p /opt/bubase
       mkdir -p /opt/buxlog
   接着我们设定一些环境变量及备份所在目录:
       export PGDATA=/home/postgres/pgdata
       export BUBASE=/opt/bubase
       export BUXLOG=/opt/buxlog
   设置完上面那些变量后, 编辑 $PGDATA/postgresql.conf 文件, 设置如下:
       archive_mode = on
       archive_command = 'cp %p /opt/buxlog/%f'
   OK, 所有设置都完成了, 启动或重启 PostgreSQL 服务.
   * 备份
   备份是有顺序的, 先做基线备份, 然后备份日志.
   基线备份命令如下:
       psql -d template1 -c "select PG_START_BACKUP('backup baseline')"
       cp -R $PGDATA/* $BUBASE
       psql -d template1 -c "select PG_STOP_BACKUP()"
   基线备份好后, 就可以时不时的备份日志了, 命令如下:
       cp -R $PGDATA/pg_xlog/* $BUXLOG
  
   日志备份尽可能的频繁一些. 因为当线上提供服务的所在磁盘坏掉, 而你又没有备份
   WAL 日志, 你会丢数据.
   * 恢复
   哎呀, 线上提供服务的 PostgreSQL 宕了。不怕、不怕, 我们这不是有备份嘛, 嚯嚯!
   嘎嘎, 不小心又弄来一台新机器(YY 中... 假设一下啦), 那我们把 baseline 的备份
   弄过来, 不管你用哪种方法. 拟定也放在 /home/postgres/pgdata 目录下.
   接着呢, 为了避免恢复还响应连接请求什么的, 我们把服务只开启本地连接, 修改
   $PGDATA/postgresql.conf 文件:
       listen_addresses = 'localhost'
   再下来, 在 $PGDATA 目录下创建一个 recovery.conf 文件. PostgreSQL 启动的时候
   如果发现 $PGDATA 目录里面有这个文件就会进入恢复模式, 恢复完后会把这个文件重
   命名为 recovery.done. 文件内容只有一行, 如下:
       restore_command='cp /opt/buxlog/%f %p'
   注意这里是单引号, 别用双引号, 不然会提示错误.
   关键时刻了, 启动数据库:
       pg_ctl start -D $PGDATA -l /tmp/pg.log
   这个时候观察 /tmp/pg.log 文件, 会发现正在恢复一堆一堆、一坨一坨的 WAL 日志文
   件。
   最后, 恢复完后, 再把 $PGDATA/postgresql.conf 文件中的 listen_addresses 改回
   原来的模样。重启:
       pg_ctl restart -D $PGDATA -l /tmp/pg.log
   嚯嚯, 大功告成！！！
四、脚本化及自动化
   个人觉着这些步骤还是很繁琐的, 可以编写个什么脚本之类的, 把脚本放进 crontab
   里面, 较比的省心.
   脚本如何写, 我就不献丑了. 不过, 这里需要说明一下的是, baseline 备份的频繁度
   会影响你恢复的速度. 为什么这么说呢, 因为每次备份 baseline, 恢复的时候也就恢
   复这次备份 baseline 以后的所有修改数据库数据文件的 WAL 就可以了，相信这是很
   好理解的.
以上所有的设置或测试都是基于 PostgreSQL 8.3.1 版本的.