この記事の要点

.dump / .bak はデータベースのバックアップファイルの慣用拡張子。内部形式は DBMS により全く異なる PostgreSQL の pg_dump -Fc は独自バイナリ形式（カスタムフォーマット）の .dump。圧縮 + 並列リストア対応 SQL Server の .bak は MTF（Microsoft Tape Format）ベースの専用形式。BACKUP DATABASE 文で作成、RESTORE DATABASE で復元 Oracle の RMAN バックアップ、MySQL Enterprise Backup、Percona XtraBackup も独自バイナリ形式（拡張子は様々） 物理バックアップ（データファイル単位）と論理バックアップ（SQL 文ベース）の 2 系統がある。.bak は基本物理 リストア戦略は フル + 差分 + トランザクションログ の 3 階層。PITR（Point-In-Time Recovery）で任意時刻に巻き戻せる ファイル自体に DB ユーザ・パスワード・データが含まれるため、暗号化と保管場所の管理が必須

概要

DB ダンプファイルは、データベースの内容をまるごと書き出したバックアップファイルの総称です。拡張子は .dump・.bak・.backup・.tar など DBMS と運用慣習で異なり、ファイル内部の形式も製品固有のバイナリだったり SQL 文だったり様々です。前項の SQL ダンプ（.sql） がテキストの汎用形式なのに対し、ここで扱うのは 製品固有のバイナリ形式 を中心とした「運用バックアップ」のファイルです。

大きく分けて 2 系統あります。論理バックアップは CREATE TABLE / INSERT のような SQL や独自エンコードでデータの「意味」を保存する方式で、DB バージョンを跨いで移行しやすい代わりに大規模になるとリストアが遅い。物理バックアップは DB が使うデータファイル（PostgreSQL なら base/ ディレクトリ、SQL Server なら .mdf・.ldf）をそのままコピーする方式で、リストアが圧倒的に速い代わりに同じバージョン・同じプラットフォームでしか復元できないのが基本です。

典型的なファイルとして、PostgreSQL の pg_dump -Fc が出力するカスタムフォーマット .dump、SQL Server の BACKUP DATABASE が出力する .bak、Oracle RMAN のバックアップピース、Percona XtraBackup の xbstream 出力などが挙げられます。いずれも そのままテキストエディタで開いても読めない バイナリで、専用のリストアコマンドを通す必要があります。

内部構造とよくある中身

形式	DBMS	系統	圧縮	並列	PITR 連携
カスタム -Fc	PostgreSQL	論理	○（gzip）	○（リストア時 -j）	△（WAL 併用）
ディレクトリ -Fd	PostgreSQL	論理	○	◎（ダンプ・リストア両方）	△
.bak	SQL Server	物理	○	○	◎（ログバックアップ）
RMAN	Oracle	物理	○	◎	◎
XtraBackup	MySQL / MariaDB	物理	○	◎	○（binlog 併用）
mysqldump	MySQL / MariaDB	論理	×（要 gzip）	×	△（binlog 併用）

たとえば PostgreSQL のカスタム形式は、ヘッダに「PGDMP」のマジックを持ち、続いてテーブル定義・データ・インデックス・トリガなどがブロック単位で並びます。pg_restore -l でブロック一覧（TOC）を出力でき、-L で必要なブロックだけ選んで戻すことができます。SQL Server の .bak は MTF（Microsoft Tape Format）をベースに、データページとログをまとめた形式で、RESTORE HEADERONLY で中身のメタ情報を読み出せます。

主な用途

• 定期バックアップ: 毎日フルバックアップを取り、世代を 7〜30 日分保持。週次のフルと日次の差分・増分を組み合わせるのが定石
• 本番→検証環境のデータ複製: 物理バックアップで全データを一気に移し、その上に個人情報マスキングを適用する
• 災害復旧（DR）: 別リージョンにバックアップを転送し、リージョン障害時にそこから DB を再構築する
• 監査・コンプライアンス: 一定期間（金融なら 7〜10 年）のバックアップ保管が法令で求められる業界がある
• ポイントインタイムリカバリ（PITR）: フルバックアップ + トランザクションログで「3 日前 14:23:45 の状態」に巻き戻す
• 本番リプレース: ハードウェア更改で旧マシンの .bak を新マシンに RESTORE するのが SQL Server の伝統的な移行手順

関連形式との比較

SQL ダンプ（.sql） がテキストで「移植性 ◎・速度 ×」だったのに対し、.dump / .bak は「移植性 ×・速度 ◎」という反対の特性を持ちます。両者を組み合わせて、週次の物理バックアップ + 月次の論理バックアップ + 毎時のトランザクションログ という三段構成にすると、復旧スピードと長期可搬性の両方を確保できます。

項目	論理（.sql / mysqldump）	物理（.bak / XtraBackup）
サイズ	中（テキスト）	大〜中（バイナリ）
取得時間	長い	短い
リストア時間	長い（SQL 再実行）	短い（ファイル戻すだけ）
バージョン跨ぎ	○	×（基本不可）
PITR	△	◎
テーブル単位	○	×（DB 全体）

コマンド・ツール

# PostgreSQL: カスタム形式
pg_dump -U postgres -F c -f shop.dump shop
pg_restore -U postgres -d shop_new -j 4 shop.dump

# 中身の TOC を確認
pg_restore -l shop.dump | head

# 部分リストア（特定テーブルだけ）
pg_restore -U postgres -d shop_new -t users shop.dump

# SQL Server: T-SQL 内で
BACKUP DATABASE shop TO DISK = N'D:\\bk\\shop.bak'
  WITH COMPRESSION, INIT, NAME = N'shop-full';

RESTORE DATABASE shop_new FROM DISK = N'D:\\bk\\shop.bak'
  WITH MOVE 'shop'     TO 'D:\\data\\shop_new.mdf',
       MOVE 'shop_log' TO 'D:\\data\\shop_new.ldf',
       REPLACE;

# Percona XtraBackup（MySQL）
xtrabackup --backup --target-dir=/bk/full/
xtrabackup --prepare --target-dir=/bk/full/
xtrabackup --copy-back --target-dir=/bk/full/

# 並列圧縮（zstd）でアーカイブ
pg_dump -F c shop | zstd -T0 > shop.dump.zst

クラウドのマネージド DB（RDS・Cloud SQL・Azure SQL）では、これらのバックアップが 自動スナップショット として隠蔽されており、ユーザは「7 日前 14:00 に戻す」というボタンだけで PITR ができるようになっています。内部的には WAL / binlog / トランザクションログを継続的に S3 等へ転送している実装です。

注意点

• 「バックアップは取れているがリストアできない」事故: 月 1 回は 本番と同じ手順でリストア訓練 を行う。検証していないバックアップは存在しないのと同じ
• バージョン互換: .bak は古いバージョンの SQL Server で取ったものを新版に戻すのは可能だが 逆は不可。PostgreSQL のカスタム形式も同じ。移行計画で必ず確認
• 暗号化: バックアップファイルは平文の機密情報を含む。LUKS / BitLocker でディスク暗号化するか、BACKUP ... WITH ENCRYPTION（SQL Server）等で暗号化する
• 3-2-1 ルール: 3 つの複製を、2 種類のメディアに、うち 1 つはオフサイト。クラウド時代でも基本は変わらず、リージョン跨ぎの転送で対応する
• 整合性: 物理バックアップはホットコピー中の整合性確保が肝。XtraBackup / VSS（Windows）/ snapshot（ZFS・LVM・EBS）を活用する
• ファイル名と世代管理: shop-2026-06-22.bak のように日付を含め、古い世代は自動削除 する運用にする。手動管理だとディスクが溢れる
• リストア時のディスク容量: 圧縮された .dump は展開すると数倍〜十数倍に膨らむ。リストア先の空き容量を事前確認

関連リンク

• 親カテゴリ: データベース・データ交換
• 概論: ファイル拡張子とは
• カテゴリ: データベース（カテゴリ）
• 関連: SQL ダンプ（.sql）（論理バックアップ）
• 同 Wave: SQLite / NDJSON / BSON