私はあなたが書いたものについて考えました、そしてここにあなたのためのいくつかのアイデアがあります：
- ある時点で実際に一貫性のあるバックアップが必要な場合は、pg_basebackupまたはpg_barman（内部ではpg_basebackupを使用）を使用する必要があります。説明は以下の1.リンクにあります。最新のpg_basebackup10はWALログをストリーミングするため、バックアップ中に行われたすべての変更もバックアップします。もちろん、このバックアップはPGインスタンス全体のみを取ります。一方、テーブルはロックされません。また、リモートインスタンスから実行すると、PGインスタンスのCPU負荷が小さくなり、ディスクIOが一部のテキストで示唆されているほど大きくなりません。私の経験についてはリンク4を参照してください。復元は非常に簡単です。リンク5を参照してください。
- pg_dumpを使用する場合は、バックアップがその時点で実際に一貫しているという保証がないことを理解する必要があります。ここでもリンク1を参照してください。データベースのスナップショットを使用する可能性があります（リンク2および3を参照）。それでも、100％の一貫性を期待することはできません。 pg_dumpは、1日あたり1回だけ新しいものをロードする分析データベース（昨日は本番データベースからのパーティション）でのみ使用しました。並列オプションで高速化できます（ディレクトリバックアップ形式でのみ機能します）。ただし、欠点はPGインスタンスの負荷がはるかに高いことです。つまり、CPU使用率が高くなり、ディスクIOがはるかに高くなります。 pg_dumpをリモートで実行している場合でも、そのような場合は、バックアップファイルを保存するためにディスクIOのみを保存します。さらに、pg_dumpは、テーブルに読み取りロックを設定して、新しい挿入またはレプリケーション（レプリカで取得された場合）と照合できるようにする必要があります。ただし、データベースが数百GBに達すると、並列ダンプでも数時間かかる可能性があり、その瞬間にpg_basebackupに切り替える必要があります。
- pg_barmanはpg_basebackupの「快適なバージョン」です+PGインスタンスが非常にひどくクラッシュした場合でもデータの損失を防ぐことができます。動作するように設定するには、さらに変更が必要ですが、それだけの価値はあります。 WALログアーカイブを設定する必要があり（リンク6を参照）、PGが10未満の場合は、「max_wal_senders」と「max_replication_slots」（とにかくレプリケーションに必要）を設定する必要があります。正確には素晴らしいとは言えません。 pg_barmanは、バックアップ間でもWALレコードをストリーミングおよび保存するため、非常にひどいクラッシュが発生した場合のデータ損失はほとんどありません。しかし、説明が正確に適切ではないため、機能させるには何時間もかかる場合があります。 pg-barmanは、そのコマンドを使用してバックアップと復元の両方を実行します。
データベースは5GBの大きさなので、どのバックアップ方法でもすばやく実行できます。ただし、ポイントインタイムリカバリが必要で、データ損失がほぼゼロであるかどうかを判断する必要があります。したがって、pg-barmanの設定に時間を費やすかどうかを決定する必要があります。
リンク：
- PostgreSQL、バックアップ、その他すべて知っておく必要があります
- 論文のレビュー：14-シリアル化可能PostgreSQLでのスナップショットアイソレーション -スナップショットについて
- データベースの並列ダンプ -スナップショットの使用方法の例
- pg_basebackup experiencies
- pg_basebackup-tarバックアップの復元
- スクリプトを使用したWALログのアーカイブ