「Postgresでのバックアップの回復を加速する」という記事の最初の部分で、ローカル環境での回復時間を短縮するためにとった手順について話しました。 シンプルなものから始めました：pg_dump-drank（そのような単語はありますか？）、gzipで圧縮され、解凍され、出力をpsql < file.sql 。 回復するのに約30分かかりました。 最終的に、 カスタムPostgres形式に落ち着き、 -j引数を適用して、時間を16分に短縮しました。
この記事では、バックアップファイルのサイズを削減する方法を説明しました。これにより、回復プロセスがさらに加速されました。
バックアップのサイズを調べる
リカバリプロセスを高速化する試みについて書き始めたとき、パックされたバックアップファイルのサイズは約2 GB（アンパック-30 GB）でした。 それ以降、ベースはほぼ2倍になりました（パック-3.7 GB、アンパック-68 GB）。 これにより、リカバリ時間が大幅に増加しただけでなく、バックアップファイルのコピー/転送に時間がかかりました。
バックアップファイルが2倍になったことに気付き、これがなぜ起こったのか、どのデータが原因であるのかを見つけ始めました。
最初に、データベースのサイズを見つけました。
次に、テーブルのサイズを調べて、ベースの成長に明らかな原因があるかどうかを調べることにしました。
このリストは、データベース全体の60％以上を占める上位3つのテーブルが、開発環境には不要な履歴またはログを参照していることを明確に示しています。 インデックス（それぞれ17 GB、1 GB、1.5 GB）とともに、これらのテーブルはデータベースの89％を占有します。 これについて、テーブルのサイズの調査を停止し（89％の削減は許容可能と見なされます）、バックアップからテーブルを除外できるかどうかを確認することにしました。
バックアップのサイズを小さくする
問題に対処し始めて、私は最初にドキュメントに精通するようにします。 PostgreSQLプロジェクトはこの点で素晴らしい仕事をしましたpg_dumpセクションを数分間読んだ後、必要なものを正確に見つけました。
pg_dump dbname -Fc \ --exclude-table-data 'logging*' \ --exclude-table-data 'reversions*' \ --exclude-table-data 'webhooks_logging*' > postgres.dev.sql
*（アスタリスク）はここでワイルドカードとして使用され、これらのテーブルからもインデックスを除外するのに役立ちます。
--exclude-table-dataパラメーターで除外テーブルを指定すると、バックアップファイルのサイズが3.7 GB（非圧縮-68 GB）から0.7 GB（非圧縮-5.4 GB）に縮小されました。
リストを見て、結果が単純にすばらしいことを確認できます。
宛先：
$ pg_restore -d db -j 8 dumpfc.gz real 16m49.539s user 1m1.344s sys 0m39.522s
後：
$ pg_restore -d db -j 8 devfc.gz real 5m38.156s user 0m24.574s sys 0m13.325s
3つのテーブルを除外することで、データベースのサイズを89％削減し、復旧を66％スピードアップできました！ 覚えているなら、最初の部分では32.5分から始めました。 リカバリ時間を26.9分または87％短縮できたことがわかりました。
この記事の結果に基づいて、回復を16分から5分に加速しました。 これにより、年間57時間の復旧時間が節約されます（6人の開発者が11分間で年間52回） 。 合計で、復旧の待ち時間を130時間短縮しました。
おわりに
PostgreSQLのドキュメントに戻ると、回復プロセスを高速化する方法がいくつかあることに注意してください。 たとえば、 pg_dump -jパラメーターを確認する必要があります。これにより、バックアップ時間を短縮できます（PostgreSQL 9.3以降で使用可能）。 また、 autocommitオフにし、 maintenance_work_mem大幅に増やして、より高いmax_wal_sizeを設定することもmax_wal_sizeます。
現時点では、ローカル開発環境でのデータベースのバックアップのリカバリ時間は非常に良好です。
参照：
- オリジナル： Postgresリストアパート2の高速化（リストアにかかる時間を半分に短縮するだけでは十分ではなかったため） 。
- Postgresのバックアップのリカバリを高速化します。 パート1