Day23 前半のゴール
「“壊れたら終わり”を“壊れても戻せる”に変える感覚を持つ」
Day23 はバックアップです。
ここまで設計・パフォーマンス・トランザクション・ロック…とやってきましたが、どれだけきれいに作っても「壊れたら終わり」では意味がありません。
バックアップは、“もしものときに過去の自分を助ける仕組み”です。
前半のゴールはこうです。
pg_dump が「PostgreSQL標準のバックアップツール」であることを理解する。
「何をバックアップするのか」「どの単位で取るのか」をイメージできる。
簡単な例で、バックアップ→リストアの流れを説明できる。
まずは、「バックアップってそもそも何を守るのか」からいきます。
バックアップの本質
「“データそのもの”と“構造”の両方を守る」
バックアップというと、「データをコピーする」と思いがちですが、
データベースの場合はもう少し広い意味を持ちます。
守りたいものは大きく2つです。
1つ目は「データそのもの」。
ユーザー、注文、ログ、設定…これまで積み上げてきた行たちです。
2つ目は「構造」。
テーブル定義、インデックス、制約、シーケンス、関数、ビューなど、
“どういう形でデータが入っているか”という情報です。
PostgreSQL の pg_dump は、この両方をまとめて「再現可能な形」にしてくれるツールです。
つまり、「このファイルさえあれば、同じデータベースをもう一度作れる」という状態を作るのが目的です。
pg_dumpとは何か
「PostgreSQLが用意している“公式のコピー機”」
pg_dump は、PostgreSQL に付属しているバックアップ用コマンドラインツールです。
イメージとしては、「DBに接続して、中身を“再現スクリプト”として書き出すプログラム」です。
一番シンプルな使い方は、こういう形です。
pg_dump -U myuser -d mydb > mydb.sql
このコマンドは、
myuser というユーザーで mydb に接続し、
テーブル定義やデータを SQL の形で書き出し、
結果を mydb.sql というファイルに保存する。
という動きをします。
この mydb.sql を、あとで別の環境で psql などを使って流し込めば、
同じ構造・同じデータを持つデータベースを再現できます。
ここで重要なのは、「pg_dump は“PostgreSQLの外側に安全なコピーを作る”ツール」だということです。
サーバが壊れても、ストレージが飛んでも、このファイルが別の場所に残っていれば、復活のチャンスがあるわけです。
バックアップの単位をイメージする
「“全部”か“1DB”か“1テーブル”か」
pg_dump は、いくつかの単位でバックアップを取ることができます。
初心者向けに、まずは3つのイメージを持っておくといいです。
1つ目は「1つのデータベース単位」。-d mydb のように指定して、そのDBだけを丸ごとバックアップする形です。
小〜中規模のシステムでは、これが一番よく使われます。
2つ目は「特定のテーブルだけ」。-t users のようにテーブル名を指定して、そのテーブルだけをバックアップする形です。
「このテーブルだけ別環境に持っていきたい」「このテーブルだけ退避したい」といったときに使えます。
3つ目は「クラスタ全体」（これは pg_dump ではなく pg_dumpall が担当ですが、概念として押さえておく価値があります）。
複数DBをまとめて扱う場合に、「全部まとめて定義を取る」ためのものです。
Day23 前半では、「とりあえず1DB丸ごと」「必要なら1テーブル単位」という2つのイメージが持てれば十分です。
例題：開発用DBをバックアップして別環境にコピーする
「“手元のDBを丸ごと持っていく”流れを具体的に見る」
具体的なシナリオで、バックアップ→リストアの流れを見てみましょう。
状況：
ローカル環境に mydb という開発用DBがある。
これを別のPCやサーバにコピーして、同じ状態から開発を始めたい。
まず、元の環境でバックアップを取ります。
pg_dump -U myuser -d mydb > mydb.sql
これで、mydb.sql というファイルができます。
中身は、CREATE TABLE や INSERT 文などがずらっと並んだ「再現用スクリプト」です。
次に、コピー先の環境で、空のデータベースを作ります。
createdb -U myuser mydb
そして、さっきの mydb.sql を流し込みます。
psql -U myuser -d mydb -f mydb.sql
これで、元の環境と同じテーブル・同じデータを持つ mydb が、コピー先に再現されます。
この流れが、「pg_dump / リストア」の基本形です。
「バックアップファイルを作る」「新しいDBを作る」「ファイルを流し込む」という3ステップですね。
バックアップファイルの“中身”をイメージする
「SQL形式＝“人間が読める再現レシピ”」
さきほどの例で作った mydb.sql の中身は、基本的に「SQL文の集合」です。
例えば、こんな感じのものが並んでいます。
--
-- Name: users; Type: TABLE; Schema public;
--
CREATE TABLE public.users (
id bigint NOT NULL,
name text NOT NULL,
email text NOT NULL
);
--
-- Data for Name: users; Type TABLE DATA;
--
INSERT INTO public.users (id, name, email) VALUES (1, 'Taro', 'taro@example.com');
INSERT INTO public.users (id, name, email) VALUES (2, 'Hanako', 'hanako@example.com');
...
つまり、
テーブル定義（CREATE TABLE）
インデックス定義（CREATE INDEX）
制約（ALTER TABLE … ADD CONSTRAINT）
データ（INSERT）
が順番に並んでいて、「この順番で実行すれば同じDBができる」というレシピになっています。
この「SQL形式」のバックアップは、人間が読める・編集できるというメリットがあります。
小さなDBなら、これで十分です。
一方で、大規模DBでは「カスタム形式」や「ディレクトリ形式」といった、
より柔軟な形式を使うこともあります（これは後半で触れます）。
バックアップの“頻度”と“置き場所”
「取るだけじゃなく、“どこに・どれくらい残すか”が重要」
バックアップは、「1回取って終わり」ではありません。
運用としては、「どれくらいの頻度で」「どこに置いて」「どれくらい保持するか」を決める必要があります。
頻度のイメージ
開発用DBなら、手動で必要なときに取るだけでもいい。
本番DBなら、最低でも毎日、場合によっては数時間おきに取る。
置き場所のイメージ
同じサーバ内だけに置くのは危険。
別サーバ・クラウドストレージなど、「物理的に離れた場所」にコピーを置く。
保持期間のイメージ
「直近7日分は毎日」「直近3ヶ月分は週次」「それより前は月次」など、
古いバックアップをどう扱うかも決めておく。
セキュリティの観点からも、「バックアップファイルには本番データが丸ごと入っている」ことを忘れてはいけません。
アクセス権限、暗号化、保管場所――どれも“本番DBと同じくらい”慎重に扱う必要があります。
Day23 前半のまとめ
pg_dump は、PostgreSQL が標準で提供しているバックアップツールであり、「テーブル定義・インデックス・制約・データ」をまとめて“再現可能な形（SQLなど）”に書き出すことで、「このファイルさえあれば同じDBをもう一度作れる」状態を作るためのもの。
基本的な流れは「pg_dumpでDBをバックアップファイルに書き出す → 新しい環境で空のDBを作る → psqlなどでファイルを流し込んでリストアする」であり、バックアップは“取ること”だけでなく「どの単位で取るか（DB単位・テーブル単位）」「どれくらいの頻度で取るか」「どこに置いてどう守るか（別サーバ・暗号化など）」まで含めて設計するもの――ここまでのイメージが持てれば、Day23 前半としては十分な着地です。