じゃあ、イメージしてみて。自分のデータベースはめっちゃでかい図書館のアーカイブみたいなもんで、本が何千冊もある感じ。フルバックアップってのは、毎晩バイク便を呼んで全部の本をコピーするイメージ。でも、ほとんど何も変わってなかったら?それってめっちゃ遅いし、運搬も大変だし、保存場所も食うよね。そこでインクリメンタルと差分のやり方が登場。俺たちは賢くやる、無駄に多くじゃなくて、本当に変わったとこだけコピーするってわけ。
今日はこんなバックアップタイプを見ていくよ:
- フルバックアップ: データベース全体を丸ごとコピー。
- インクリメンタルバックアップ: 最後のバックアップから変わった部分だけコピー。
- 差分バックアップ: 最後のフルバックアップから変わった部分だけコピー。
それぞれのやり方にはメリット・デメリット、使いどころがある。詳しく見ていこう。
フルバックアップ
フルバックアップ(Full Backup)は、その時点のデータベース全体のバックアップ。テーブル、インデックス、スキーマみたいな構造も、全部のデータも入ってる。つまり、データベースの「スナップショット」って感じ。
フルバックアップのコマンド例:
pg_dump -U username -d database_name -F c -f full_backup.dump
これの意味:
-U username— PostgreSQLユーザー名。-d database_name— データベース名。-F c— バックアップのフォーマット(custom、pg_restoreでリストアしやすい)。-f full_backup.dump— 保存するバックアップファイル名。
pg_dumpコマンドとそのオプションについては、次の講義で詳しくやるからお楽しみに :P
フルバックアップのメリット:
- リストアが簡単。 なんかやらかしても、フルバックアップがあれば全部一気に戻せる。
- データの完全なスナップショット。 別サーバーや環境に丸ごと移す時にも使える。
フルバックアップのデメリット:
- データ量が多い: データが多いとバックアップもめっちゃでかくなる。
- 時間がかかる: データが多いほどコピーに時間がかかる。
- 保存場所が必要: フルバックアップごとに別のスペースが必要で、ストレージを食う。
フルバックアップを使うタイミング:
- 最初のバックアップを作るとき。
- データベースに大きな変更を加える前。
- 長期保存用アーカイブ(フルバックアップを「コールド」ストレージに送るとか)。
インクリメンタルバックアップ
インクリメンタルバックアップ(Incremental Backup)は、最後のバックアップ(フルでもインクリメンタルでもOK)から変わったファイルだけ保存するやり方。これでディスクスペースをかなり節約できるし、バックアップも速くなる。
PostgreSQLでインクリメンタルバックアップをやるなら、pgBackRestってツールが便利。これはPostgreSQLのバックアップ管理用の強力なユーティリティで、フル・インクリメンタル・差分全部に対応してる。
pgBackRestの仕組みは?
pgBackRestはファイルのメタデータやチェックサムで変更を検出する。- 本当に変わったファイルだけインクリメンタルバックアップに入る。
- WALファイルの自動アーカイブもサポートしてて、好きな時点までリストアできる。
インクリメンタルバックアップのコマンド例:
pgbackrest --stanza=main --type=incr backup
この意味:
--stanza=main— 設定名(特定DB用のパラメータセット)。--type=incr— インクリメンタルバックアップを指定。
最初のインクリメンタルバックアップの前に、フル(--type=full)を必ずやっておこう。
pgBackRestでインクリメンタルバックアップするメリット:
- スペース節約: 変わったファイルだけコピー。
- 速い: 変更が少ないと特に速い。
- WAL自動管理: pgBackRestがWALファイルを自動でアーカイブ&適用。
- リストアの柔軟性: 好きな時点(PITR)を選んでリストアできる。
デメリットや注意点:
- 初期設定が必要:
stanzaやリポジトリディレクトリ、権限設定が必要。 - 初心者にはちょい難しい: WALやPostgreSQLの構造を理解しておく必要あり。
- リポジトリ依存: バックアップは全部中央管理なので、ストレージ管理が大事。
インクリメンタルバックアップを使うタイミング:
- データベースが頻繁に更新されるとき。
- フルバックアップが重すぎる・時間がかかりすぎるとき。
- 信頼性が高くて自動化されたリストア戦略を、コスト最小で作りたいとき。
差分バックアップ
差分バックアップ(Differential Backup)は、最後のフルバックアップから今までに起きた全変更を保存するやり方。インクリメンタルとの違いは、差分バックアップは毎回「最後のフルバックアップから全部の変更」を持ってること。だからリストアには、最後のフルバックアップと最新の差分バックアップだけあればOK。
プロセス例:
- 初日:フルバックアップ(A)を作る。
- 2日目(B):差分バックアップを作る — Aからの変更を全部含む。
- 3日目(C):また差分バックアップ — これもAからの変更を全部含む。
メリット:
- リストアが簡単: フルバックアップと最新の差分バックアップだけでOK。
- フルより速い: 差分バックアップはフルより速い。変更だけコピーするから。
デメリット:
- バックアップファイルが大きくなる: 差分バックアップを重ねるほど、ファイルサイズが増える(フルからの全変更を持つから)。
- ディスクスペース: 長期的にはインクリメンタルより多くのスペースが必要になることも。
差分バックアップは、リストアを簡単にしたいときに便利。最後のフルバックアップからの全変更を持ってるから、データがよく変わるけど毎回フルは重すぎるって時に、スピードと信頼性のバランスが取れるやり方だよ。
バックアップタイプの比較
| バックアップタイプ | フル | インクリメンタル | 差分 |
|---|---|---|---|
| データ量 | 最大 | 最小 | 中間 |
| 実行時間 | 長い | 速い | まあまあ |
| リストア | 簡単 | ちょい難(全部のバックアップが必要) | 中間(最後のフル+差分だけ) |
| 使いどき | 初回コピー、移行 | リアルタイムで頻繁なバックアップ | 定期的なバックアップ |
どのバックアップタイプを選ぶかは、データの安全性、更新頻度、リソースの余裕によるよ。小さいDBならフルバックアップを定期的にやればOK。DBが大きくなったらインクリメンタルでスペース節約。リストアの速さ重視なら差分がベストかも。とにかく、定期的に&自動化を忘れずに!
GO TO FULL VERSION