如何在频繁的postgres备份场景中最小化带宽？

我正在寻找非常频繁的备份（每小时）postgres数据在几个虚拟机（比如说20-50）对同一个档案服务器。

这里有更多的数据，如果需要的话：理想情况下，系统应该支持所有虚拟机上的80到200个数据库的负载。数据库很小（从10MB到100MB）到中等大小（500MB – 2GB），由百分之一表组成，这些表中的一小部分可以很容易地包含数千行，高达大约一百万行。对数据库的更改通常是新logging，有些更新，没有太多的删除。带宽将是100Mbits / s。

正如我已经使用增量备份（ rsync ）的标准文件系统这样做，我想知道是否可以通过postgres数据库备份实现类似的东西。

我有几个可能的select：

我可以select把数据库放在可快照的文件系统上（ aufs docker style， ZFS ， btrfs ，但是其中一些看起来确实减慢了postgres的速度）。
如果需要，我准备好使用WAL
如果需要的话，只能在数据库级别进行备份会更好。因为我不需要备份整个postgres数据，只有客户数据库。
我在postgres服务器上有一些可以保留中间备份的磁盘空间。
我可以在虚拟机上承担一些合理的CPU工作负载，但是宁愿在备份服务器上最小化它，因为它会增加更多的数据库来备份。
我并不是在寻找连续备份或PITR恢复选项。我的备份服务器有一个基于文件的系统（brfs）来执行高效的备份定期快照。这很好。

我想过：

在SQL中使用rsync与pg_dump本地组合到服务器，但是我不确定我应该使用哪种不同的格式来保持最高的效率。
使用可快照的文件系统，允许在块级别上发送二进制差异（btrfs和ZFS擅长），使用或不使用本地转储（关于要使用的备份格式相同的问题）。
我已经知道了pg_rman的存在，我不知道它是否可以依赖，设置和各种过程似乎比pg_dump稍重。它会支持只有增量备份吗？我们可以在备份方面有一个实际的格式吗？

还有增量备份达到小带宽的另一种方式吗？

那么… 我怎么能在我的postgres备份scheme中将带宽缩小 ？

你试图用一个尴尬的解决scheme来解决一个实践中的问题（在真正的数据库系统中）对于大多数来自小型数据库系统背景的人来说，这是可以理解的（而且我自己和MySQL做了一个非常类似的事情，并且因为带宽爆发而淹没了它）。

你应该使用PostgreSQL的复制function; 请参阅http://www.postgresql.org/docs/9.3/interactive/high-availability.html

以sql格式进行转储。让本地虚拟机保持一个完整的副本，可以说每天刷新。然后转储新的副本，并从完整副本作出差异。每天复制一次全文，只有在其他时间进行比较。要恢复你将不得不补丁与完整的副本，并执行SQL文件。