使用永久磁盘时备份 PostgreSQL 的安全方法
Safe way to backup PostgreSQL when using Persistent Disk
我正在尝试为 运行 在 Google Compute Engine 上的 PostgreSQL 实例设置每日备份（使用永久磁盘快照），其数据目录位于永久磁盘上。
现在，根据 Persistent Disk Backups 博客 post，我应该：
- 停止我的应用程序 (PostgreSQL)
fsfreeze 我的文件系统以防止进一步修改并将挂起的块刷新到磁盘- 拍摄永久磁盘快照
- 解冻我的文件系统
- 启动我的应用程序 (PostgreSQL)
这显然会带来一些停机时间（在我的测试中，每个步骤从几秒到几分钟不等），我想避免或至少尽量减少。
博客 post 的步骤被标记为确保快照一致的必要步骤（我假设在文件系统级别），但我对干净的文件系统不感兴趣，我有兴趣能够从这样的快照恢复我的 PostgreSQL 实例中的所有数据。
PostgreSQL uses fsync when committing, so all data which PostgreSQL acknowledges as committed has made its way to the disk already (fsync goes to the disk).
出于本次讨论的目的，我认为比较没有停止PostgreSQL和没有使用fsfreeze 磁盘上的文件系统刚刚经历了意外断电。
阅读 https://wiki.postgresql.org/wiki/Corruption and http://www.postgresql.org/docs/current/static/wal-reliability.html 后，我的理解是所有提交的数据都应该在意外断电时幸存下来。
我的问题是：
我与意外停电的比较是否准确，还是我遗漏了什么？
我可以在不停止 PostgreSQL 且不使用 fsfreeze 的情况下拍摄快照吗？还是我错过了一些副作用？
如果以上问题的答案是我不应该只拍摄快照，那么创建另一个永久磁盘是否符合惯例，定期使用 pg_dumpall(1) 转储整个数据库并然后快照另一个永久磁盘？
1) 是的，不过拍摄快照应该更安全。 fsfreeze 的东西真的是 100% 安全的（轶事：我从来没有在我的 PD 上使用 fsfreeze 并且没有 运行 遇到问题）
2) 是的，但不能 100% 保证它始终有效（偏执的解决方案：拍摄快照，使用该快照启动临时 VM，检查磁盘是否正常，然后删除 VM。这可以自动化）
3) 不，我不会推荐快照。这将花费更多时间，可能会降低您的数据库性能，如果在转储过程中发生某些事情会怎样？此外，PD 对于增量备份来说非常昂贵。快照是不同的，因此您不必为每个副本（仅第一个）支付整个磁盘的费用，只需更改即可。
可能的推荐：
执行#3，然后创建新 PD 的快照，然后删除 PD。
https://cloud.google.com/compute/docs/disks/persistent-disks#creating_snapshots 最近更新了，现在包括这个新段落：
If you skip this step, only data which was successfully flushed to disk by the application will be included in the snapshot. The application experiences this scenario as if it was a sudden power outage.
所以我原来问题的答案是：
- 是
- 是
- N/A，因为②的答案是肯定的
我正在尝试为 运行 在 Google Compute Engine 上的 PostgreSQL 实例设置每日备份（使用永久磁盘快照），其数据目录位于永久磁盘上。
现在，根据 Persistent Disk Backups 博客 post，我应该：
- 停止我的应用程序 (PostgreSQL)
fsfreeze我的文件系统以防止进一步修改并将挂起的块刷新到磁盘- 拍摄永久磁盘快照
- 解冻我的文件系统
- 启动我的应用程序 (PostgreSQL)
这显然会带来一些停机时间（在我的测试中，每个步骤从几秒到几分钟不等），我想避免或至少尽量减少。
博客 post 的步骤被标记为确保快照一致的必要步骤（我假设在文件系统级别），但我对干净的文件系统不感兴趣，我有兴趣能够从这样的快照恢复我的 PostgreSQL 实例中的所有数据。
PostgreSQL uses fsync when committing, so all data which PostgreSQL acknowledges as committed has made its way to the disk already (fsync goes to the disk).
出于本次讨论的目的，我认为比较没有停止PostgreSQL和没有使用fsfreeze 磁盘上的文件系统刚刚经历了意外断电。
阅读 https://wiki.postgresql.org/wiki/Corruption and http://www.postgresql.org/docs/current/static/wal-reliability.html 后，我的理解是所有提交的数据都应该在意外断电时幸存下来。
我的问题是：
我与意外停电的比较是否准确，还是我遗漏了什么？
我可以在不停止 PostgreSQL 且不使用
fsfreeze的情况下拍摄快照吗？还是我错过了一些副作用？如果以上问题的答案是我不应该只拍摄快照，那么创建另一个永久磁盘是否符合惯例，定期使用
pg_dumpall(1)转储整个数据库并然后快照另一个永久磁盘？
1) 是的，不过拍摄快照应该更安全。 fsfreeze 的东西真的是 100% 安全的（轶事：我从来没有在我的 PD 上使用 fsfreeze 并且没有 运行 遇到问题）
2) 是的，但不能 100% 保证它始终有效（偏执的解决方案：拍摄快照，使用该快照启动临时 VM，检查磁盘是否正常，然后删除 VM。这可以自动化）
3) 不，我不会推荐快照。这将花费更多时间，可能会降低您的数据库性能，如果在转储过程中发生某些事情会怎样？此外，PD 对于增量备份来说非常昂贵。快照是不同的，因此您不必为每个副本（仅第一个）支付整个磁盘的费用，只需更改即可。
可能的推荐：
执行#3，然后创建新 PD 的快照，然后删除 PD。
https://cloud.google.com/compute/docs/disks/persistent-disks#creating_snapshots 最近更新了，现在包括这个新段落：
If you skip this step, only data which was successfully flushed to disk by the application will be included in the snapshot. The application experiences this scenario as if it was a sudden power outage.
所以我原来问题的答案是：
- 是
- 是
- N/A，因为②的答案是肯定的