PostgreSQLデータベースバックアップの設定手順を解説「保存版」

目次：

• はじめに：なぜPostgreSQLデータベースのバックアップが必要なのか？
• 実践！PostgreSQLバックアップの設定手順
  方法1：pg_dumpによる論理バックアップの使用
  方法2：pg_basebackupによる物理バックアップの設定
  方法3：PITRによるアーカイブバックアップの手順
  方法4：MultCloudによる自動バックアップの実行
• まとめ
• よくある質問

はじめに：なぜPostgreSQLデータベースのバックアップが必要なのか？

「バックアップは面倒」「まだ一度も障害が起きたことがない」――そんな油断が、あなたの大切なデータを一瞬で奪い去ります。ハードウェアの故障、人為的な削除ミス、ランサムウェア攻撃など、障害のリスクはいつ訪れてもおかしくありません。だからこそ、信頼性の高いPostgreSQLデータベースバックアップの仕組みを今のうちに構築しておくことが、運用の要となるのです。

では、具体的になぜPostgreSQLに特化したバックアップ戦略が必須なのでしょうか。以下の3つの観点から明確にお答えします。

• ダウンタイムゼロを実現するオンラインバックアップ：24時間稼働が当たり前の現代システムでは、停止を伴うバックアップは現実的ではありません。PostgreSQLのオンラインバックアップを使えば、サービスを止めずに一貫性のあるスナップショットを取得できます。これにより、ユーザー影響ゼロで常に復旧ポイントを確保できます。
• 人的ミスを防ぐ自動バックアップの仕組み：意図しない削除や更新は、いつ誰にでも起こり得ます。手動運用では漏れや遅れが生じるため、PostgreSQLの自動バックアップを日次で実行することが必須です。自動化によって「実行忘れ」をなくし、確実な世代管理が初めて実現します。
• コスト効率の良いクラウドバックアップで災害対策：オンプレミスのみの保管は、物理災害に対して脆弱です。PostgreSQLのクラウドバックアップ（S3互換ストレージなど）を導入すれば、オフサイト保管が低コストで実現し、リストア時の柔軟性も向上します。

このように、PostgreSQLのDBをバックアップする戦略は「単なるお守り」ではなく、「ビジネスの信頼性を支える根幹」です。本記事では、基礎的なpg_dumpから物理バックアップ、さらに自動化やクラウド連携に至るまで、実践的な設定手順を失敗事例を交えながらわかりやすく解説していきます。

実践！PostgreSQLバックアップの設定手順

ここからは、実際のコマンドラインを使った設定手順に移ります。バックアップ手法は運用規模や求める復旧精度に応じて段階的に進化させていくのが鉄則です。各手法を組み合わせることで、PostgreSQLデータベースのバックアップ全体の信頼性が飛躍的に高まりますので、ぜひご自身の環境に合わせて読み進めてください。

方法1：pg_dumpによる論理バックアップの使用

pg_dumpは、データベース内のスキーマやデータをSQL文や専用形式ファイルにエクスポートする、最もシンプルな論理バックアップツールです。特定のテーブルだけを救出したい場合や、異なるバージョン・OS間でのデータ移行に優れています。

✅ 実際にpg_dumpを使ったバックアップは、以下の基本コマンドで実行できます。

pg_dump -U ユーザー名 -h ホスト名 -p ポート番号 -d データベース名 > バックアップファイル.sql

• -U：接続ユーザー名
• -h：データベースのホストアドレス
• -p：接続ポート番号（デフォルトは5432）
• -d：バックアップ対象のデータベース名

例えば、「mydb」というデータベースをユーザー「postgres」でバックアップする場合、コマンドは次のようになります。

pg_dump -U postgres -h 127.0.0.1 -p 5432 -d mydb > mydb_backup.sql

このコマンドを実行すると、mydb_backup.sqlというファイルが生成されます。これがあなたのPostgreSQL DBバックアップの実体です。このファイルはテキストエディタで開くことができ、中にはデータベースを再構築するためのSQL文が網羅されています。

このような論理バックアップの最大の特徴は、データベース内部の構造を「SQLという共通言語」に変換して保存する点にあります。そのため、PostgreSQLのバックアップとしての移植性が非常に高く、異なるバージョンや異なるOS間でも、生成されたSQLファイルを実行するだけで同じデータベースを再現できます。特に、中小規模のデータベースや、特定のテーブルだけを選択的にバックアップしたい場合に最適な手法です。

ただし、データベースサイズが数百GB〜TB単位に達するような大規模環境では、論理バックアップは処理に長い時間を要し、復元時にもすべてのSQLを最初から実行する必要があるため、速度面で課題が生じます。

方法2：pg_basebackupによる物理バックアップの設定

pg_basebackupは、データベースクラスタ全体をファイルシステムレベルで丸ごと複製する物理バックアップツールです。大量のデータも高速にコピーでき、何よりPostgreSQLのオンラインバックアップを実現するpg_basebackupなら、稼働中でも全体を丸ごとコピーできるため、ダウンタイムが一切発生しません。

以下の基本構文で実行します。

pg_basebackup -D 出力ディレクトリ [オプション]

主なオプションは次のとおりです。

オプション	説明
Dディレクトリ	バックアップファイルの出力先パスを指定（必須）
-F pまたは-F t	出力形式：p（plain：ディレクトリ構造そのまま）または t（tar：1つのtarアーカイブにまとめる）
-P	バックアップの進行状況（パーセント）を表示
-v	詳細なログ（verboseモード）を出力
-Uユーザー名	データベース接続ユーザーを指定
-hホスト	データベースサーバーのホストアドレスを指定
-pポート	データベースサーバーのポート番号を指定（デフォルトは5432）
-Z 0〜9	圧縮レベル（tar形式の場合のみ有効）。数値が大きいほど圧縮率が高まる
-R	standby.signalファイルを生成し、レプリケーションスタンバイサーバー構築に利用
-X streamまたは-X fetch	WALログの転送方式を指定。stream（ストリーミング）が推奨され、バックアップ中にWALを並行して取得できる

例1：データベース全体を物理ファイルとして出力（プレーン形式）

データベースクラスタの実体ファイルをそのまま /pgdata/backup/base/ にコピーし、進行状況と詳細ログを表示する場合は、以下のコマンドを使用します。

pg_basebackup -D /pgdata/backup/base/ -F p -Pv -U postgres -h 127.0.0.1 -p 5432

例2：tar圧縮ファイルとして出力（圧縮レベル指定）

バックアップを1つのtarファイルにまとめ、さらに圧縮することで保存容量を節約したい場合です。

pg_basebackup -D /pgdata/backup/ -F t -Pv -U postgres -h 127.0.0.1 -p 5432 -Z 5

例3：WALログをストリーミングで同時取得する完全バックアップ

バックアップ中に生成されるWAL（先行書き込みログ）も同時に取得することで、復旧時に即座に適用できる状態にします。これはPostgreSQL DBバックアップとして最も信頼性の高い取得方法の一つです。

pg_basebackup -D /pgdata/backup/ -F t -X stream -Pv -U postgres -h 127.0.0.1 -p 5432

このように、pg_basebackupはオプションを組み合わせることで、さまざまな運用ニーズに柔軟に対応できます。特に-X streamを指定すれば、バックアップ中もWALアーカイブが途切れず、後述するPITR（ポイントインタイムリカバリ）の基盤としても活用できます。

大規模データベースやダウンタイムを許容できないシステムでは、ぜひ物理バックアップを導入し、PostgreSQLデータベースのバックアップの堅牢性を一段と高めてください。

方法3：PITRによるアーカイブバックアップの手順

PITR（Point-In-Time Recovery）は、ベースバックアップに加えてWALアーカイブを継続的に蓄積し、障害発生時の「任意の過去時刻」まで正確に戻せる高度な復旧手法です。PostgreSQLのDBバックアップの最終形とも言えるPITRでは、WALログを継続的に取り込むことで秒単位の復旧が可能になります。

PostgreSQLデータベースバックアップを任意の時点に戻せる状態にするには、以下の3つのステップを継続的に実行する仕組みが必要です。これにより、障害発生時にも秒単位の復旧が可能になります。

まずは、PostgreSQLの設定ファイル postgresql.conf でアーカイブ機能をオンにします。

archive_mode = on

archive_command = 'cp %p /アーカイブ先ディレクトリ/%f'

この設定により、すべてのWAL（先行書き込みログ）が指定ディレクトリに自動保存されるようになります。PostgreSQLの自動バックアップの基盤として、このアーカイブ機能は必須です。

pg_basebackup コマンドを使って、データベースクラスタ全体の完全なコピー（ベースバックアップ）を作成します。

具体的なコマンド例は、前項の方法2（pg_basebackupによる物理バックアップの設定） を参照してください。

ベースバックアップが完了した瞬間以降に生成されるすべてのWALログを、漏れなくアーカイブディレクトリに保存し続けることが重要です。

これらのWALログがあれば、ベースバックアップの時点から任意の過去時刻まで、PostgreSQL DBバックアップとしての復旧ポイントを自由に設定できます。つまり、障害が発生した時刻の直前の正しい状態に戻すことが可能になるのです。

方法4：MultCloudによる自動バックアップの実行

ここまで、pg_dumpやpg_basebackup、PITRといったPostgreSQLネイティブのバックアップ手法を解説してきました。これらの手法はいずれも強力ですが、バックアップファイルを「どこに」「どうやって」保管するかという課題が残ります。特に、PostgreSQLデータベースバックアップを日々実行するとなると、ファイルの蓄積と管理が運用負荷の大きな要因になります。

そこで補完的に活用したいのが、MultCloudというクラウド統合管理ツールです。MultCloudは、Google DriveやDropbox、OneDriveなど40種類以上のクラウドストレージを一つのプラットフォームで統合管理できるWebベースのサービスです。

MultCloudの「ウェブサイトバックアップ」機能を使えば、FTPサーバーやデータベースサーバーに直接アクセスし、PostgreSQL DBのバックアップファイルをクラウドストレージに自動保存できます。従来のように、サーバーからローカルにダウンロードしてからクラウドに再アップロードする二度手間が完全に不要になるため、PostgreSQLの自動バックアップ体制を手軽に構築できるのです。

★MultCloudでPostgreSQLバックアップを自動化するメリット

手動ダウンロードの二度手間が不要：FTPやDBサーバーからローカルに落とさず、PostgreSQLバックアップのファイルを直接クラウド保存できます。作業時間を短縮し、ローカル容量も節約できます。

バックアップ先を柔軟に選択可能：Google DriveやDropboxに加え、別のWebサイト（FTP）も保存先に指定できます。PostgreSQLのクラウドバックアップ戦略の幅が大きく広がります。

スケジュール機能でバックアップ忘れを防止：「毎日」「毎週」「毎月」など頻度を設定すれば、PostgreSQLの自動バックアップが確実に実行され、手動運用のうっかりミスを完全に排除できます。

無料プランでも導入しやすい：月間5GBの転送量までは無料で利用可能です。直感的なUIで使いやすく、まずは無料版から始めて運用規模に合わせてプランアップするのがおすすめです。

それでは、MultCloudを使ってPostgreSQLデータベースのバックアップをクラウドに自動保存する手順をステップごとに解説します。

ステップ 1：MultCloudの公式サイトにアクセスし、メールアドレスとパスワードを入力して無料アカウントを作成します。GoogleやFacebook、Appleアカウントを使ったログインにも対応しているので、お好みの方法で始められます。

ステップ 2：左メニューの「クラウドを追加」をクリックし、バックアップ先として使いたいクラウドストレージ（例：Google Drive）を選択します。画面の指示に従いアカウント連携を完了させてください。

ステップ 3：左メニューの「ウェブサイトバックアップ」をクリックし、「バックアップ対象のウェブサイト」をタップして、バックアップしたいサイト（PostgreSQLサーバーが稼働するWebサーバー）を追加します。

FTP／SFTPサーバーの認証情報（IPアドレス・ポート・ユーザー名・パスワード）を入力すれば完了です。

ステップ 4：ウェブサイトのファイル全体に加え、PostgreSQL DBのバックアップも選択できます。WordPressなどCMSで運用しているサイトの場合、テーマファイルやプラグイン、アップロード画像に加え、データベースも含めて漏れなく選択するようご注意ください。

ステップ 5：先ほど連携したクラウドストレージ（例：Google Drive）を保存先として選択し、画面右下の「今すぐバックアップ」ボタンをクリックします。あとはMultCloudが自動でPostgreSQLバックアップを実行し、指定したクラウドに直接保存してくれます。

ウェブサイトバックアップ機能には、以下のような便利なオプションも用意されています。

• 通知機能：バックアップタスクが完了したタイミングで、指定したメールアドレスに完了通知を送信できます。PostgreSQLデータベースのバックアップの実行状況を常に把握できるため、障害時にも即座に対応可能です。
• フィルター機能：特定の拡張子を持つファイルだけをバックアップ対象に含めたり、逆に除外したりすることも可能です。不要なファイルを除外することで、PostgreSQLのクラウドバックアップの容量とコストを最適化できます。

• スケジュール（自動実行設定）：バックアップの実行頻度を「毎日」「毎週」「毎月」などから自由に設定できます。サイトの更新頻度に合わせて最適なスケジュールを選ぶことで、PostgreSQLの自動バックアップを確実に実現できます。

MultCloudのウェブサイトバックアップ機能は、クラウドストレージへの保存だけでなく、別のWebサイトをバックアップ先として設定することも可能です。具体的には、FTP接続情報を持つ別のサーバーを「バックアップ先」として追加すれば、サイトAのPostgreSQL DBバックアップをサイトBに直接バックアップできます。

さらに、MultCloudは以下の機能を提供しています。

まとめ

本記事では、PostgreSQLデータベースバックアップの実践的な手法を、論理バックアップ（pg_dump）から物理バックアップ（pg_basebackup）、さらにPITR（ポイントインタイムリカバリ）まで段階的に解説してきました。最終的には、MultCloudを活用したPostgreSQLの自動バックアップとクラウド連携により、運用負荷を大幅に軽減し、ヒューマンエラーを防ぐ体制を整えることが可能です。

特にMultCloudは、今回紹介したウェブサイトバックアップ機能に加え、クラウドストレージ間のファイルを直接移動できる「クラウド転送」機能も備えています。これにより、バックアップファイルを異なるクラウドサービス間で柔軟に分散保管することが容易になります。

よくある質問

1.PostgreSQLのデータベースはどこに保存されますか？

PostgreSQLのデータベースは、データディレクトリ（通常は/var/lib/postgresql/や/usr/local/var/postgres/など）内にファイルとして保存されます。このディレクトリには、各データベースのデータファイルや設定ファイル、WALログなどが含まれています。MultCloudのようなクラウド管理ツールを使えば、これらのバックアップファイルを自動的にクラウドへ転送し、オフサイト保管も簡単に実現できます。

2.PostgreSQLのベースバックアップとは何ですか？

ベースバックアップとは、pg_basebackupコマンドを使ってデータベースクラスタ全体をファイルシステムレベルで丸ごと複製する物理バックアップのことです。稼働中でも一貫性のあるコピーが取得でき、PITR（ポイントインタイムリカバリ）の基盤としても利用されます。

3.PostgreSQLのDBのバックアップはどうやって取りますか？

主に3つの方法があります。（1）pg_dumpによる論理バックアップ（SQL形式で出力）、（2）pg_basebackupによる物理バックアップ（ファイルシステムごとコピー）、（3）WALアーカイブを併用したPITR（任意の時点へ復旧可能）です。MultCloudのスケジュール機能を使えば、これらのバックアップファイルを定期的にクラウドへ自動保存でき、バックアップ忘れを完全に防げます。

4.PostgreSQLの弱点は何ですか？

主な弱点は、（1）デフォルト設定ではパフォーマンスが十分に発揮されずチューニングが必要なこと、（2）大規模な書き込み負荷ではMVCC（多版型同時実行制御）によるVACUUM処理が負担になること、（3）複雑なレプリケーション設定が求められる点です。

5.pg_dumpとpg_dumpallの違いは何ですか？

pg_dumpは単一のデータベースのみをバックアップするのに対し、pg_dumpallはクラスタ内のすべてのデータベースとグローバルオブジェクト（ロールやテーブルスペースなど）をまとめてバックアップします。pg_dumpallはリストア時にデータベース自体の作成も行います。

6.MySQLとPostgreSQLのどちらが良いですか？

用途によります。PostgreSQLは複雑なクエリや分析処理、ACID準拠が求められるシステムに強く、MySQLはシンプルなWebアプリや高負荷の読み取り処理に適しています。データの整合性や拡張性を重視するならPostgreSQL、シンプルさと速度を重視するならMySQLがおすすめです。