转储Postgres DB，时间和.sql文件的权重

我有一个大数据库（nominatim db，用于地址地理编码反向），大约是408gb。

现在，为了向客户提供估计，我想知道导出/重新导入过程将花费多长时间，.sql转储文件将有多大。我的postgresql版本是9.4，安装在具有16GB RAM和500GB磁盘空间的centOS 6.7虚拟机上。

你能帮助我吗？

谢谢大家的回答，无论如何还原转储的数据库，我不使用命令，pg_restore但是psql -d newdb -f dump.sql（我在官方文档中以这种方式阅读）。这是因为我必须在另一台机器上设置此数据库，以避免nominatim db索引过程！我不知道是否有人知道nominatim（openstreetmap开源产品），但是在具有16gb ram的CentOS 6.7机器中，欧洲地图的数据库索引过程（15.8 gb）使我花了32天的时间……比另一个可能的问题是：pg_restore等于psql -d -f？速度更快？

再次感谢

正如@a_horse_with_no_name所说，没有人能够为您的环境提供确切的答案。但这是我用来估算的过程。

通常，我发现我的数据的压缩备份是实时数据库大小的1/10或更小。通常，您还可以从备份大小中减去索引的磁盘大小。检查数据库中事物的大小，以获得更好的主意。您也可以尝试形成数据库的子集，该子集要小得多，然后将实时大小与压缩备份进行比较。这可能会给您带来应有的比率。SQL文件比较复杂，压缩效果很好。尽管Postgres使用的磁盘表示似乎更加轻松。性能价格可能。

估计时间的最佳方法是进行一些探索性的运行。以我的经验，这通常比您预期的花费更长的时间。我有一个大约1 TB的数据库，我敢肯定它会花大约一个月的时间来恢复，但是它也被积极地索引了。我有大约20 GB的数据库，大约15分钟即可备份/还原。因此，它非常可变，但是索引会增加时间。如果可以设置类似的服务器，则可以尝试备份-还原过程，并查看将花费多长时间。无论如何，我建议这样做，只是为了建立信心，并在扣动扳机之前解决所有挥之不去的问题。

我还建议您尝试使用pg_dump的“自定义格式”（pg_dump -Fc），以使压缩归档文件易于pg_restore使用。